The Azure AD Connect Team has decided to move Azure AD Connect’s default source anchor attribute in on-premises Active Directory Domain Services (AD DS) environments from objectGUID to mS-DS-ConsistencyGuid for user objects in Azure AD Connect version 1.1.553.0, and up.
When you’ve been using Azure AD Connect to synchronize objects between your on-premises Active Directory Domain Services (AD DS) environment(s) and Azure Active Directory, and you upgrade to this version, or any version beyond from a previous version, you’ll be notified of this change with a notice on the Configuration complete screen:
Azure Active Directory is configured to use AD attribute objectGUID as the source anchor attribute. It is strongly recommended that you let Azure manage the source anchor for you. Please run the wizard again and select Configure Source Anchor. Learn more
About Source Anchors
The source anchor attribute helps Azure AD Connect to perform a hard match between on-premises objects in Active Directory Domain Services (AD DS) to objects in Azure Active Directory.
It is recommended to use an attribute as a source anchor that doesn’t change throughout the lifecycle of an Active Directory object and is unique to the object. Because people get married, get divorced, change their names, etc. the userPrincipalName, and mail attributes cannot be picked as the source anchor attribute in Azure AD Connect. (and also, because source anchors may not contain special characters, like the @-sign).
Before Azure AD Connect version 1.1.524.0, Azure AD Connect (but also Azure AD Sync and DirSync) defaulted to the objectGUID attribute for objects as the source anchor. Azure AD Connect version 1.1.553.0, and beyond, defaults to the mS-DS-ConsistencyGuid for user objects, but objectGUID for groups and computer objects.
The table below provides an overview:
This begs the question: What’s wrong with using ObjectGUID as the source anchor?
What’s wrong with objectGUID?
objectGUID is an attribute for on-premises Active Directory objects, that is written to with a random value when the object is created. From there on, it can no longer be changed. It’s immutable, even for Active Directory itself.
You’d think this makes for a pretty decent source anchor, but there two challenges:
The Cross-forest Migration Challenge
With the possibility for Azure AD Connect to synchronize multiple on-premises Active Directory Domain Services (AD DS) environments, a challenge emerges:
How do we cope with migrating a user object from one Active Directory forest, to another, when the person associated with the user account enjoys the benefits of Azure Active Directory?
When a user object is migrated from one Active Directory forest, to another, it is reborn, and, thus, receives a different value for objectGUID. Azure AD Connect will not be able to perform a hard match and the person may receive no mailbox, a fresh new mailbox, or worse, access to someone else’s mailbox…
The Accidentally Deleted Challenge
The second issue with using objectGUID as the source anchor for Azure AD Connect is that it complicates undelete of (accidentally) deleted user objects in on-premises Active Directory Domain Services (AD DS) environments in scope for synchronization.
While the use of the Active Directory Recycle Bin feature is highly recommended (Azure AD Connect provides a notice when this feature is not enabled), it’s not possible to enable it in every environment. While enabled, though, it adds another 180 days time-out, by default, to the garbage collection process on each of your Domain Controllers, on top of the default 180 days tombstone lifetime.
In other Active Directory Domain Services (AD DS) environments, though, the tombstone lifetime may still be set at 60 days. When these Active Directory forests were first setup, admins leveraged Domain Controllers running Windows Server versions prior to Windows Server 2003 with Service Pack 1. In the time since its inception, the tombstone lifetime was never set to 180 days, although Microsoft changed its recommendation.
When you reanimate an object beyond the tombstone lifetime, or in other rare cases, the object is recreated with its former attributes, except for objectGUID… Since this is a system-generated value set at creation date, the object is reborn with a different value for its objectGUID attribute.
How does mS-DS-ConsistencyGuid help?
When your organization already faced the challenges above, you may have already switched from objectGUID to mS-DS-ConsistencyGuid, mS-DS-SourceAnchor or even EmployeeID, using Mark Renoden’s guidance or using Roelf Zomerman’s guidance.
The magic in Azure AD Connect version 1.1.553.0, and beyond, is the introduction of the ability to automatically switch from objectGUID to mS-DS-ConsistencyGuid.
When you select mS-DS-ConsistencyGuid , Azure AD Connect will perform the following actions:
- In organizations with Active Directory Federation Services (AD FS) and the ‘Office 365 Identity Platform’ (or urn:federation:MicrosoftOnline) Relying Party Trust (RPT), Azure AD Connect will update the AD FS Issuance Transform Rules for this RPT to accommodate the use of mS-DS-ConsistencyGuid.
- On the first synchronization cycle, Azure AD Connect will check the mS-DS-ConsistencyGuid attribute of user objects in scope. When these attributes are empty, Azure AD Connect will update the attributes with the value of the objectGUID attribute.
- On the second synchronization cycle, Azure AD Connect will synchronize the user objects in scope with filled mS-DS-ConsistencyGuid attributes to Azure Active Directory.
Now, when you migrate a user object from one on-premises Active Directory Domain Services (AD DS) environment, to another, and both environments are in (future) scope of Azure AD Connect, the value for the objectGUID attribute of the user object changes, but the value for the mS-DS-ConsistencyGuid attribute remains the same. With mS-DS-ConsistencyGuid as its source anchor attribute, Azure AD Connect is able to hard match the Active Directory user object with the Azure Active Directory user object, as if nothing happened.
The same thing happens when you reanimate a user object in the on-premises Active Directory Domain Services (AD DS) environment: the value for the objectGUID attribute of the user object changes, but the value for the mS-DS-ConsistencyGuid attribute remains the same.
What you need to know
I have already scattered some tidbits throughout this blogpost on what you may, and may not expect from this change. I’ve compiled a list below for your convenience:
- The source anchor setting is a per-Azure AD Connect setting. When you change the source anchor attribute on your actively synchronizing Azure AD Connect installation, you should also change the source anchor attribute on the Staging Mode Azure AD Connect installation(s).
- The mS-DS-ConsistencyGuid attribute may not be in use by another application throughout each of the on-premises Active Directory Domain Services (AD DS) environments you have or intend to have in scope for Azure AD Connect.
- Custom-managed Azure AD Connect service account(s) may not have permission to write to the mS-DS-ConsistencyGuid attribute of user objects in your on-premises Active Directory Domain Services (AD DS) environment(s). You will need to grant this permission manually in (each of) the Active Directory Domain Services environment(s) in scope.
- The switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor in Azure AD Connect is (currently) only available for user objects, not for groups or computer objects.
- When you leverage Active Directory Federation Services (AD FS) as the Azure AD authentication scenario with Azure AD Connect, you will need direct network connections using TCP80, TCP443 and TCP5985 between your Azure AD Connect installation and the primary AD FS Server, when you switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute.
- When you make the switch through Azure AD Connect, it is no longer a good idea to reset the ‘Office 365 Identity Platform’ (or urn:federation:MicrosoftOnline) Relying Party Trust (RPT) by deleting it on the AD FS Primary Server and then recreating it using the Convert-MSOLDomaintoFederated PowerShell Cmdlet. Instead, use the Reset Azure AD and AD FS Trust option in Azure AD Connect:
Join me for part 2 of this series, where I show you the exact changes in Active Directory Federation Services’ Issuance Transform Rules and a script to grant a custom Azure AD Connect service account permissions to write the mS-DS-ConsistencyGuid attribute in your on-premises Active Directory Domain Services (AD DS) environments.
Choosing a sourceAnchor for Multi-Forest Sync with AAD Connect – Part 5, Using mS-DS-ConsistencyGuid
Migrating ‘SourceAnchor’ from ‘ObjectGUID’ using new AAD Connect 1.1.524.0
Office 365 – Why You Need to Understand ImmutableID
ImmutableID – mS-DS-ConsistencyGuid – ADConnect
How AAD Connect transforms employeeID(from AD) as SourceAnchor to ImmutableID(to Azure AD)? In case of ObjectGUID as SourceAnchor , it will converts sourceAnchor to base64string and stores in ImmutableID of the corresponding user.
This appears to be exactly what I have been looking for. I have multi forest , hybrid , O365 CRM environment That I have been performing migrations, Domain consolidation and coming up includes the O365 CRM users that I had concerns with how that was to happen.
This is a juicy post Sander. Lots of useful tidbits of info.
One question though. If we set the source anchor to EmployeeID for example and decide to change this to ms-DS-ConsistencyGuid via uninstalling and reinstalling AD Connect, does this mean we have to start all over? like permanently removing all synced accounts in Azure and Azure recycle bin and doing a new initial sync?
can we just resync everything normally after uninstalling and reinstalling AD Connect with the new sourceAnchor?
How we can do this ?
Custom-managed Azure AD Connect service account(s) may not have permission to write to the mS-DS-ConsistencyGuid attribute of user objects in your on-premises Active Directory Domain Services (AD DS) environment(s). You will need to grant this permission manually in (each of) the Active Directory Domain Services environment(s) in scope.
This is part 1 of a series on mS-DS-ConsistencyGUID in Azure AD Connect. In Part 2, I have included a script to grant the service account for the on-premises Active Directory Domain Services environment(s) the proper delegated rights.
Hi Sander, Thanks for the great post.
When migrating Azure AD Connect from 1.4 to v2.x on a new server, the ADSyncDocumenter comparison tool lists the source anchor for Groups as changing from objectguid to ms-ds-consistencyguid, which I undertand is now the default.
Or more specifically, it lists the new value being: IIF(IsPresent([mS-DS-ConsistencyGuid]),[mS-DS-ConsistencyGuid],[objectGUID])
Is there any risk taking the new AAD Connect instance out of staging mode on the new server? We can't seem to find a way to change the source anchor for groups back to objectGuid (if we did this, the 2 configs would be the same).
With Azure AD Connect 126.96.36.199, Azure AD Connect switched from objectGUID to mS-DS-ConsistencyGUID as the source anchor for group objects. Of course, at the initial Import step for Active Directory, no value for the mS-DS-ConsistencyGUID attribute is not present, as it is written during the first Export step towards Active Directory. Permissions and custom synchronization rule conflicts may get in the way. If there is something in the way, the objectGUID attribute is still perfectly capable of acting as the source anchor attribute (the end-to-end attribute that ties the Azure AD object and Active Directory object together and that offers a way to tie the two objects together even when your Azure AD Connect installations are completely lost and need to be rebuilt.
I don't expect any problems with this rule change.
I have not heard of any people with problems with this rule change.