Using the mS-DS-ConsistencyGuid attribute to fix sync issues to Office 365/AAD.
By Cesar Hara, Victor Santana and Caio Cesar
Greetings everyone!
Today we are going to cover a very interesting way to troubleshoot user synchronization issues to Office 365 (Azure Active Directory). The method consists of using the attribute: “mS-DS-ConsistencyGuid”.
We recommend going through this article for a better understanding of what is being discussed in this post.
As many of you know, historically, AD Connect used to choose “ObjectGUID” as the sourceAnchor attribute to sync objects to the cloud. Starting on version 1.1.524.0, we can use mS-DS-ConsistencyGuid instead.
What is the big deal with it? Unlike ObjectGuid, this attribute is writable. This means we can manipulate synced objects easier.
Recently, customers started to raise tickets related to this matter. We were able to fix these incidents without causing service disruption to the end users, scenarios may vary from: “I have a synced multi-forest environment and the user was migrated between them”, “A user was deleted from Active Directory by mistake while AD Connect was not working and we reinstalled it” and “I lost the only DC in my forest, so I had to rebuild my AD forest completely”.
(PLEASE, ALWAYS PROMOTE AT LEAST TWO DOMAIN CONTROLLERS!!)
Pre-requisites: You will need to have access to AAD PowerShell connected to your tenant (with global admin permissions), AD Connect Server and access to the Domain Controller.
Scenario 1:
“A user was deleted from AD by mistake while AD Connect was not working. We created a new account since we cannot recover the old one and then we reinstalled AD Connect, but the changes performed on local Active Directory object are not syncing to the cloud account.”
NOTE: There are other possible scenarios, this is only one of the scenarios we have seen.
Understanding the problem:
• As AD Connect was down, the removal of the user was not “picked” by AD Connect.
• As a result, this deletion did not occur in AAD. This means the account is orphan in AAD.
• The new account has a new on-prem ImmutableID (originated from ObjectGUID). This attribute cannot be changed in the cloud for synced accounts.
To reproduce this behavior, we have uninstalled AD Connect, deleted the user account from Active Directory and re-installed AD Connect.
To confirm that the problem is with the different ImmutableID, you can follow these steps:
• Get the ImmutableID of the affected account in the cloud:
Get-MsolUser -UserPrincipalName john@cesarhara.com | select ImmutableID
ImmutableID: kKfL2wwI+0W+rN0kfeaboA==
• Perform a metaverse search for the new user created in AD (or convert the ObjectGUID taken from AD into a base64 format with the GUID2ImmutableID tool) to confirm the new ImmutableID:
• If you have attribute resiliency, AD Connect will not show any errors. You can go to the Portal or PowerShell to identify the error:
In summary, any changes we make to this on-prem object will not be reflected to the cloud.
Steps to resolve:
1- Confirm that the attribute being used in AD Connect as the “SourceAnchor” is the “mS-DS-ConsistencyGuid”, just run the AD Connect Wizard and choose “View Current Configuration”:
2- Make sure that the “UPN” and “ProxyAddresses” attributes are the same in O365 and AD accounts - you can download the users report in the Admin Portal or use PowerShell to extract this information. These attributes are essential, if you are aware of any other one missing, proceed to add it to the account in your local AD accordingly.
3- Grab the ImmutableID value of the cloud/original account. Here is the cmdlet again:
Get-MsolUser -UserPrincipalName john@cesarhara.com | select ImmutableID
ImmutableID: kKfL2wwI+0W+rN0kfeaboA==
4- We have to convert the value of the “ImmutableID” to a HEX format so we can add it into the on-prem account:
[system.convert]::FromBase64String("kKfL2wwI+0W+rN0kfeaboA==") | %{$a += [System.String]::Format("{0:X}", $_) + " "};$result = $null;$result = $a.trimend();$result
The output is:
90 A7 CB DB C 8 FB 45 BE AC DD 24 7D E6 9B A0
5- Now let’s get back to our AD Connect server and stop the scheduled task (it’s a good practice to do so, avoiding a sync task to run while we are troubleshooting this):
Set-ADSyncScheduler -SyncCycleEnabled $false
6- Move the account to a non-synced OU and run a delta sync (this is required to the match occurs later).
Start-ADSyncSyncCycle -PolicyType Delta
7- In the new account created in ADDS, edit its attributes. Do this by locating the mS-DS-ConsistencyGuid and adding the HEX value from step 2 (if there is a value, AD Connect added the current ObjectGUID value as the default behavior, proceed to add the new one):
8- Move the account back to a synced OU and run a delta sync again, if everything ran as expected the sync would occur successfully.
9- Add or change an attribute in AD to make sure the sync worked as expected. Check in the Portal and the error will be gone:
10- Finally, let’s enable the sync scheduler again:
Set-ADSyncScheduler -SyncCycleEnabled $True
Conclusion:
With this new feature, it is possible to resolve problems that used to be hard to deal with it when using “ObjectGUID”. Regardless the scenario, we must always use the original ImmutableID (already set in the cloud), convert it to an HEX value and add into the “mS-DS-ConsistencyGuid” so the match occurs.
If you are going to migrate accounts between forests make sure to populate in the target forest object “mS-DS-ConsistencyGuid”, the value of the source object “ObjectGUID”.
Comments
- Anonymous
April 02, 2018
Excellent article. - Anonymous
September 11, 2018
** Don't forget to re-enable the syncSet-ADSyncScheduler -SyncCycleEnabled $true- Anonymous
April 17, 2019
Thanks for the tip, I have updated the content.
- Anonymous
- Anonymous
February 09, 2019
The comment has been removed- Anonymous
April 17, 2019
The comment has been removed
- Anonymous