We all know Azure AD as a home for our user and group objects, sourcing from on-premises directories. To match an on-premises user to a synchronized user, a “relationship” is needed, this is referred to as the sourceAnchor. The sourceAnchor attribute helps Azure AD Connect (the Synchronization Engine) to perform a hard match between on-premises objects in Active Directory Domain Services (AD DS) and objects in Azure Active Directory. One of the requirements of this matching attribute is that it does not change during its lifetime and is unique in both the on-premise directory and Azure AD.
The standard for this hard matching defaulted to the objectGUID over the past few years, however there were other possibilities. Beyond Azure AD Connect version 1.1.553.0 things have changed. Microsoft now suggests using a completely different attribute when you upgrade/install Azure AD Connect. In fact, the proposition is made to let Azure AD chose the sourceAnchor for you… Kind of creepy right?
What Azure AD Connect will do is use a different Active Directory attribute called mS-DS-ConsistencyGuid. Why would we want to use this attribute and say farewell to our beloved objectGUID? There are some valid points:
- Cross-Forest migration scenario’s: when you are planning to migrate your users towards another AD Forest, 1 big pitfall comes into play. User matching will break! When a user is migrated (with ADMT for example), this user gets a new objectGUID in the new Forest. Problem! We need to perform some correcting actions so that Exchange Online mailboxes and such don’t get into trouble. mS-DS-ConsistencyGuid is an attribute that can be migrated along with other user attributes and thus corrective action is no longer needed.
- When, for some obscure reason, AD Recycle Bin is not enabled within a forest, problems will occur when restoring deleted objects. The simple reason: resurrection will not include the objectGUID!
Good to know: in case you have federated your Office 365 domains with ADFS, Azure AD Connect will update the AD FS Issuance Transform Rules for this Relying Party to accommodate the use of mS-DS-ConsistencyGuid. Also be aware that a removal of the Office 365 Relying party is not a good idea anymore after the switch to mS-DS-ConsistencyGuid. Use the Azure AD Connect wizard instead!
Some prerequisites apply: no previous usage of mS-DS-ConsistencyGuid (very unlikely), the Service Account used for synchronization needs delegated permissions to write to the mS-DS-ConsistencyGuid. The script below can be used for this purpose:
$ForestDN = "DC=DOMAIN,DC=COM"
$cmd = "dsacls '$ForestDN' /I:S /G '<code>"$accountName
Invoke-Expression $cmd | Out-Null