What to Use as the “sourceAnchor” Attribute in Azure AD Connect
In Azure AD Connect, the sourceAnchor attribute connects an on-premises object to a cloud object. It ensures that a hybrid object has the same identity both on-premises and in Azure. After the sourceAnchor attribute has been set, it is best practice to avoid updating the sourceAnchor attribute value unless it is absolutely necessary to do so. Attributes such as UserPrincipalName or email, for example, should not be used, since they can change if a user’s user name or email changes.
Even though it is best practice to avoid changing the sourceAnchor attribute value, unplanned situations such as accidental user deletion may require you to edit the value on-premises to match the on-premises user object with the cloud user object. This is why you should use the ms-DS-ConsistencyGuid attribute, which is writable, as the sourceAnchor attribute.
The on-premises sourceAnchor (either ms-DS-ConsistencyGuid or ObjectGUID) must always match the ImmutableID in the cloud. The naming is a bit confusing because the cloud and on-premises attributes have the same value, but the Azure AD representation is called the “ImmutableID” and the on-premises version is called the “sourceAnchor.”
The recommended approach is to install the latest version of Azure AD Connect and use the ms-DS-ConsistencyGuid (shortened to “ConsistencyGuid” in some documentation) as the sourceAnchor attribute. For versions 1.1.524.0 and later, the default attribute is already set to the ms-DS-ConsistencyGuid.
In the past, Azure AD Connect selected the ObjectGUID as the default sourceAnchor attribute for synchronizing objects to Azure AD. The wizard selected “ObjectGUID” because it is a globally unique value. But the disadvantage of using ObjectGUID is that it is not writable and can cause problems in cases of accidental user deletion or multi-forest migration where there is no trust between forests. (Both of these problems and their solutions are documented thoroughly in Sander Berkouwer’s blog, ObjectGUID vs. ms-DS-ConsistencyGuid, Part 1).
The main advantage of ms-DS-ConsistencyGuid is that it does not require you to change the cloud user’s ImmutableID in order to solve “user mismatch” issues. Instead, you can take the ImmutableID from the cloud user, convert it into a hex value, and copy it into the ms-DS-ConsistencyGuid value. Then, after editing any user attributes that need to change, you can synchronize the on-premises user to the cloud and the sourceAnchor (ms-DS-ConsistencyGuid) will match the ImmutableID. This new configuration ensures that the source of truth remains with the on-premises user.
The best tutorial and explanation I have seen for this process is SecureCRC’s Fixing Hybrid-User Sync Issues with Azure AD Connect video.
Going forward, here are the settings needed to select ms-DS-ConsistencyGuid as the sourceAnchor attribute using Azure AD Connect:
For existing environments that are already using ObjectGUID:
Go to Azure AD Connect > Configure > Configure Source Anchor > Next
The option to “Configure Source Anchor” will only appear if your sourceAnchor is already set to ObjectGUID. If this does not appear, then you already have ms-DS-ConsistencyGuid set as the sourceAnchor. (You can confirm this on the “Review Your Solution” page.)
When you step through the wizard and select “Configure”, the ms-DS-ConsistencyGuid will be set as the sourceAnchor and updated with the ObjectGUID values.
For “Express” installation in a new environment:
If you are using Express installation, Azure AD Connect will select the ms-DS-ConsistencyGuid by default as long as the attribute is not already populated. If the attribute is already in use, the wizard will still select ObjectGuid.
For “Custom” installation in a new environment:
Please ensure that you select “Let Azure manage the sourceAnchor for me”, rather than overriding it by selecting a specific attribute. This way, Azure will automatically select ms-DS-ConsistencyGuid for all users.
