What rights does "Replicating Directory Changes" actually grant in Active Directory?

The existing answer didn't satisfy my curiosity and I didn't want people getting more than they needed from my directory. So I did a little more digging.

Main Info here:

http://support.microsoft.com/kb/891995

Breakdown:

If you want to synchronize your program's database with AD (like sharepoint/FIM) you have two ways of asking AD what's changed since your last query.

You can use the "DirSync" control (LDAP protocol extension) OR you can go kinda ghetto and just use uSNChanged polling - but there are limitations there.

"A DirSync control search returns all the changes that are made to an Active Directory object regardless of the permissions that are set on the object." It will even return tombstoned objects.

So to use the DirSync LDAP control you need the "Replicating Directory Changes", or be a domain admin.

From what I was able to gather, the only thing scary is that they can pretty much read anything in the directory partition, regardless of standard permissions. They cannot change anything.

However - you may have some attributes that are senstivite in your directory.

More on the DirSync Control Extension here:

https://msdn.microsoft.com/en-us/library/ms677626(v=vs.85).aspx

True Test: Connecting to AD using the DirSync control

And here's the true way for you to find out for yourself. This guy is the man. If you want to see for yourself - adapt this powershell example, run it as the user you granted the right to, and query for a user object (or something else).

http://dloder.blogspot.com/2012/01/powershell-dirsync-sample.html

I checked with our Sharepoint account to see what I could get back. Before I granted the permission, I got an access denied exception when trying to use the DirSync control.

Once I did I got back almost everything on a user account:

Notable security related attributes that came back in a user query that I'm pretty sure you can't normally see without elevated permissions:

• userAccountControl
• userparameters
• msexchuseraccountcontrol
• pwdlastset
• unicodePwd (BLANK. So no hashed domain pw is returned)
• lockouttime
• accountexpires
• unixuserpassword (YIKES. If you are using this - it IS visible but it's hashed. Do some reading here if you are paranoid or use services for unix password sync.)

I also checked out a computer account that had a bitlocker recovery password attached to it and that attribute was not available in the returned results.

If you ever had Services for Unix in your environment and synced pw's - you could have leftover data in here. One of our users that had been around for a long time had this set on his account. It's feasible that cracking this pw could lead to a current day password by just trying variations on it.

This had been removed from our environment, so newer users didn't have any data here.

http://support.microsoft.com/kb/303972

Note Using either method, setting the Replicating Directory Changes permission for each domain within your forest enables the discovery of objects in the domain within the Active Directory forest. However, enabling discovery of the connected directory does not imply that other operations can be performed.

To create, modify, and delete objects within Active Directory using a non-administrative account, you may need to add additional permissions as appropriate. For example, for Microsoft Metadirectory Services (MMS) to create new user objects in an Organizational Unit (OU) or container, the account that is being used must be explicitly granted the Create All Child Objects permission, as the Replicating Directory Changes permission is not sufficient to allow the creation of objects.

In a similar fashion, the deletion of objects requires the Delete All Child Objects permission.

It is possible that there are limitations on other operations, such as attribute flow, depending on the specific security settings that are assigned to the object in question, and whether or not inheritance is a factor.

As a matter of fact "Replicating Directory Changes" permission does not grant DCPROMO rights nor it is possible to use this permission to pull back hashed values of user's password.

In order to gain access to user's password hashes it is necessary to grant "Replicate Directory Changes All". For more information see https://social.technet.microsoft.com/Forums/windowsserver/en-US/cc72be66-30c4-420e-8de3-9085858037bc/difference-between-replicating-directory-changes-replicating-d

To delegate the service to replicate in Active Directory, you have to enable the send as and receive as delegation.

In case it's helpful to someone, I re-wrote the referenced script to query a separate domain other than the one the current machine is on:

Add-Type -AssemblyName System.DirectoryServices.Protocols

#defaults
$RootDSE = [ADSI]"LDAP://RootDSE"
$dcHostName = $RootDSE.dnsHostName
$distinguishedName = $RootDSE.defaultNamingContext

#or use the lines below for another DC on another domain
$dcHostName = "dc1.contoso.local"
$distinguishedName = (Get-ADDomain "contoso.local").DistinguishedName

$LDAPConnection = New-Object System.DirectoryServices.Protocols.LDAPConnection($dcHostName) 
$Request = New-Object System.DirectoryServices.Protocols.SearchRequest($distinguishedName, "(objectclass=*)", "Subtree", $null) 
$DirSyncRC = New-Object System.DirectoryServices.Protocols.DirSyncRequestControl($Cookie, [System.DirectoryServices.Protocols.DirectorySynchronizationOptions]::IncrementalValues, [System.Int32]::MaxValue) 
$Request.Controls.Add($DirSyncRC) | Out-Null 

$MoreData = $true

while ($MoreData) {

    $Response = $LDAPConnection.SendRequest($Request)

    $Response.Entries | ForEach-Object { 
        write-host $_.distinguishedName 
    }

    ForEach ($Control in $Response.Controls) { 
        If ($Control.GetType().Name -eq "DirSyncResponseControl") { 
            $Cookie = $Control.Cookie 
            $MoreData = $Control.MoreData 
        } 
    } 
    $DirSyncRC.Cookie = $Cookie 
}

The biggest risk of abuse (IMO) this right has is that it can be used to impersonate a DCPROMO. It appears to be possible to use this permission to pull back hashed values of the password, which is just a short step away from all kinds of attacks.

There's a really good example that demonstrates some misuse of the Replicating Directory Changes permission over on dsinternals.com :

https://www.dsinternals.com/en/retrieving-active-directory-passwords-remotely/