In one of my older posts, I explained the great importance of the ImmutableID attribute for the AADC sync: The ImmutableID Match in AADC environments. So you learned that in the ImmutableID property, the hybrid sync stores a value from the on-premises AD object to ensure the match between the local object and the cloud object. This matching attribute is called the Source Anchor attribute.
And for reasons that you can read in this other post, Microsoft changed its default source anchor attribute from the on-premises objectGUID to the more modern mS-DS-ConsitencyGUID.
But this is only true if you install the Azure AD Connect (AADC) with version 1.1.533.0 and above! If you installed AADC with an older version, the mS-DS-ConsistencyGUID is not used – even if you updated the AADC to the newest version.
So if you still use the old objectGUID source anchor, it’s maybe time now that you switch it to mS-DS-ConsistencyGUID. It’s more flexible, especially if you want to write your own value in the source anchor and control the sync match (e.g. for migrations). The objectGUID is a read-only system attribute – mS-DS-ConsistencyGUID is read-write.
So, first of all, you should check what source anchor attribute is used in your environment at the moment. The easiest way via the GUI: Open the AADC Wizard and review the configuration:
Or via PowerShell (this is a scripting blog after all! 🙂 )
(Get-ADSyncGlobalSettings).Parameters["Microsoft.SynchronizationOption.AnchorAttribute"].Value
Old style….. Ok, let’s change this.
Prerequisites for using mS-DS-ConsistencyGUID (Permissions)
You should check before if your AADC sync account for the on-premises AD access has permissions to read and write the mS-DS-Consistency attribute. This might not be the case if you chose not to use the standard sync account creation in the AADC wizard. If you are not sure about that, check the Sync Service Manager in the Ad connector properties:
If there is a sync account other than ‘MSOL_something‘, you probably use a customized account and you should check / grant the permissions for this account. You can grant the appropriate permissions with the DSACLS.EXE tool:
dsacls "dc=mydomain,dc=com" /I:S /G MYDOMAIN\MSOL_aadcserviceaccount:RPWP;mS-DS-ConsistencyGuid;user
This sets the permissions on the domain root, you could also do this on OU container level. If you get permission denied errors in the Sync Service Manager tool, you did something wrong here….
Prerequisites for using mS-DS-ConsistencyGUID (ADFS Usage)
If you are not running an ADFS for authenticating your O365 users, then you can jump over this topic. But if your O365 tenant is federated with a local ADFS system, then the Wizard will have to do a few changes in the ADFS settings remotely. Because the source anchor plays a role in the claim rules there. Before you do the switch, ensure that the AADC-Server can communicate with the ADFS system over the following TCP ports:
- 80 (http)
- 443 (https)
- 5985 (Windows Remote Management)
After the switch, you better check if your ADFS claim rules have been adjusted to the new source anchor. For the O365 relying party, the old claim issuing rule named “Issue Immutable ID” should be replaced by “Issue msdsconsistencyguid as Immutable ID if it exists“. This rule and a few others related to the source anchor. If this is not the case, you might need to adjust your ADFS claim rules by yourself. Not a problem! Use the ADFSHelp Azure AD Relying Party Trust Claim Generator – it will provide you with the latest valid O365 Claim Rules for ADFS.
Action: Switch from objectGUID to mS-DS-ConsistencyGUID
If you want to switch the source anchor from objectGUID to the new mS-DS-ConsistencyGUID, you do it with the AADC wizard GUI. No rule customizing like in the old days when mS-DS-Consistency was new…. please use ONLY the AADC wizard for this! The source anchor setting is local for each AADC server, so if you have a second AADC (in staging mode, for high availability), then you have to do it on both. Start the Wizard on the AADC server and choose “Configure Source Anchor” from the list of additional tasks.
The wizard does some checks then, and you should see thhe following screen. Note that Microsoft advises you that it would be a good idea to change the source anchor:
If the wizard gives you a warning “Your source anchor configuration cannot be changed because the mS-DS-ConsistencyGUID is already in use……“, then jump to the next section “Already Occupied”.
But normally everything should be fine without warnings. So if you choose next here and let the wizard finish its configuration, you are switched to the modern source anchor. Congratulations:
Already occupied!
If you want to configure your source anchor and you get a message like this:
… then it’s because the check found objects in your existing local AD that have a value set in the mS-DS-ConsistencyGUID attribute. Maybe a holdover from an earlier attempt? Hopefully, these values are obsolete, because otherwise, you will not be able to switch to the modern source anchor in your AADC sync. If you are sure that the existing attribute values are obsolete, then you can clean the objects by erasing the attribute value. Use this PowerShell cmdlet to find the objects in question:
Get-ADObject -Ldapfilter "(mS-DS-ConsistencyGUID=*)"
After you deleted the mS-DS-ConsistencyGUID attribute (with the attribute editor of ‘AD Users and Computers’ or with some tool like LEX – The LDAP Explorer) on these objects, you can start over the AADC wizard to try it again.
Further reading
- Microsoft Dokumentation of the source anchor:
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-design-concepts - Sander Berkouver’s very good blog post about this topic:
https://dirteam.com/sander/2017/07/12/azure-ad-connect-objectguid-vs-ms-ds-consistencyguid-part-1/