There may be many reasons to hide few of the information in active directory which can be only view by authorized person & not everyone able to read it. By default what all information stored in AD can be view/ready by any domain user. In some company there may be a requirement to update few information in each user attribute which should not be publicly visible , but only domain admin or delegated groups/user should be able to read/modify/update it.

Below is the best way to implement the confidential attribute without extending the schema & nor tampering the default permission in active directory.

The best way is to take an existing attribute and flag it as Confidential.

The default permissions in Active Directory are such that Authenticated Users have blanket read access to all attributes. This makes it difficult to introduce a new attribute that should be protected from being read by everyone.

To mitigate this, Windows 2003 SP1 introduces a way to mark an attribute as CONFIDENTIAL. This feature achieved by modifying the searchFlags value on the attribute in the schema. SearchFlags contains multiple bits representing various properties of an attribute. E.g. bit 1 means that the attribute is indexed. The new bit 128 (7th bit) designates the attribute as confidential.

Note: you cannot set this flag on base-schema attributes (those derived from “top” such as common-name). You can determine if an object is a base schema object by using LDP to view the object and checking the systemFlags attribute of the object. If is the 10th bit is set it is a base schema object.

When the Directory Service performs a read access check, it checks for confidential attributes. If there are, then in addition to READ_PROPERTY access, the Directory Service will also require CONTROL_ACCESS access on the attribute or its property set.

By default, only Administrators have CONTROL_ACCESS access to all objects. Thus, only Administrators will be able to read confidential attributes. Users are free to delegate this right to any specific group they want. This can be done with DSACLs tool, scripting, or the R2 ADAM version of LDP. As of this writing is not possible to use ACL UI Editor to assign these permissions.

The process of marking an attribute Confidential and adding the users that need to view the attribute has 3 Steps

  1. Determining what attribute to mark Confidential, or adding an attribute to mark Confidential.
  2. Marking it confidential
  3. Granting the correct users the Control Access right so they can view the attribute.

For more details and step-by-step instructions, please refer to the following article:

922836 How to mark an attribute as confidential in Windows Server 2003 Service Pack 1;EN-US;922836

Before configure as confidential  attribute 

pic1                         After configuring it to confidential attribute


Access the user via domain admin account



Access the user via normal user account


How do we set the CONTROL_ACCESS permission for a hidden attribute? This should actually be an easy thing, but Microsoft didn’t supply any command-line tools with Windows Server 2003 SP1 that could set this access at the attribute level. However, Windows Server 2008 and later versions have an updated Dsacls version that fully supports this capability, as tested on a Windows Server 2012 DC.

The correct syntax to add the CONTROL_ACCESS permission via Dsacls is as follows:


When you assign CONTROL_ACCESS permissions at the property level to a user or group, you must specify the display name of the property—in our case, employeeNumber:

DSACLS "CN=Root-User1,OU=UserAccounts,DC=root,DC=net"
  /G root\HR-users:employeeNumber

Unfortunately, ever since the CONTROL_ACCESS permission was introduced, there hasn’t been a really useful UI to manage or view this permission. This is still true in Windows Server 2012. But since Windows Server 2003 R2, the LDP.exe editor does include a powerful security editor that allows you to view and set the CONTROL_ACCESS flag on a specific object attribute.

Navigate to the object on which you want to change the permissions. Right-click the object and choose Advanced, Security Descriptor. LDP then pops up a dialog box, which you can use to set the options for displaying the Security Descriptor. Don’t choose the Text dump, which dumps the descriptor to the output window. Using the default settings starts the new

How to let non-administrative users see the attribute data

Note the following procedures require that you use the Ldp.exe tool that is included with Windows Server 2003 R2 Active Directory Application Mode (ADAM). Other versions of the Ldp.exe tool cannot set permissions.

How to manually set Control_Access permissions on a user/group account

  1. Open the Ldp.exe tool that is included with Windows Server 2003 R2 ADAM.
  2. Connect and bind to the directory.
  3. Select a user account, right-click the account, click
    Advanced, click Security Descriptor, and then click OK.
  4. In the DACL box, click Add ACE.
  5. In the Trustee box, type the group name or the user name to which you want to grant permissions.
  6. In the Control Access box, verify the changes that you made in step 5.



How to use inheritance to assign Control_Access permissions

To use inheritance, create an access control entry that grants Control_Access permissions to the desired users or groups that are higher in the container hierarchy than the objects that have confidential attributes. You can set this access control entry at the domain level or at any point in the container hierarchy that works well for an enterprise. The child objects that have confidential attributes must have inheritance enabled.

To assign Control_Access permissions, follow these steps:

  1. Open the Ldp.exe file that is included in Windows Server 2003 R2 ADAM.
  2. Connect and bind to a directory.
  3. Select an OU or a container that is the higher in the container hierarchy than the objects that have confidential attributes, right-click the OU or the container, click Advanced, click
    Security Descriptor, and then click OK.
  4. In the DACL box, click
    Add ACE.
  5. In the Trustee box, type the group name or the user name to which you want to grant permissions.
  6. In the Control Access box, verify the changes that you made in step 5.
  7. In the Object Type box, click the confidential attribute that you added.
  8. Make sure that inheritance is enabled on the target objects.

In below screen you have to provide the delegation if only read then only select “Control access” if need modify rights then select”Write permission” alomg with Control access.

pic 5

How to determine the systemFlags attribute value when you use an existing attribute

If you use an existing object, you must verify what the current searchFlags attribute value is. If you add an object, you can define the value when you add the object. There are many ways to obtain the searchFlags attribute value. Use the method that works best for you.

To use the Ldp.exe tool to obtain the searchFlags attribute value, follow these steps:

  1. Click Start, click Run, type LDP, and then click OK.
  2. Click Connection, and then click
  3. Bind as the Administrator of the root domain, or bind as an account that is an Enterprise Administrator.
  4. Click View, and then click
  5. Click
    CN=schema,cn=configuration,dc=rootdomain, and then click OK.
  6. In the left pane, expand
  7. Locate the domain name of the attribute that you want to mark as confidential, and then expand it.
  8. In the list of attributes that are populated for the object, find searchFlags to determine the current searchFlags attribute value for that object.

Note To determine the new searchFlags attribute value, use the following formula:

128 + current searchFlags attribute value =
new searchFlags attribute value

How to determine whether an attribute is a base schema attribute

To determine whether an attribute is a base schema attribute, use the Ldp.exe tool to examine the systemFlags attribute value.

LDP output of Employee-ID – systemFlags: 0x10 = (FLAG_SCHEMA_BASE_OBJECT)