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
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
Before configure as confidential attribute
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:
DSACLS /G :CA;
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
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:
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.
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:
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)