Quick Summary
The Replicating Directory Changes right in Active Directory allows you to request information out of Active Directory in ways that bypass some normal LDAP permissions. But it is one of three separate rights. While Replicating Directory Changes - All allows attackers to harvest everything out of Active Directory (including password hashes), accounts with just the Replicating Directory Changes right may be able to pull other sensitive information from Active Directory even when administrators think it is safe in confidential attributes. The type of leaked information depends on what information you have stored in Active Directory and in what attributes. Knowing what information is being stored in which specific confidential attributes and who has the Replicating Directory Changes right is important for preventing attackers from gaining access to the information you believe is hidden in Active Directory.
Full Article
You may not know it, but if you ever used the lsadump::dcsync feature of mimikatz, you’ve used a specific set of rights in Active Directory called Replicating Directory Changes. You may have thought mimikatz was able to get the information only because you were using a Domain Admin account or an account in the built-in Administrators group. In actuality, it was because the account you used had two of three possible special rights: Replicating Directory Changes and Replicating Directory Changes - All. In addition to those two, there is a third option, Replicating Directory Changes in Filtered Set. How these different rights work is not often understood, nor is the potential security implications of all of them.
An identity with these rights has the ability to pull information out of the directory in a manner similar to how domain controllers replicate data between each other. The rights are often set on applications that want to be able to get just the AD data that has changed since the last time the application made the same request. The most common example application is the Azure AD Connect sync which replicates data between on-prem AD environments and Azure AD. These DirSync requests can be made over LDAP or through RPC calls and grant the ability to read information, not make changes.
The Replicating Directory Changes Right
The first right is Replicating Directory Changes. This is the base level right and without it, the other two options will not work. It is the most restricted in what data it can request. Most importantly, this right does not allow the syncing of account password hashes. However, it still allows the syncing of all regular attributes and many confidential attributes.
Confidential attributes were introduced with Windows 2003 SP1 as a means of hiding the information in some attributes from normal users. By default, everything in AD is readable by any account that has authenticated to AD. The confidential bit forces a secondary check against a CONTROL_ACCESS permission (which is typically only held by administrators). In a freshly promoted domain, there are 22 confidential attributes. Installing LAPS adds another. Identifying the confidential attributes can be done by looking if the 7th bit (128 or 0x80) is set on the searchFlags attribute on objects in the schema. For simplicity's sake, you can run the following command:
Get-ADObject -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=128))" -properties * | select lDAPDisplayName,SearchFlags | ft -AutoSize
It will return something like the image below.
To make things more interesting, some confidential attributes are protected by even further extended rights in AD. Normally, this enhanced security is on password-like attributes created by Microsoft. Examples include the LAPS password (ms-Mcs-AdmPwd), and BitLocker information (msFVE-RecoveryPassword and msFVE-KeyPackage). These attributes can not be pulled through a sync by an account that only has the Replicating Directory Changes right.
The Replicating Directory Changes in Filtered Set Right
The next right that offers the ability to sync information is Replicating Directory Changes in Filtered Set. While this right still does not allow the syncing of account password hashes, it grants access to more attributes. It allows the holder to request all regular attributes and any confidential attributes that are also in the Read-Only Domain Controller (RODC) filtered attribute set. You can find these attributes by seeing if the 10th bit (512 or 0x200) in the searchFlags attribute on schema objects is set as well as the confidential bit being set. The AD cmdlet PowerShell command for this is:
Get-ADObject -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=640))" -properties * | select lDAPDisplayName,SearchFlags | ft -AutoSize |
The Replicating Directory Changes - All Right
Finally, we get to the last of the three DirSync rights: Replicating Directory Changes - All. This allows the syncing of any information out of the domain, including password hashes. In a default configuration, only Domain Controllers and members of the built-in Administrators group have this right. If you use the Azure AD Connect server, its service account also has this right.
Putting It All Together
In order to demonstrate the difference between the different rights, I have set up a small lab environment.
Three groups have been granted different levels of access at the root of the domain.
Looking at the members of those groups, we see that the following users have specific rights through their group membership:
Finally, they are using LAPS and storing passwords for some user accounts in the unixUserPassword attribute. An example of an account is shown below.
The admins of the lab.pvt domain haven’t given anyone access to see LAPS passwords and also feel that storing passwords in unixUserPassword is safe as it is a confidential attribute. Their thoughts appear valid as when other users look at the unixuser account with standard LDAP tools (such as Active Directory Users and Computers, LDAP search tools, or through PowerShell), they don’t see any information. In the example below, only the Domain Admin, da1, has the ability to see the information (which has not been translated from a byte array).
However, the responses from the domain controller change when we run a PowerShell script that uses the .NET LDAP DirSyncRequestControl class instead of a normal LDAP request. In the picture below, we see that a normal user, user1, doesn’t have the appropriate rights to use DirSync. However, both the Domain Admin and an account, repdir, that has the Replicating Directory Changes right receive the password for the unixuser account (my script translated the byte array back to clear text).
Even though I only showed the repdir account, the other two accounts with the additional DirSync rights would also be able to see the same information.
This environment also shows the difference between the Replicating Directory Changes and Replicating Directory Changes in Filtered Set rights. As I mentioned earlier, the LAPS password (stored in the ms-Mcs-AdmPwd attribute) is a confidential attribute that is also protected by special extended rights. Therefore, when we use my LDAP DirSync script, only the Domain Admin and the repdir-fil accounts get the information back. Our account that only has Replicating Directory Changes is denied access as it hasn’t been granted the extended right.
In Conclusion
Overall, granting accounts any of the Replicating Directory Changes rights adds some level of risk to the environment. The dangers of Replicating Directory Changes All is well documented. Any accounts with that level of access have the ability to see password hashes for all accounts in the domain. An attacker who gains this level of access has compromised the entire environment. The other two levels of rights aren’t as cut and dry. It depends on what information is being stored in your directory, in what attributes, and how those attributes are configured within AD.
Links
If you’d like to see or use my LDAP DirSync script it can be found on github. This script was built off of one I found from Ondrej Sevecek that shows how to call the LDAP DirSync functionality in PowerShell. Be aware that DirSync will not return constructed or backlink attributes (such as canonicalName and memberOf). In addition, this script cannot be used to get password hashes for accounts, even if you have the Replicating Directory Changes All right. Domain Controllers don’t expose that information through LDAP, only RPC. You’ll just have to continue to use Benjamin’s mimikatz.
If you want to read more on confidential attributes, searchFlags, the RODC filtered attribute set, etc, here is a slew of links from Microsoft.
https://docs.microsoft.com/en-us/windows/win32/adschema/a-searchflags
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/mark-attribute-as-confidential
https://docs.microsoft.com/en-us/windows/win32/ad/rodc-and-active-directory-schema