Synchronizing on-prem AD users against Azure AD can be a real challenge once you realize that (some of) your users aren’t syncing the right way. In this blog post I’ll explain the basics about the identity matching process as well as the key differences about soft and hard matching which will help you through the configuration.

Most of the tech guides about implementing Azure AD Connect assumes you are starting “greenfield” with a brand new (blank) tenant, ready to sync against your on-prem Active Directory.
However, if you are starting with an existing Azure AD tenant, because you were (for example) already using some parts of the Office 365 suite, there is a decent chance you might run into trouble and you’re ending up with duplicate, inconsistent or missing/non-synced users.

Don’t worry, if you master the basics of Azure AD (Connect) and follow Microsoft best practices, most of the time you’ll just be fine and Azure AD Connect will sync the users using the soft matching process (also known as “SMTP matching”).

Although, in some cases you might desire some kind of trick to “tell” or “hardcode” Azure AD which on-prem AD account belongs to the correspondent Azure AD account. This is also known as hard matching (by calculating the “immutableID”).

Soft matching

Let’s first explain the soft matching process, which will fit in most sync scenarios. This kind of matching requires your on-prem identities UPN and SMTP address to be aligned with your external domain name, as shown in the example below. In this example, the external domain name has been added as UPN within Active Directory, and applied to user Test03.

This way, Azure AD Connect will recognize the domain name and will set the loginname of the corresponding Azure AD account to the appropriate domain. This is the first place to check if you notice your users login names are named using the default domain.

Keep in mind, you cannot simply change the UPN of a specific user without adding the UPN suffix in Active Directory first. You can configure/add the suffix from the domain properties within the Active Directory Domains and Trusts console.

Also, although changing the users UPN usually doesn’t have any serious impact on his/her domain- or software access I recommend to first run some tests together with a pilot group of endusers.

Hard matching

As introduced above, soft matching might fail in some circumstances. There are far too many possible causes for this to happen, so we’re not walking through all of them. However, a common cause is trying to sync against existing Azure AD users which already have certain fields populated, particularly the “immutableID” attribute.

In fact, the hard matching process is a solution to “hardcode” the link between an on-prem user and corresponding Azure AD user. The solution consists of a Base64 calculation of the on-prem GUID attribute which gets populated into the “immutableID” attribute in Azure AD. In transit, the ID is named as “SourceAnchor” within the connector spaces of Azure AD Connect. Keep in mind, a successful “regular” soft-match will also result in populating this field to (kind of) “seal” the link between the two user accounts, so there’s no customization at all.

AD ObjectGUID to AAD ImmutableID flow

In other words, there’s no magic behind the scenes. When you’re forcing a hard-match between accounts you’re just building a link by hand. It will not have any impact on Azure AD Connect since it’s fully supported. Azure AD Connect will just threat the particular user account as it have been successfully soft-matched before.

No rocket science, right? You can use the PowerShell script below to convert the on-prem “ObjectGUID” to the needed “ImmutableID” format, and populate it into Azure AD.

I’m pretty sure this will help you solve any mis-matches during directory synchronization. If you’re having any questions, suggestions or other ideas, please feel free to drop them below.