Did you also give the AADConnect account:
Replicate Directory Changes
Replicate Directory Changes All
at the root for the Password Hash Sync requirement?
If you add the account to Domain Admins as a test, I assume it works yes?
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Hello,
We currently installed Azure AD Sync connect and everything seems to be synching well except for a 8344 "Insufficient access rights to perform the operation". We did a custom install where it only syncs a specific OU / group.
-We are doing only PW Hash Synchronization
-Users are getting their pws synced for the few that we are doing, pw changes, take effect too,
-During AD Forest account we selected create a new ad account
-We used users are represented only once across all directories
-Let azure manage the source anchor was selected
Again all the passwords are synching good but when I open Synchronization service manager I get the above error. When I click on the user error I see it has a change under "ms-ds-consistencyGuid" which I believe is the change it is having issue writing back to our active directory. Is there an easy way to fix this?
EDIT:
Finally it is fixed! After I started checking the security permissions for the root domain I noticed the OU for our users didn't have the security permissions for the MSOL service account at all.
The users OU had inheritance disabled. After I enabled inheritance for that particular OU, the permissions instantly appeared for the service account and the problem was fixed.
Did you also give the AADConnect account:
Replicate Directory Changes
Replicate Directory Changes All
at the root for the Password Hash Sync requirement?
If you add the account to Domain Admins as a test, I assume it works yes?
As I checked somehow the "mS-DS-ConsistencyGuid" is visible in the attribute editor of a user account but the below script of assigning the rights to modify/write that attribute for MSOL_ account doesn't work. Even if the permission inheritance is enabled. What's more the mS-Ds-ConsistencuGuid is visible in the attribute editor of an account but it is not visible in the Security\EffectivePermissions. Maybe too old AD controller, maybe not updated schema. Have no idea. But I've found the workaround. Instead of fighting the permissions, I take a look at the Azure Synchronization Manager - synchroinization error details. I've found what the old and the requested/new value of the "ms-Ds-ConsistencyGuid" the service wants to set but cannot due to the "insufficient rights error". So I've opened the problematic user properites, went to the Attribute Editor, found the ms-Ds-ConsistencyGuid attribute and set it manually to the binary string specified in the error details. Next, I've run the sync manaully by using PowerShell script and the problem was solved. Workaround but works well. In my case I had such issue only with some accounts not all of them. Have no idea why.
So I checked the three users I am having the issue with and they already have enabled inheritance so that's not the issue.
I also do not have any other option besides password hash synching. I do not have write back enabled and I do not have SSPR in azure enabled. Understood on the group filtering, we are testing to make sure everything works perfectly before we synch everyone.
As a test I temporarily added the service account to the admin group and it added the ms-ds-consistencyguid to the users with previous errors. I then added 3 new users to synch, removed admin to the service account and it went back to giving me the permission issue. Is it possible I have to give write permission to the azure ad account for ms-ds-consistencyguid?
For this feature to work, the AD DS account used to synchronize with on-premises Active Directory must be granted write permission to the ms-DS-ConsistencyGuid attribute in on-premises Active Directory.
Thanks for the article. I'm trying to give permission to the service account with the below powershell script:
$accountName = "domain\MSOL_nnnnnnn" $ForestDN = "DC=do,DC=domain,DC=local" $cmd = "dsacls '$ForestDN' /I:S /G '"$accountName
":WP;ms-ds-consistencyGuid;user'" Invoke-Expression $cmd | Out-Null
however when I try to run it in powershell where I have azure ad connect it tells me At line:1 char:41 $accountName =domain\MSOL_nnnnn" etc etc unexpected token $ForestDN in expression or statement and same for Invoke-Expression.
I have only used powershell a few times so not sure if I am supposed to run it line by line or save it to a script file and then run it?
Any help would be appreciated.