This article is contributed. See the original author and article here.

 


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).


 


Eric_Woodruff_0-1618498906985.png


 


Eric_Woodruff_1-1618498906989.png


 


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.


 


Eric_Woodruff_2-1618498906991.png


 


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())

 


 


Eric_Woodruff_3-1618498906993.png


 


Because we are impatient, we force a delta sync of Azure AD Connect, and check out the results of the UPN soft-match.


 


Eric_Woodruff_4-1618498906996.png


 


Eric_Woodruff_5-1618498906997.png


 


Eric_Woodruff_6-1618498906998.png


 


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.


 


Eric_Woodruff_7-1618498906999.png


 


Eric_Woodruff_8-1618498907000.png


 


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.


 


Eric_Woodruff_9-1618498907002.png


 


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.


 


Eric_Woodruff_10-1618498907005.png


 


Eric_Woodruff_11-1618498907007.png


 


Eric_Woodruff_12-1618498907011.png


 


Eric_Woodruff_13-1618498907012.png


 


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.


 


Eric_Woodruff_14-1618498907013.png


 


Eric_Woodruff_15-1618498907014.png


 


Eric_Woodruff_16-1618498907015.png


 


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.


 


Eric_Woodruff_17-1618498907017.png


 


We run our Azure AD Connect delta sync and examine the results of the match.


 


Eric_Woodruff_18-1618498907019.png


 


Eric_Woodruff_19-1618498907019.png


 


Eric_Woodruff_20-1618498907021.png


 


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.

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

%d bloggers like this: