Hard match takeover in Entra Connect: the June 2026 block and what it leaves open

Samantha Kloos-Kilkens
Apr 15, 2026 · Samantha Kloos-Kilkens

From 1 June 2026 Microsoft Entra ID refuses to hard-match a new Active Directory user onto an existing cloud-managed user that holds a Microsoft Entra role. That closes the most direct route to what Semperis called SyncJacking, but only for one specific group of accounts, and the tenant settings that block cloud object takeover entirely have been available for a long time. This post covers how matching actually works, how the takeover runs, how to find the exposed admin accounts in your tenant today, and what I would switch on before June.

A mooring rope tied to a cleat on a wooden dock Photo: Renato Leal on Unsplash

How hard match and soft match work

When Entra Connect Sync or Cloud Sync exports a user that is new from its point of view, the service first looks for an existing object whose onPremisesImmutableId equals the incoming sourceAnchor: on any recent Connect installation the Base64 form of ms-DS-ConsistencyGuid, which Connect fills with the objectGUID when it's empty. A hit is a hard match: the cloud object's source of authority flips to on-premises and every attribute that has a value in AD overwrites the cloud value, as described in Microsoft Entra Connect: When you have an existing tenant. With password hash sync enabled, that includes the password hash.

Without a hit, Entra tries a soft match on the primary SMTP address, and on userPrincipalName when SoftMatchOnUpn is enabled (once enabled it can't be turned off). Soft match only considers cloud objects that don't have an immutableId yet, and after a soft match the sourceAnchor is written to the cloud object, so from then on it's a hard match target. Both kinds of matching only happen for objects that arrive as new.

The asymmetry that matters here: soft matching onto a cloud user with an admin role has been blocked for years. That's the Existing Admin Role Conflict in the sync error reference. Hard match had no enforced equivalent until the June 2026 change. The InvalidHardMatch section of the same article already describes a hard match blocked for users with privileged roles, but Microsoft's announcement says enforcement only starts on 1 June, so as far as I can tell, until then the role on the target didn't stop a hard match if you had the immutableId.

How the takeover works

There are two variants. The original SyncJacking research by Semperis, reported to MSRC in October 2022, targets a synced account: with write rights on an unsynced AD user and delete rights on the synced target, the attacker copies the target's anchor onto their own object, deletes the target in AD and lets sync remap the cloud identity to the object they control. The second variant targets cloud-managed accounts that still carry an onPremisesImmutableId, and that's the one the June change is about. The steps:
  1. The attacker controls an AD identity that can create a user, or write ms-DS-ConsistencyGuid on an existing one, in an OU that is in sync scope. Delegated OU admins, helpdesk groups and old provisioning service accounts typically have exactly that right.
  2. They get hold of the target's onPremisesImmutableId. It's a property on the user object, not a secret, and for a formerly synced admin it's the Base64 form of a GUID that may still be sitting on an object in AD.
  3. They write the decoded bytes into ms-DS-ConsistencyGuid on their object and give it a password they know.
  4. At the next sync cycle (every 30 minutes by default for Connect Sync, every few minutes for Cloud Sync) the object is exported as new, Entra hard-matches it to the cloud admin and converts that account to synced. With password hash sync the attacker's hash is written to the account; with pass-through authentication or federation, authentication goes to AD, where the attacker already owns the password.
  5. The role assignments stay where they were, on the same object. What's left between the attacker and an admin session is Conditional Access and the MFA methods registered on the account.

Cloud-only admin accounts that still carry an onPremisesImmutableId

Most organisations I work with keep admin accounts cloud-only, as Microsoft has advised for years. The catch is that "On-premises sync enabled: No" in the admin center says nothing about whether the account still carries an anchor. The usual ways an admin account ends up cloud-managed (or looking like it) with an onPremisesImmutableId:
  • It was synced once and later converted by disabling directory synchronization on the tenant, or it went through the old trick of removing it from sync scope and restoring it from the recycle bin. Both leave the anchor in place. The second route leaves a user with OnPremisesSyncEnabled False that Microsoft still considers a synced object, explicitly available to be matched again, which makes it an even easier target.
  • It was created in a federated domain, where Microsoft Graph requires onPremisesImmutableId when you create the user.
  • It went through the new user Source of Authority transfer, which makes a synced user cloud-managed and is designed so that the AD object can take it back over on rollback.
  • A migration tool or a script stamped it at some point.
Emergency access accounts are the ones I'd check first: cloud-only by design, often excluded from at least part of Conditional Access, and rarely looked at once they exist.

Finding admin accounts with an anchor

The script below collects active role assignments and PIM eligibility, expands role-assignable groups to their members, and reports every role holder that has an onPremisesImmutableId. Eligibility schedules need Entra ID P2; without it, drop that line. 
Connect-MgGraph -Scopes "RoleManagement.Read.Directory", "Directory.Read.All"

$roleNames = @{}
Get-MgRoleManagementDirectoryRoleDefinition -All |
    ForEach-Object { $roleNames[$_.Id] = $_.DisplayName }

$grants = @(
    Get-MgRoleManagementDirectoryRoleAssignment -All |
        Select-Object PrincipalId, RoleDefinitionId, @{ n = 'Kind'; e = { 'Active' } }
    Get-MgRoleManagementDirectoryRoleEligibilitySchedule -All |
        Select-Object PrincipalId, RoleDefinitionId, @{ n = 'Kind'; e = { 'Eligible' } }
)

# Role-assignable groups: report their members
$expanded = foreach ($g in $grants) {
    $obj = Get-MgDirectoryObject -DirectoryObjectId $g.PrincipalId
    if ($obj.AdditionalProperties['@odata.type'] -eq '#microsoft.graph.group') {
        Get-MgGroupMember -GroupId $g.PrincipalId -All | ForEach-Object {
            [pscustomobject]@{ PrincipalId = $_.Id; RoleDefinitionId = $g.RoleDefinitionId; Kind = "$($g.Kind) via group" }
        }
    }
    else { $g }
}

$expanded | Group-Object PrincipalId | ForEach-Object {
    $u = Get-MgUser -UserId $_.Name -Property Id, UserPrincipalName, OnPremisesImmutableId, OnPremisesSyncEnabled -ErrorAction SilentlyContinue
    if ($u.OnPremisesImmutableId) {
        [pscustomobject]@{
            UserPrincipalName     = $u.UserPrincipalName
            OnPremisesSyncEnabled = $u.OnPremisesSyncEnabled
            OnPremisesImmutableId = $u.OnPremisesImmutableId
            Roles = ($_.Group | ForEach-Object { "$($roleNames[$_.RoleDefinitionId]) ($($_.Kind))" } | Sort-Object -Unique) -join '; '
        }
    }
} | Format-Table -AutoSize
Rows where OnPremisesSyncEnabled is empty or False are cloud-managed admins with an anchor, which is the population the June change targets. Rows with True are synced admins, which Microsoft recommends against anyway and which are the target of the original SyncJacking variant.

For a cloud-managed admin that has no reason to keep its anchor, clear it. ADSyncTools 2.5.0 and later include Get-ADSyncToolsOnPremisesAttribute and Clear-ADSyncToolsOnPremisesAttribute for exactly this, for example Clear-ADSyncToolsOnPremisesAttribute -Id <objectId> -onPremisesImmutableId. Don't do this for users in a federated domain that still depend on the immutableId as their claim. Before clearing, I'd also check on the AD side whether any object still carries that anchor, because an object outside sync scope with an admin's anchor on it can be used for a takeover as soon as someone moves it into a synced OU: 
$immutableId = '<onPremisesImmutableId from the report>'
$bytes = [Convert]::FromBase64String($immutableId)
$ldap  = ($bytes | ForEach-Object { '\{0:x2}' -f $_ }) -join ''
Get-ADObject -LDAPFilter "(mS-DS-ConsistencyGuid=$ldap)" -IncludeDeletedObjects -Properties whenChanged

What the June change covers and what it doesn't

MC1262584, published on 26 March and listed in What's new for Microsoft Entra, says that from 1 June 2026 Entra ID blocks Connect Sync and Cloud Sync from hard-matching a new AD user onto an existing cloud-managed user that holds Microsoft Entra roles. The sync client gets an InvalidHardMatch error, and the documented way through for an intentional match is to remove the roles, let the match complete and assign them again. Explicitly unchanged: hard match for cloud users without Entra roles, soft match, and ongoing sync of objects that were matched before.

Reading the announcement next to the InvalidHardMatch section, I'd plan around these gaps:
  • Accounts without an Entra role that are still powerful: Owners on Azure subscriptions, owners of app registrations with high Graph permissions, holders of Exchange or Intune RBAC roles. None of these are Entra roles.
  • PIM-eligible accounts and role assignments through role-assignable groups. Both texts talk about roles that are assigned or held, so I'm not assuming eligibility or group membership counts.
  • Roles that aren't labelled privileged: What's new says "Microsoft Entra roles", the troubleshooting article says "privileged roles", and I'd plan for the narrower reading.
Synced accounts are covered by a separate change. MC1263280, published 27 March and listed on mc.merill.net as seen only in Education tenants, says that from 1 July 2026 Entra blocks Connect from modifying OnPremisesObjectIdentifier once it has been mapped to a synced user, which stops a synced cloud identity from being remapped to a different AD object. The December 2025 What's new entry for this first named March 2026 as the enforcement date; it now says 1 July. Blocked operations return "Hard match operation blocked due to security hardening. Review OnPremisesObjectIdentifier mapping.", the audit log now records changes to OnPremisesObjectIdentifier and DirSyncEnabled, and for a legitimate remap you clear the value with PATCH https://graph.microsoft.com/beta/users/{id} and body {"onPremisesObjectIdentifier": null}, which needs User-OnPremisesSyncBehavior.ReadWrite.All plus Global Administrator or Hybrid Identity Administrator.

Tenant settings you can switch on yourself

You don't have to wait for June. The onPremisesDirectorySynchronization object has two features that do most of the work: blockCloudObjectTakeoverThroughHardMatchEnabled blocks hard match takeover of cloud objects for every user, with or without a role, and blockSoftMatchEnabled blocks soft match for all objects. 
Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"

$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features | Select-Object BlockCloudObjectTakeoverThroughHardMatchEnabled, BlockSoftMatchEnabled

$OnPremSync.Features.BlockCloudObjectTakeoverThroughHardMatchEnabled = $true
$OnPremSync.Features.BlockSoftMatchEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
    -OnPremisesDirectorySynchronizationId $OnPremSync.Id `
    -Features $OnPremSync.Features
In Entra PowerShell, Set-EntraDirSyncFeature with the BlockCloudObjectTakeoverThroughHardMatch and BlockSoftMatch features does the same. Both flags also block the legitimate cases: bringing an existing cloud-only user under sync, re-adding a user that was out of scope and restored from the recycle bin, or re-enabling directory sync on a tenant. Microsoft's guidance is to switch them off only for the duration of such a matching job. In a large environment I'd put switching them off and back on as explicit steps in the runbook for every matching job.

These flags are about cloud objects. Semperis reported that their synced-account variant still worked with hard match takeover blocked, which fits: that variant remaps an object that is already synced, and that is what the July OnPremisesObjectIdentifier enforcement addresses. Until then, the new audit events are your detection. In Log Analytics: 
AuditLogs
| where OperationName in ("Update user", "Set DirSyncEnabled flag")
| where tostring(TargetResources) has_any ("OnPremisesObjectIdentifier", "DirSyncEnabled")
| project TimeGenerated, InitiatedBy, TargetResources
On the AD side, the right to write ms-DS-ConsistencyGuid on in-scope users, or to create users in synced OUs, is effectively a cloud privilege and belongs in your tiering review. The same goes for anyone who can manage the credentials of the Connect Sync application.

Run the inventory script this week, clear the anchor on every cloud-managed role holder that doesn't need one (emergency access accounts first), and switch on blockCloudObjectTakeoverThroughHardMatchEnabled and blockSoftMatchEnabled before 1 June.

Update April 2026: A day after this post, Microsoft changed the rollback steps for user source of authority: they now start by disabling blockCloudObjectTakeoverThroughHardMatchEnabled. So the flag I recommend above also blocks rolling back a source of authority transfer until you switch it off. Put that step in the same runbook, so nobody switches the protection off for a rollback and forgets to switch it back on.

Update July 2026: Since 1 July 2026 Entra ID also blocks a hard match when the target cloud user already has onPremisesObjectIdentifier set or is eligible for a privileged role, not only when a role is assigned, and the check is enforced in the cloud for both Connect Sync and Cloud Sync. Cloud-managed accounts with writeback enabled are excluded, and allowOnPremUpdateOfOnPremisesObjectIdentifierEnabled is available as a temporary bypass during remediation. See Troubleshoot InvalidHardMatch errors.

Sources

Written by an Argus IT expert

Want an expert like this in your team, or work like this yourself in security, IAM or cloud?

Get in touch Work at Argus IT
Samantha Kloos-Kilkens

Samantha Kloos-Kilkens

Samantha Kloos-Kilkens has worked in security and identity for more than ten years, eight of them at Microsoft in the Identity and Network Access product group. She founded Argus IT in 2023 and has a soft spot for the hidden gems in Entra ID. CISSP, CCSP, CISM, CCSK and Microsoft Certified Trainer.

Stay in the Loop

Subscribe to our newsletter for a friendly nudge whenever we publish a new article or have news to share.