Microsoft Entra Connect Hard Match Fails for Privileged Users: How to Diagnose and Fix It

If Microsoft Entra Connect or Cloud Sync has started throwing InvalidHardMatch errors, or an export error saying “Hard match operation blocked due to security hardening”, nothing is broken. Microsoft changed the rules in 2026 so that an on-premises Active Directory account can no longer take over certain cloud accounts, starting with privileged ones.

That’s a good change. It closes off an attack sometimes called SyncJacking, where someone with write access to AD stamps an on-premises account with the right attribute value and quietly takes control of a cloud Global Administrator. But it also catches legitimate work: re-linking a user after an AD account was recreated, restoring someone from the recycle bin, consolidating domains after a merger, or connecting an existing cloud admin to a new AD account.

We run a hybrid tenant with every admin role eligible through PIM, which is exactly the kind of environment this change was built for. This guide explains what changed, how to work out which rule is blocking you, how to fix it safely, and which changes to avoid while you’re troubleshooting.

What changed, and when

Microsoft rolled the change out in two stages.

From 1 June 2026, Microsoft’s What’s new in Entra page announced that Entra ID would block Connect Sync and Cloud Sync from hard matching a new AD user to an existing cloud-managed user that holds Entra roles.

From 1 July 2026, Microsoft’s troubleshooting documentation describes broader automatic enforcement. A hard match is now blocked when the target cloud account:

• already has onPremisesObjectIdentifier set, meaning it’s already mapped to an on-premises object,
• is assigned a privileged Entra role, or
• is eligible for a privileged Entra role.

That last point is the one that catches PIM shops out. An admin account with no active role assignment, only PIM eligibility, is still protected.

The check is enforced in the cloud, so it applies to Connect Sync and Cloud Sync regardless of client version. Hard matches to ordinary, unmapped cloud users still work, and users who are already correctly synced aren’t affected. Cloud-managed accounts with writeback enabled are excluded.

Hard match vs soft match in two minutes

When a new object arrives from AD, Entra ID tries to find an existing cloud object that represents the same person.

Hard match compares the incoming object’s sourceAnchor with each cloud object’s onPremisesImmutableId. By default, sourceAnchor is the Base64 form of the AD user’s mS-DS-ConsistencyGuid, or objectGUID on older configurations. If they match, the on-premises object takes over the cloud account, and AD becomes its source of authority.

Soft match is the fallback. If no hard match is found, Entra ID tries the user principal name and primary SMTP address instead.

Soft matching to a cloud user with an admin role has been blocked for years, which is the familiar “Existing Admin Role Conflict” error. The 2026 change extends similar protection to hard match. Soft match behaviour itself hasn’t changed.

One detail matters a lot: when a takeover succeeds, Microsoft warns that every cloud attribute with an on-premises value is overwritten by the AD value. If password hash sync is on, the cloud password is replaced too. Linking the wrong AD account to an admin isn’t a sync problem. It’s a security incident.

Step 1: Read the error

On the Entra Connect server, open Synchronization Service Manager, select the latest export run on the Entra ID connector, and open the object’s error. For Cloud Sync, check the provisioning logs in the Entra admin centre. Microsoft’s troubleshooting guide lists three forms the error takes:

There’s a fourth possibility that has nothing to do with the 2026 change. If someone enabled BlockCloudObjectTakeoverThroughHardMatchEnabled on your tenant, every hard match takeover is blocked, privileged or not.

Step 2: Check the cloud account

First, confirm which cloud account the incoming object is trying to match, and whether it’s protected. This lists cloud-managed users that have an onPremisesImmutableId and hold or are eligible for any Entra role:

Connect-MgGraph -Scopes "User.Read.All", "RoleManagement.Read.Directory"

$users = Get-MgUser -All -Property Id, DisplayName, UserPrincipalName, OnPremisesImmutableId, OnPremisesSyncEnabled |
    Where-Object { $_.OnPremisesImmutableId -and -not $_.OnPremisesSyncEnabled }

$assigned = (Get-MgRoleManagementDirectoryRoleAssignment -All).PrincipalId
$eligible = (Get-MgRoleManagementDirectoryRoleEligibilitySchedule -All).PrincipalId

$users |
    Where-Object { $_.Id -in $assigned -or $_.Id -in $eligible } |
    Select-Object DisplayName, UserPrincipalName, OnPremisesImmutableId

It’s deliberately broad. It lists any role, not just the privileged ones, and it won’t show a user who gets a role through a role-assignable group, so check those separately. Every account it returns is one that an AD object could previously have taken over.

To see the full set of on-premises attributes on one account, including onPremisesObjectIdentifier, use ADSyncTools 2.5 or later on the Connect server:

Import-Module ADSyncTools -MinimumVersion 2.5
Get-ADSyncToolsOnPremisesAttribute -Id "<userObjectId>"

Step 3: Check the AD account

Next, work out what sourceAnchor the AD account is presenting, so you can confirm whether it’s meant to match that cloud user at all:

