MIIS's Magic X-Ray Specs

Remember those atrocious ads in the back of comic books luring your money away for the promise of seeing through walls for a peak at confidential data?  Well, look no further, MIIS can do this right out of the box (cereal not included)! 

In a previous posting I talked about the Confidentiality Bit now available in Windows 2003 level Active Directories.  On a recent project I was frustrated by a set of attributes that were apparently empty but MIIS kept insisting there was data there.  No matter what I did or where I checked, MIIS kept importing the data even though ADSI Edit and LDP clearly showed this value was null.  After further investigation, remote consults (thanks Markus!) and much head scratching it was found that the attribute in question had the confidentiality bit set - MIIS was reading the data even though it was protected!  How can this be, and is it a security risk?

DirSync and the Replicate Directory Changes Right

Active Directory, being a robust directory service, has a facility for querying for changes called DirSync.  Once you have a full read of the directory, DirSync can be used to request only objects or attributes that have changed since the last query.  Prior to Windows Server 2003, DirSync only functioned in so called "regular" mode which exposed the attributes and objects therein equally and seemingly unprotected but looks can be deceiving.  Let's see what MSDN has to say about DirSync:

The DirSync technique is based on an LDAP server control that you can use through ADSI or LDAP APIs. The disadvantages of the DirSync control are that it can only be used by a highly privileged account, such as a domain administrator. The following is a list of limitations of DirSync control:

• The DirSync control can only be used by a highly-privileged account, such as a domain administrator.
• The DirSync control can only monitor an entire naming context. You cannot limit the scope of a DirSync search to monitor only a specific subtree, container, or object in a naming context.

By "highly privileged" we mean the Replicating Directory Changes right which can only be assigned at the root of the naming context (domain, configuration or schema).  You're already familiar with this right because MIIS requires it for the ADMA and MIIS can't even read the directory without it - go ahead, try.  As it turns out, it takes a very deliberate act from a privileged administrator to grant this right, but administrators will always want to be aware of what granting this right has the potential to expose.  Luckily for us, MIIS is generally involved with placing the confidential data in the directory, so reading it is a moot point - and remember, passwords are always hashed, so they are never exposed.  The point I'm trying to make here is that by default, the account you use for your ADMA doesn't need rights to read attributes protected by the confidentiality bit - partially because that bit is designed to protect from casual read access but mostly because they are protected by the Replicating Directory Changes right.  So, is there another option?

Per-object Security for DirSync

In Windows Server 2003 Active Directory there is an option to enforce per-object security through the DirSync changelog, but I'm at a loss as to how to enable it.  Furthermore, there is currently no option for the ADMA to operate under this environment, so for the time being you're still going to have to grant the right anyway; however the pieces are in place to further extend the reach of the confidentiality bit to the DirSync changelog.

Summary

The Replicating Directory Changes right trumps the confidentiality bit - at least until per-object security can be enabled in the DirSync.  Ensure that any identities or processes that are delegated this right are cleared to read any data stored in the directory that may be marked as confidential.