Hey folks, Eric Woodruff here – Customer Engineer still living and breathing in the world of Azure Active Directory.
Today we are going to dive into the specifics of how user accounts in Active Directory are matched to user accounts in Azure Active Directory.
For organizations that started their Azure AD journey with services such as Office 365, the implementation of Azure AD Connect (now including Azure AD Connect Cloud Sync) is relatively low effort when there is not an existing stake in the cloud.
On the flip side, when working with organizations that have already been on their cloud journey, but never synchronized their Azure AD (AAD) tenant with Active Directory (AD), there is more concern about how this process works when the same user exists in both directories.
And with this concern comes some common questions, which I hope to bring some clarity to here.
Before we jump into things, note that we have some excellent documentation that covers a lot of the details of this as well, which can be found here:
Azure AD Connect: When you already have Azure AD | Microsoft Docs
Is configuring Azure AD Connect “destructive”?
While the term destructive can be interpreted a few ways, the sum of the question is whether existing user accounts in the Azure AD tenant will be deleted or overwritten by Azure AD Connect.
One of the main reasons behind this question, is the concern that users already have group membership, RBAC roles assigned, applications they are accessing, and so on; losing this would require having to reconfigure these assignments.
The answer is no – Azure AD Connect synchronizes in a way such that any existing AAD users (referred to as cloud-mastered, but also informally as “cloud-only” or “cloud-sourced”) will remain in the directory, and new user objects from Active Directory will be created in the cloud.
What about when the same user already exists in both places?
Before we talk about how user account matching happens, let’s get a quick background on what defines object uniqueness within directories.
Object Uniqueness
In both AD and AAD, every object has an immutable ID – a unique attribute that persists for the lifetime of the user object. The immutable ID attribute in AAD is ObjectId; in AD it is objectGUID. And while many times we are used to referring to on-premises user objects in terms of their SID (security Identifier), from a directory perspective the immutable ID is what represents object uniqueness.
Because these values are what represent a unique user object, it’s what allows you to change the User Principal Name (UPN), or on-premises samAccountName, and all the groups, ACL’s, and everything assigned to that user object remain.
How Azure AD aligns user objects
If you inspect ObjectId and objectGUID, you will notice these attributes are not the same, both in format as well as value. It is up to AAD and/or Azure AD Connect to align existing user objects, which is based on sourceAnchor. Technically the attribute name is ImmutableId in AAD, sourceAnchor in the metaverse in Azure AD Connect, and usually (but not always) mS-DS-ConsistencyGuid in Active Directory. Logically immutable ID and sourceAnchor terminology can be used interchangeably when discussing the attribute that represents the tie between the AAD and AD user object.
If the user object is new, then by default Azure AD Connect will take the objectGUID of the user object, calculate the Base64 of the value, and then write it to the user object mS-DS-ConsistencyGuid attribute in AD.
Certain customer scenarios may call for using a different attribute as the data source for sourceAnchor from Active Directory, but generally customers should allow Azure AD Connect to manage this for their environment.
You can read further about sourceAnchor within Azure AD Connect here:
Azure AD Connect: Design concepts | Microsoft Docs
Handling the duality issue
The background on sourceAnchor helps paint the picture when we start to talk about user matching. We have two types of object matching within Azure AD – soft-matching and hard-matching.
Soft-matching
Soft-matching is the case where we attempt to match two disparate user objects without existing sourceAnchor information; Azure AD will attempt to match user objects based on either UPN or email address.
Soft-match by UPN
Here we are going to look at soft-matching based on the UPN. We have our user, Lee Gu, existing as a cloud-mastered user – Lee has no ImmutableId, and Directory synced is no (keyed off the hidden attribute cloudMastered being true).
To synchronize Lee, we will need to move the user object into an OU that is scoped for synchronization by Azure AD Connect, but first let’s look at the user data – note that mS-DS-ConsistencyGuid is empty.
While not required for the match itself, if we want to see what the sourceAnchor of Lee is going to be, we can leverage a quick PowerShell command:
[system.convert]::ToBase64String(([guid](get-aduser -identity $_).objectguid).ToByteArray())
Because we are impatient, we force a delta sync of Azure AD Connect, and check out the results of the UPN soft-match.
Key Takeaways:
- The user object has been changed to a directory synchronized user account; cloudMastered has been changed from true to false.
- User attributes from AD have flown through and updated on the user object in AAD; this is because AD is the authoritative directory.
- The ImmutableId/sourceAnchor we calculated matches what was calculated by Azure AD Connect and written to AAD, as well as populated in AD for mS-DS-ConsistencyGuid.
- The ObjectId in AAD has not changed. This is one is critical in showing that, whatever Lee had access to prior, that access will persist.
Soft-match by mail
This time we are going to look at soft-matching by the email address. We have our user, Foster Caleb, existing as a cloud-mastered user – Foster has no ImmutableId, and Directory synced is no.
Before we move Foster into scope for synchronization, let’s look at the user account in AD. Note that the UPN does not match between the directories, but the mail attribute does.
After our Azure AD Connect delta sync, let’s examine the results of the soft-match by mail. Because the UPN has changed, in AAD we must either query by the ObjectId or the updated UPN for our results.
Key Takeaways:
- The user object has been changed to a directory synchronized user account; cloudMastered has been changed from true to false.
- User attributes from AD have flown through and updated on the user object in AAD, including the UPN; this is because AD is the authoritative directory.
- The ImmutableId/sourceAnchor has been calculated and populated in AAD and AD.
- The ObjectId in AAD has not changed. This is one is critical in showing that, whatever Foster had access to prior, that access will persist.
Hard-matching
Unlike soft-matching, hard-matching is more common when we are discussing DR scenarios for Azure AD Connect, or cross-forest user migrations. In our example, however, we are going to show how hard-matching can effectively match two user objects that have neither a matching UPN nor email address.
A word of caution – incorrectly setting the wrong ImmutableId can cause cascading negative impact on users, which can flow into not just AAD, but also Exchange Online, as well as other services and applications that consume and key off UPN or email address.
We have our user, Lidia Holloway, existing as a cloud-mastered user – Lidia has no ImmutableId, and Directory synced is no. Note that the user object in AAD has no matching UPN nor email address in AD.
Before moving Lidia under scope for synchronization, we need to generate the ImmutableId and write it to AAD; it’s important to do this prior to scoping the user object for sync, otherwise it will just be created as a new user in AAD. Keying off the objectGUID in AD, we calculate and write the value for ImmutableId in AAD.
We run our Azure AD Connect delta sync and examine the results of the match.
Key Takeaways:
- The user object has been changed to a directory synchronized user account; cloudMastered has been changed from true to false.
- User attributes from AD have flown through and updated on the user object in AAD, including the UPN and mail; this is because AD is the authoritative directory.
- The ObjectId in AAD has not changed. This is one is critical in showing that, whatever Lidia had access to prior, that access will persist.
What else is important to know about matching?
Be careful with email address matching.
Email address matching has potentially higher ramifications on the user object. Many Enterprise Applications consume the UPN as the Name ID claim, which defines the uniqueness of the user object; if this has changed the application may see the user as a new user. If Azure AD Provisioning handles user object synchronization to the application, it can usually manage these changes, but manual user provisioning or just-in-time (JIT) may see the user as a different object.
Users with administrative roles in Azure AD will bypass matching.
To prevent unaccounted for account takeover of roles with privilege assignment, any user object that has an admin role assigned in AAD will be bypassed for matching.
Speaking of administrative roles and synchronization in general, highly privileged user accounts should be separated out from regular user accounts. Further, privileged accounts should be cloud-mastered, to prevent account takeover, as well as bypass dependencies on federated identity providers. For more information about protecting Azure AD from on-premises attack vectors, refer to this blog post by our Alex Weinert:
Protecting Microsoft 365 from on-premises attacks - Microsoft Tech Community
Groups and Contact objects work too.
If the group or contact has a mail address populated, they can be soft-matched based on this attribute. We can’t set the ImmutableId on these objects, so we don’t have a method of providing for hard-matching.
Understanding where matches are evaluated.
Soft-matching happens in Azure AD, which is why a user will show as an add in Azure AD Connect instead of an update. Hard-matching can be performed by Azure AD Connect, which helps expedite directory re-synchronization in the event of a disaster; this also helps accelerate the process of standing up a staging server for Azure AD Connect and having existing users matched.
Happy Matching!
For those that are either starting their cloud journey, apprehensive about connecting their directories, or just curious about how things work under the hood, I hope this post helps shed some light.
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Microsoft
