Azure AD – sourceAnchor you say?

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:

  1. 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.
  2. 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:

$accountName = "DOMAIN\ACCOUNT" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory
$cmd = "dsacls '$ForestDN' /I:S /G '<code>"$accountName

Invoke-Expression $cmd | Out-Null
More information:

Share this post on

Author: Anthony Van den bossche

Anthony Van den bossche
Within my Technical Consultant role, I advise customers concerning (Hybrid) Identity topics such as Azure AD, WAP, ADFS, Certificate Services, Domain Services and others. "Better to be a geek than an idiot."

Leave a Comment

All fields are required. Your email address will not be published.