Active Directory (AD) is widely adopted by many companies as the central identity and access management platform. It provides authentication and authorization services and includes many security features that can enforce access controls to applications and other services within the enterprise. However, sometimes the data you store within AD to support applications is sensitive and should only be readable by authorized users.
It’s not a good idea to store highly sensitive data in a directory that can be read by everyone; however, there are times when certain data should be hidden from the general population. Examples include custom schema extensions to support data that apps may require but that should not be broadly published. When it’s needed, AD has an option called the confidentiality bit that you can use to hide sensitive information and grant the proper access to only need-to-know accounts.
The Problem
The Pre-Windows 2000 Compatible Access group is a special built-in group that was designed to provide backward compatibility to legacy apps and systems. This group grants members the ability to read all users and groups in the domain. By default, the Authenticated Users group is a member, meaning that all users in the domain can read all other users and groups. This can expose sensitive attributes to anyone in the domain.
The easiest remedy seems to be removing the Authenticated Users group from the Pre-Windows 2000 Compatible Access group. However, doing so isn’t advised without careful planning and testing. Removing the Authenticated Users group may have unintended consequences such as breaking apps and restricting necessary functionality.
Hiding Attributes with the Confidentiality Bit
Starting with Windows Server 2003 SP1, administrators can use a special feature called the confidentiality bit to restrict access to view sensitive attributes. This is done by setting the correct value in the searchFlags attribute on a schema attribute. The searchFlags property specifies various options about an attribute, such as indexing, replication, and confidentiality. For more information about the searchFlags attribute, download the Active Directory Technical Specification from Microsoft.
One caveat is that attributes that are part of the base schema cannot be changed, because of system protections that prevent modifications. To see the details of an AD schema attribute, use ADSIEDIT and connect to the schema partition. Right-click an attribute and select Properties. While viewing the properties, find the systemFlags attribute. If the 0x10 bit is set (SCHEMA_BASE_OBJECT), then that specific attribute is part of the base schema and cannot be changed.
Also note that domain administrators can see confidential attributes by default, and it isn’t entirely possible to prevent them from viewing the values.
Setting Attribute Confidentiality
To demonstrate the process of setting the confidentiality bit on an attribute, I first created a custom schema extension in my AD lab environment called accountClassification and associated it with the User objectClass in AD.
I then created a service account, _svcAcctClass, that will explicitly be delegated the necessary permissions to read the contents of the attribute. All other accounts will be unable to see the values in the attribute.
To mark the accountClassification attribute as confidential, you must be a Schema Admin.
Follow these steps:
- Open ADSIEDIT.msc and connect to the Schema partition.
- Select the Account-Classification attribute, then right-click and choose Properties.
- Open the searchFlags attribute in the Attribute Editor window.
- Input decimal value 128, then click OK to save.
(Notice the searchFlags attribute value now displays 0x80 = (CONFIDENTIAL).)
- Finally, click OK to close the Attribute Properties window.
If the searchFlags attribute is already populated, you will need to perform a bitwise calculation to input the correct number. You can also find more information about searchFlags allowed values on Microsoft’s site at Search-Flags attribute – Win32 apps | Microsoft Learn.
Delegating Access
For an account to read a confidential attribute, it must be delegated the “Control_Access” permission on the attribute. To delegate access, I used the Directory Services Access Control Lists (DSACLS) command-line tool. DSACLS is a powerful tool for managing Access Control Lists (ACLs) on AD objects. For example, I am using a service account called _svcAcctClass that I will delegate “Control_Access” permissions to read the accountClassification attribute on the People organizational unit, with inheritance to child objects only. You can read more about DSACLS at Dsacls | Microsoft Learn.
- Open an elevated command prompt as a Domain Admin.
- Type the following command to allow the service account to read the accountClassification confidential attribute by granting “Control_Access” permissions on OU=People with inheritance to child objects only.
Dsacls OU=People,DC=MyLabDomain,DC=Org /G MyLabDomain\_svcAcctClass:CA;accountClassification /I:S
Validation
To confirm that the attribute is now hidden from non-delegated users, I created several test accounts and set values for the accountClassification attribute. I then ran the same PowerShell query as a normal user and as the account to which I delegated “Control_Access” permission with inheritance to child objects only. You can see the query along with the different results between the two accounts below.
Query Results as a Non-Delegated User
name objectclass accountClassification ---- ----------- --------- Testuser100 Sample100 user Testuser101 Sample101 user Testuser102 Sample102 user Testuser103 Sample103 user Testuser104 Sample104 user
Query Results as the Delegated Account
Name objectClass accountClassification ---- ----------- --------------------- Testuser100 Sample100 user Full-Time Testuser101 Sample101 user Full-Time Testuser102 Sample102 user Terminated Testuser103 Sample103 user Part-Time Testuser104 Sample104 user Intern
The query results show that non-delegated users are unable to view the attribute values. However, the service account can retrieve the values because it was delegated the “Control_Access” permission.
Summary
The Pre-Windows 2000 Compatible Access group granted all users read access to all user and group properties. Because of this, it is not recommended to store sensitive information within AD. However, there may be specific custom extensions that need to be hidden from general users. Using the confidentiality bit, administrators can hide information from unauthorized users and supply granular access as needed to delegated accounts. The confidentiality feature overrides the default “READ_PROPERTY” permission granted by the Pre-Windows 2000 Compatible Access group. It is always best practice to test and confirm in a lab environment before making changes in production. Also consider any impact this setting may have on other applications that need to read the confidential attribute. Lastly, document and track any changes made to attribute permissions; this will make it easier to troubleshoot any issues that arise in the future.
Need guidance on managing permissions in your AD environment? Contact the experts at Ravenswood Technology today. We’re here to help!
