In Hybrid Identity implementations, objects and their attributes are synchronized between on-premises Active Directory environments and Azure AD tenants.

The initial stages of synchronization

When integrating an Azure AD tenant with an Active Directory environment, you’re bound to start with the situation where you have accounts on both sides that you need to combine.

We often encounter self-service accounts in Azure AD when performing  straightforward Hybrid Identity implementations, because people have been invited to collaborate on documents, manage Microsoft licenses or have been working with trial licenses of Microsoft cloud services.

I have explained my approach for this situation on the ENow Software Solutions Engine a while back.

Hard matching and soft matching

It features an explanation of the concepts of Hard Matching and Soft Matching, just as I explained them in this blogpost.:

• Hard Matching matches objects on the source anchor attribute of the object in AD to the ImmutableID attribute of the object in Azure AD
• Soft Matching matches objects, based on the userPrincipalName attribute and the primary email address (denoted with SMTP: in the proxyAddresses attribute).

However, past these early stages of synchronization, there is typically no need to have Soft Matching enabled.

The problems with Soft Matching

I see two main problems with Soft Matching:

Malicious account take-over

Past the early stages of synchronization, the Soft Matching mechanism can be used by an attacker to match a newly created object in Active Directory to an existing object in Azure AD, overwriting attributes (like the password) with the values set by the attacker.

Luckily, Azure AD Connect no longer allows this account take-over for accounts with privileged roles.

Loose way to match objects

Soft Matching is also a loose way to match objects. Many wrong matches can be made. When using Hard Matching, only the objects that an admin decides to configure for matching and the objects that have previously been a good match, will match.

While this allows for a larger administrative burden when matching, it does rule out matching errors, possibly providing access to mailboxes, SharePoint sites, OneDrive for Business data and Teams data to the wrong person.

Disabling Soft Matching

Because there is typically no need to have Soft Matching enabled past the early stages of synchronization, I recommend disabling Soft Matching. Here’s how:

Before you begin

When signing in to the Windows Server running Azure AD Connect, make sure you use an account that is a member of the ADSyncAdmins group. When signing in to the Azure Portal, make sure you use an account that has the Global Administrator role in Azure AD.

Make sure your device has TLS 1.2 enabled and that you have the latest version of the MSOnline PowerShell Module installed on it.

Make sure that you have no synchronization errors. Perform the following steps:

• Sign in to the Windows Server installation running Azure AD Connect.
• Press Start.
• Search for the Synchronization Service and click on its search result.
  The Synchronization Service Manager window appears and the Operations tab will be selected. This tab shows a table with the last 7 days of synchronization cycles with their connector’s Name, the Run Profile Name, the Status, Start Time and End Time.
• In the Status column, make sure there are no run profiles with completed-*-warnings or completed-*-errors as their status.
• Close the Synchronization Servicer Manager window.
• Sign out.

If there are run profiles with completed-*-warnings or completed-*-errors as their status, address these issues before disabling soft matching as these errors might prevent Azure AD Connect from writing to the source anchor attribute.

Getting your tenant’s current Soft Matching setting

Perform these steps to get your Azure AD tenant’s current Soft Matching settings:

• Press Start.
• Search for Windows PowerShell and click on its search result, or start powershell.exe. The Windows PowerShell window appears.
• Run the following line of Windows PowerShell:

Connect-MsolService

• An Azure AD authentication window appears. Sign in.
• Run the following line of Windows PowerShell:

Get-MsolDirSyncFeatures | Format-Table DirSyncFeature,Enabled

• The value in the Enabled column for the option in the DirSyncFeature colum labeled BlockSoftMatch shows the current setting.
• Close the Windows PowerShell window, by either typing exit, or closing the window like you would any other window.

Disabling Soft Matching

To disable Soft Matching, perform these steps:

• Press Start.
• Search for Windows PowerShell and click on its search result, or start powershell.exe. The Windows PowerShell window appears.
• Run the following line of Windows PowerShell:

Connect-MsolService

• An Azure AD authentication window appears. Sign in.
• Run the following line of Windows PowerShell:

Set-MsolDirSyncFeature –Feature BlockSoftMatch –Enable $True

• Confirm changing the setting by typing Y.
• Close the Windows PowerShell window, by either typing exit, or closing the window like you would any other window.

Concluding

Microsoft recommends using the BlockSoftMatch feature in the disabled state and keep it at enabled until Soft Matching is required again for the Azure AD tenant. The feature should be disabled again after any Soft Matching has completed and is no longer needed.

Further reading

Explained: User Hard Matching and Soft Matching in Azure AD Connect
The Hard Part of Soft Matching between Active Directory and Azure AD
Azure AD Connect: When you already have Azure AD
Set-MsolDirSyncFeature (MSOnline)
How to use SMTP matching to match on-premises user accounts to Office 365 user accounts for directory synchronization
Azure AD Connect Synchronization Service Manager Operations