We need to grant a service ID the Replicating Directory Changes to Active Directory. People are concerned that we might accidentally let the service ID write data in Active Directory, or have somebody abuse the service ID and change Active Directory data.

Does somebody know what rights are part of "Replicating Directory Changes?"



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.

  • 1
    So, it "enables the discovery of objects in the domain within the Active Directory forest." Sounds a lot like "read." – Jim May 3 '11 at 18:58

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:



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:


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).


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.

  • 1
    We have a fairly standard AD implementation, and a number of the attributes you have listed are readable by ordinary users: userAccountControl, pwdLastSet, lockoutTime, accountExpires (much of this info is returned by NET USER <username> /DOM, too) – JMusgrove May 20 '16 at 9:26

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


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

$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 :


  • Just to note that such elevated rights are associated with Replicate Directory Changes ALL, which is a separate permission. Only Domain Controllers, Domain/Enterprise Admins, System and password sync service accounts (such as AAD Connect w/ password writeback) should have RDC ALL. Those accounts have limited permissions at the domain root, except Enterprise Admins (which should usually be empty). e.g. AAD Connect has Read/Write All Properties to descendent users/contacts/computers/groups, not everything – LeeM Dec 1 '20 at 4:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.