$ad = Get-ADUser jsmith -Properties "mS-DS-ConsistencyGuid", ObjectGUID

if ($ad."mS-DS-ConsistencyGuid") {
    [Convert]::ToBase64String($ad."mS-DS-ConsistencyGuid")
} else {
    [Convert]::ToBase64String($ad.ObjectGUID.ToByteArray())
}

If the value matches the cloud account’s onPremisesImmutableId and it’s the same person, you have a legitimate match that’s been blocked. If it matches but it’s not the same person, or nobody can explain why that AD account carries that value, stop. Someone may have set it deliberately, and that’s exactly what this protection exists to catch.

Step 4: Decide what you’re actually trying to do

Work through these questions in order.

1. Is the cloud account an admin account?

• Yes, and it’s a dedicated cloud-only admin account. Don’t link it to AD at all. Microsoft recommends cloud-native accounts for Entra roles, and strongly recommends against syncing on-premises accounts with existing administrative accounts. Find out why an AD object is trying to match it, fix or remove that object, and leave the admin account cloud-only.
• Yes, but it’s someone’s everyday account that also holds a role. Ask whether the role belongs on that account. Often the better fix is to give the person a separate cloud-only admin account, remove the role from their everyday account, and then let the everyday account sync. Otherwise, use the privileged role recovery in Step 5.
• No. Go to question 2.

2. Does the cloud account already have onPremisesObjectIdentifier set?

• Yes. It’s already linked to a different on-premises object. This is common after an AD account is recreated, a forest or domain move, or a merger. Confirm the new AD object is the right one, then clear the identifier (Step 5).
• No. Go to question 3.

3. Is the user soft-deleted?

• Yes. Restore the user from the Entra ID recycle bin first. A soft-deleted synced user with privileged roles is also blocked from hard match during restore.
• No. Go to question 4.

4. Is BlockCloudObjectTakeoverThroughHardMatchEnabled turned on for the tenant?

• Yes. That’s blocking every hard match. Turn it off only for the duration of a planned matching job, then turn it back on.

Step 5: Fix it safely

Privileged role or eligibility blocking the match. Microsoft’s documented recovery is to temporarily remove the role assignment or PIM eligibility, run a sync so the hard match completes, then restore the role. Export the user’s current assignments before you start, so nothing is forgotten, and restore them straight away. Don’t leave an admin without their roles longer than you need to.

onPremisesObjectIdentifier already set. Once you’ve confirmed which AD object should own the account, clear the value with ADSyncTools and rerun sync. The next successful sync stamps a fresh value:

Import-Module ADSyncTools -MinimumVersion 2.5

$userId = "<userObjectId>"

Get-ADSyncToolsOnPremisesAttribute -Id $userId | Export-Clixml "onprem-attributes-backup.xml"
Clear-ADSyncToolsOnPremisesAttribute -Id $userId -onPremisesObjectIdentifier

You can also clear it with a Graph PATCH to the beta users endpoint, setting onPremisesObjectIdentifier to null. That needs the User-OnPremisesSyncBehavior.ReadWrite.All permission and Global Administrator or Hybrid Identity Administrator. The value can only be cleared, never set to something else.

A large migration you can’t remediate in time. Microsoft provides a tenant-level bypass, AllowOnPremUpdateOfOnPremisesObjectIdentifierEnabled, that temporarily allows these updates:

Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"

$sync = Get-MgDirectoryOnPremiseSynchronization
$sync.Features.AllowOnPremUpdateOfOnPremisesObjectIdentifierEnabled = $true

Update-MgDirectoryOnPremiseSynchronization `
    -OnPremisesDirectorySynchronizationId $sync.Id `
    -Features $sync.Features

Set it back to $false the moment the migration is done. While it’s on, you’ve switched off the protection for the whole tenant.

After any fix, rerun sync, confirm the export error has cleared, and check that the cloud user is linked to the AD object you intended.

What not to do while troubleshooting

• Don’t edit onPremisesImmutableId on an admin account to force a match. That’s the attack technique, performed by you.
• Don’t hard-delete the cloud admin account to let a new synced one replace it. You lose its role history, MFA registration and any assignments tied to its object ID.
• Don’t leave the bypass flag or a disabled hard match block switched on after the job is finished.
• Don’t treat hard match as a general repair tool for accounts that are already mapped. Confirm the mapping first. If the wrong AD object is linked, the account inherits the wrong source of authority.

Make it less likely to happen again

While you’re in there, harden the rest of the matching process:

• Keep admin accounts cloud-only, so there’s nothing in AD that should ever match them.
• Turn on BlockCloudObjectTakeoverThroughHardMatchEnabled and BlockSoftMatchEnabled permanently once your tenant no longer needs to link existing cloud accounts. Microsoft advises enabling both unless you need them for a takeover.
• Restrict who can write mS-DS-ConsistencyGuid in AD. Anyone who can change it can, in principle, point an AD account at a cloud identity.
• Run the Step 2 script now and then. Any cloud-managed account with an onPremisesImmutableId and a role deserves a closer look.

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.