Using Confidential Bits to Hide AD Object Attributes

Q: I'm looking for a technique to hide specific Active Directory (AD) object attributes from users who only have generic read permissions to the attribute. One of the attributes I would love to hide, for example, is my employees’ smart card identifier numbers. Does the AD access control model out-of-the-box support something that can help me out?

A: By default, every AD user has read permission to all of the attributes of his proper AD user object. This is because in the AD access control model the Windows SELF well-known-security-principal is granted the Read All Properties permission to a user object.
As you refer to in your question, this is problematic if you want to prevent access to sensitive data for accounts that have been granted read access to certain attributes either directly, or through the all encompassing Read All Properties permission. You may, for example, want to hide the content of AD attributes holding the social security number of employees, their smart card IDs, or even their employee ID.
This is where the confidential bit comes in that Microsoft introduced in Windows Server 2003 SP1. As the name implies, the confidential bit configures specific attributes in AD to be confidential, which translates to "not-accessible to any user without a special permission that is different from plain read permission".
The basic steps behind configuring the confidential bit for a given AD attribute are the following:
• The confidential bit must set as bit 7 (=128 decimal value) in the searchFlags property of an attributeSchema object in the AD schema. This means that if you add 128 to any existing value the attribute will be marked as confidential.
• Granting access to a confidential attribute to users or groups who need to read the confidential data in the attribute, requires that you grant these users CONTROL_ACCESS permission on the attribute for the respective objects.

A very important limitation to be aware of when you try to use the confidential bit is that Microsoft does not let you apply the bit to the base schema attributes. This basically rules out leveraging the confidential bit for 90% of the default attributes that come with AD. This does not mean that you cannot apply the confidential bit to custom attributes you add to your AD schema for serving organization-specific needs. Table 1 lists the Common Names of the AD attributes the confidential bit can be applied to in Windows 2003.
There is not much sense in questioning why Microsoft chose specific attributes to be base schema attributes and why others of the same nature are not and vice versa. Basically Microsoft wanted to limit using the confidential data feature to custom extensions to AD, such as an attribute containing the Social Insurance number of a user, which is not part of the default schema.
One of the main reasons why Microsoft added the confidential bit AD in Windows 2003 SP1 was to support another new security-related feature in SP1: credential roaming. Credential roaming enables Windows domain users to access their PKI private keys and certificates from any workstation they log on to in the Windows domain. Their credentials can roam with them because the credential roaming service keeps a secured copy of the user PKI credentials in the user’s AD object and keeps these in sync with the local PKI credentials stored in the user’s certificate store and private key store on the workstation. The user PKI credentials are secured/hidden using the confidential bit.
 For more information on the confidential bit and how you can leverage it, I also refer to the following Microsoft article: http://support.microsoft.com/kb/922836.

Table 1: Default AD schema attributes that confidential bit can be applied to