Quick post to describe a common layer-8 issue.
You’ve installed Azure AD Sync Services (AADSync) 1.0.0470.1023 (or later) and have setup password hash synchronisation, i.e. you are synchronising users and their passwords as opposed to creating federated users.
Password synchronisation doesn’t appear to be working and you find the Event ID 611, source Directory Synchronization, in the event log:
Here’s the text:
Password synchronization failed for domain: emeads.abstractsynapse.com. Details:
Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsException: RPC Error 8453 : Replication access was denied. There was an error calling _IDL_DRSGetNCChanges.
at Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsRpcConnection.OnGetChanges(ReplicationState syncState)
at Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsConnection.GetChanges(ReplicationState replicationState)
at Microsoft.Online.PasswordSynchronization.RetryUtility.ExecuteWithRetry[T](Func`1 operation, Func`1 shouldAbort, RetryPolicyHandler retryPolicy)
at Microsoft.Online.PasswordSynchronization.DeltaSynchronizationTask.SynchronizeCredentialsToCloud()
at Microsoft.Online.PasswordSynchronization.PasswordSynchronizationTask.SynchronizeSecrets()
at Microsoft.Online.PasswordSynchronization.SynchronizationExecutionContext.SynchronizeDomain()
at Microsoft.Online.PasswordSynchronization.SynchronizationManager.SynchronizeDomain(SynchronizationExecutionContext syncExecutionContext).
In order to synchronise credentials the Active Directory Domain Services connector (management agent) account needs both of the following extended rights assigned on each in-scope domain naming context/partition:
- Replicating Directory Changes
- Replicating Directory Changes All
In my case I had only granted Replicating Directory Changes All which was insufficient. Here’s a screenshot of the permissions assignment using the Active Directory Domain Services (AD DS) Users and Computers MMC snap-in. I’ve granted these control access rights directly to a principal called SVCAADSYNCCON:
Once the permissions are correctly assigned you can wait for scheduled synchronisation to occur or you can manually invoke via C:\Program Files\Microsoft Azure AD Sync\Bin> .\DirectorySyncClientCmd.exe [initial | delta] and you should subsequently see Event ID 656, source Directory Synchronization that describes successful synchronisation of credentials (excuse the misspelling of the Terminator):
Hope this helps.
Hybrid Identity 
Thanks for this, very useful 🙂
This piece of software is a nightmare. We’re getting this issue using AADSync. Why can Microsoft not just make an application that works like it says without us having to trawl through Google to find blogs such as yours (which are brilliant)?
@ Gareth E, why don´t you just read the manual before your install it? it clearly describes the requirement:
If you want to enable password synchronization between your on-premises AD DS and your Azure Active Directory for your users, you need to grant the following permissions to the account that is used by Azure AD Sync to connect to your AD DS:
• Replicating Directory Changes
• Replicating Directory Changes All
Both permissions are required to enable the account to read password hashes from your on-premises AD DS
https://msdn.microsoft.com/en-us/library/azure/dn757602.aspx
Cheers Peter
Great post! You are the only one that I’ve seen reference the DirectorySyncClientCmd.exe tool, so I have to ask, is there a way to change the registry like you could with previous versions and set the “FullSyncNeeded” registry key to 1 in order to force a full sync? I’m not seeing this key, and I’m guessing that they removed the DirSync powershell module, too?
I don’t know but will look into it and come back and answer here.
Thank you!
Worked like a charm after assigning the permissions.
Hi,
Where exactly do you set these permissions ? In AD Users and Computers at the root of the domain ? I did and also checked to this object and all its descendants and I still get the same message …
Thanks in advance,
I’m in the same boat Marc….here’s my post from TechNet .. have not found a solution yet! I did the same w the permissions at the domain root- no difference
**************************************************************************************************************
Hello all…..Getting quite frustrated here. I have an Office 365 Subscription…and simply want to sync my single domain on-prem users with Office.
I have verified our domain – mycompany.org in the 365 portal
On-prem domain is mycompany.local
I could not change our users UPN suffix to use the .org because of other on-prem applications so elected to use Alternate ID – the mail attribute…. which is user@mycompany.org anyway.
Users sync fine but the password sync does not work. I’ve done all the “Google” fixes below:
Assigning Replicating Directory Changes \ Replicating Directory Changes All perms to the local on-prem sync account.
Restarting
Run full initial sync many times- then trigger a PW sync
Reinstalling Azure AD Connect
Firing off a password sync with the well known script that is out there.
http://social.technet.microsoft.com/wiki/contents/articles/28433.how-to-use-powershell-to-trigger-a-full-password-sync-in-azure-ad-sync.aspx
Using the latest AAD Connect on a healthy Win 2012 R2 DC
This is the 611 event I get below… would appreciate any help..greatly! I thought this would be straight forward as the only caveat in my environment is that my user UPNs don’t match the Alternate ID attribute, in my case, mail. But from what I’ve read, there should be no issue – that’s what the Alternate ID is for.
Thanks in advance …Dennis
Password synchronization failed for domain: mycompany.local.
Details:
Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsException: RPC Error
8453 : Replication access was denied. There was an error calling _IDL_DRSGetNCChanges.
at Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsRpcConnection.OnGetChanges(ReplicationState
syncState)
at Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsConnection.GetChanges(ReplicationState
replicationState)
at Microsoft.Online.PasswordSynchronization.RetryUtility.ExecuteWithRetry[T](Func`1
operation, Func`1 shouldAbort, RetryPolicyHandler retryPolicy)
at Microsoft.Online.PasswordSynchronization.DeltaSynchronizationTask.SynchronizeCredentialsToCloud()
at Microsoft.Online.PasswordSynchronization.PasswordSynchronizationTask.SynchronizeSecrets()
at Microsoft.Online.PasswordSynchronization.SynchronizationExecutionContext.SynchronizeDomain()
at Microsoft.Online.PasswordSynchronization.SynchronizationManager.SynchronizeDomain(SynchronizationExecutionContext
syncExecutionContext)
.
mycompany.local
e24bc652-06a9-4fc9-bac5-5d43921f8ad1
The permissions are not permissions per-se, they are control access rights. The easiest way to set them is using ADU&C. Use the basic/immediate GUI and not the advanced UI. There should be no inheritance flags set. As I show in the post you require BOTH replicating directory changes and replicating directory changes all. You must do this at the root of each domain in the forest that you want to sync.
It is important to call out that you grant the permission to the account used by the Active Directory connector and not the service account of AAD Connect. Here’s a PowerShell one-liner to get the AD DS connector account name – this is the account that needs the permissions.
(Get-ADSyncConnector | ? { $_.Type -eq ‘AD’ }).ConnectivityParameters | ? { $_.Name -eq ‘forest-login-user’ } | select -ExpandProperty Value
I actually solved my problem. The issue was that the account used to do the sync wasn’t in the local administratifs groups. After adding it back all passwords started to sync again.
Envoyé à partir de mon Windows Phone ________________________________
There’s no requirement for that. Adding it must have granted you a missing permission. Are you talking about the local administrators group on the AAD Connect server? Or are you referring to the built-in administrators group within the domain?
The AAD Connect server is a Domain Controller so it was the built-in administrators group …
Your blog post was exactly what I needed…thank you!
Very useful, thanks. It came up first in Google. It seems to be a cut and paste of https://blogs.technet.microsoft.com/iamsupport/2014/10/29/rpc-error-8453-replication-access-was-denied-in-azure-ad-sync-services-aadsync/ but it doesn’t matter as long as it works.