Older versions of Azure AD Connect used the objectGUID attribute as the source anchor. In many cases, this is a good choice because it is an attribute that doesn't change. However, in complex configurations with multiple AD forests, this can cause an issue during migrations. When a user account is moved from one AD forest to another, it gets a new objectGUID in the new forest. Due to the new objectGUID , Azure AD Connect treats the user as a new user instead of an existing user.
To avoid this issue, we need to use an attribute for source anchor that can be moved between forests. Microsoft now recommends that deployments of Azure AD Connect use the mS-DS-ConsistencyGuid attribute as the source anchor. Unlike objectGUID , this attribute can be modified. So, it can be maintained when users are moved between forests.
I've just recently completed this process and I'll provide some general guidance (for my own reference) and a few items that I didn't see anywhere else.
Updating the Source AnchorFirst, read the information from Microsoft on updating the source anchor. You'll need to scroll down a bit to the heading "How to enable the ConsistencyGuid feature - Existing deployment".
- Require you to enter Azure AD credentials for a global admin
- Require you to enter a user account with AD FS admin permissions (if integrated with AD FS)
- Do a prerequisite check
- Update necessary settings in Azure AD
- Update necessary settings on connectors for all connected forests
- Update AD FS claim rules
Note: The wizard does not ask you which attribute you want for the source anchor. It is assumed that you want to use mS-DS-ConsistencyGuid.
Change DetailsWhen the wizard is done, a full sync is triggered for all connected forests. As part of the full sync Azure AD Connect reviews the value of the mS-DS-ConsistencyGuid attribute. If the value is blank, the objectGUID value is copied into the mS-DS-ConsistencyGuid value. Then on the next sync cycle the mS-DS-ConsistencyGuid value is sent to Office 365.
If you are using AD FS, the wizard updates the AD FS claims rules for Office 365. I didn't do a detailed review of the rules, but it seems to be similar (if not the same) as the rules Microsoft documents for you to make manual changes. You can see these rules here:
Permissions to mS-DS-ConsistencyGuidIf you have let the installation and configuration wizards for Azure AD Connect manage all of the service account permissions and AD FS integration, there should be no issues. However, if you've been manually configuring the permissions and AD FS rules, you might need to make changes manually.
The only permission change required when changing the source anchor is ensuring that the service account in each domain has read and write permissions to the mS-DS-ConsistencyGuid attribute. Unfortunately when you attempt to assign these permissions by using Active Directory Users and Computers, you find out that the attribute is not displayed in the GUI for modifying permissions. To set the permissions, use the following command (please note that this is a single line):
dsacls.exe "dc=contoso,dc=com" /I:S /G "contoso\serviceaccount:RPWP;mS-DS-ConsistencyGuid;user"The above command grants (/G) inheritable (/I:S) permissions to the service account to read (RP) and write (WP) the mS-DS-ConsistencyGuid attribute on user objects.
Verifying Successful ImplementationObviously after a successful implementation, your users can still sign in to Office 365, but there are a few other things you can verify:
- Review the AD FS claim rules for Office 365 and verify that they were modified.
- Review the mS-DS-ConsistencyGuid attribute on several user objects to verify that it has been populated.
When viewing the value of the mS-DS-ConsistencyGuid attribute in Active Directory Users and Computers, the value might be displayed in special characters for some users. This is a display error in Active Directory Users and Computers. This is not something you need to fix.
For Further Reading
- Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 1
- Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 2
- Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 3