SyncJacking Explained: How Entra Connect Hard-Match Takeover Works

SyncJacking is an attack technique where an adversary with delegated rights in on-premises Active Directory abuses the Entra Connect Sync hard-match process to bind an account they control to an existing, privileged Entra ID identity. The result: takeover of a cloud Global Administrator or Privileged Role Administrator account without ever touching Entra ID directly.

Semperis named and disclosed SyncJacking in 2022. Microsoft's Security Response Center confirmed it as an Important privilege escalation vulnerability in May 2025. Microsoft began blocking hard matches against users with Entra roles in early June 2026, and the full hardening has been enforced since July 1, 2026. That enforcement is a major safeguard, but it does not retroactively clean up tenants where privileged accounts were already synced or where sync rules leave exposure. Most enterprise hybrid teams have not run a systematic audit.

This guide walks you through the attack path, the current Microsoft controls, what the new InvalidHardMatch sync errors mean, and a PowerShell audit workflow you can run against your tenant today.

What is SyncJacking?

Entra Connect Sync is the service that bridges your on-premises Active Directory domain with your Entra ID (formerly Azure AD) tenant. It synchronizes user objects, attributes, and group memberships so that a single identity spans both environments.

The sync service uses two methods to match on-premises AD objects to cloud identities. Soft matching compares email address and UPN attributes. Hard matching uses the immutableId (onPremisesImmutableId) attribute, taken from the source anchor (mS-DS-ConsistencyGuid in current Entra Connect versions, objectGUID in older ones), to create a permanent binding between an AD object and a cloud identity.

SyncJacking exploits hard matching. An attacker with write rights over an unsynchronized on-premises account copies a target's userPrincipalName and mS-DS-ConsistencyGuid onto that account, then deletes the target's original on-premises object. On the next sync cycle, Entra Connect Sync hard-matches the attacker's account to the target's cloud identity, including one assigned the Global Administrator role, and password hash sync pushes the attacker's password to it.

Why June 2026 changed the threat landscape

Microsoft began rolling out hard-match blocking in early June 2026 (Message Center MC1262584): Entra Connect Sync and Cloud Sync can no longer hard-match an incoming AD object to an existing cloud-managed user that holds an Entra ID directory role. Instead of silently succeeding, the operation now fails with an InvalidHardMatch synchronization error.

Since July 1, 2026, Microsoft Entra ID enforces the full hard-match hardening automatically. A hard match is also blocked when the target cloud account already has onPremisesObjectIdentifier set or is eligible for a privileged role, and the sync engine can no longer overwrite onPremisesObjectIdentifier once it holds a value.

These are forward-looking platform controls. They protect new hard-match attempts against role-assigned accounts. They do not remove sync bindings that already exist, and they do not address tenants where privileged accounts were incorrectly brought under sync scope before these protections were in place. The audit step below is not optional.

One more caution from Semperis: turning off the older "hard match takeover" setting is good hygiene, but their testing found SyncJacking still worked with it disabled. Treat the platform controls as a backstop, not a fix.

Seeing InvalidHardMatch or "OnPremisesObjectIdentifier cannot be changed" errors?

Since the hardening, admins see new errors in Synchronization Service Manager, Entra Connect Health, and the Entra admin center. They are the platform working as designed. Here is what each one means, based on Microsoft's troubleshooting guide.

InvalidHardMatch (103): "The cloud user with privileged roles is not allowed to be taken over"

Sync tried to hard-match an on-premises object to a cloud user who holds, or is eligible for, a privileged Entra role. You may also see it reported as "Hard match failed: the target cloud user has active Entra role assignments." Microsoft's documented fix is to temporarily remove the role (or the PIM eligibility), let the hard match complete, then reassign it.

AttributeUpdateNotAllowed (96): "OnPremisesObjectIdentifier cannot be changed unless its current value is null"

The cloud user is already mapped to an on-premises object, and sync is trying to point it at a different one. Microsoft's fix is to back up the user's on-premises attributes, clear onPremisesObjectIdentifier to null with the ADSyncTools module (version 2.5.0 or later, Clear-ADSyncToolsOnPremisesAttribute) or Microsoft Graph, then run sync again.

Check before you fix

Both fixes reopen the exact path SyncJacking uses. An unexpected InvalidHardMatch on a privileged account can be an attack being blocked, not a misconfiguration. Before removing a role or clearing an identifier, confirm the on-premises object is legitimate: who created or changed it, when its userPrincipalName and mS-DS-ConsistencyGuid were last modified, and whether the user's original on-premises account was recently deleted. If you cannot explain the change, treat it as an incident.

Microsoft's full list of sync errors and fixes is in Understanding errors during Microsoft Entra synchronization.

The SyncJacking attack path, step by step

Understanding the attack path is necessary before you can evaluate your own exposure. Here is a realistic sequence:

1. Attacker gains a foothold in on-premises AD with delegated rights. Semperis found that two permissions are enough: Write-all-Properties (or GenericWrite) on an on-premises account that is not synchronized, and Delete on the target's synchronized account. Delegated helpdesk roles, Account Operators membership, or loose OU delegation commonly grant both. Domain Admin is not required.

2. Attacker identifies a target cloud-privileged account. They enumerate Entra ID role assignments and pick a synchronized Global Admin or Privileged Role Admin.

3. Attacker copies the target's identity onto their own account. They set the unsynchronized account's userPrincipalName and mS-DS-ConsistencyGuid to the target's values, then delete the target's original on-premises object.

4. Sync cycle runs. Entra Connect Sync finds the target's cloud object without its on-premises source and hard-matches it to the attacker's account. Without the 2026 hardening, the cloud account's source of authority moves to the attacker's object.

5. Attacker signs in as the admin. Password hash sync overwrites the cloud account's password with the attacker's, and the account keeps its Entra roles. MFA registered to the victim is now the last line of defense, which is why privileged accounts without strong MFA are fully exposed.

The attack path is particularly dangerous because it exploits a legitimate sync feature. No exploit code is needed. The attacker uses normal AD attribute changes and one deletion, then waits for the next scheduled sync.

Affected configurations

SyncJacking risk is highest in tenants with these characteristics:

Password Hash Sync (PHS) or Pass-through Authentication (PTA) tenants. Both sync models allow on-premises credentials to authenticate cloud identities, compounding the risk. Federated environments (AD FS) have a similar trust boundary problem.

Privileged cloud accounts that were migrated from on-premises. If a Global Admin or Security Admin was originally created on-premises and later migrated to cloud-only status, the onPremisesImmutableId may still be populated on the cloud object, making it a target for hard-match takeover.

Broad sync scope. Organizations that sync their entire AD forest without filtering out service accounts, privileged accounts, or break-glass accounts expand the attack surface significantly.

Missing PIM just-in-time controls. Tenants where role assignments are permanent rather than time-limited through Privileged Identity Management give an attacker a permanently-privileged session after a successful sync takeover.

How to audit your tenant for SyncJacking exposure

Run these PowerShell queries to identify privileged cloud accounts that carry sync attributes and may still be reachable via hard-match manipulation.

Step 1: Enumerate all privileged role members and check for on-premises sync attributes.

# Requires Microsoft.Graph PowerShell module
Connect-MgGraph -Scopes 'Directory.Read.All', 'RoleManagement.Read.Directory'

$privilegedRoles = @(
    'Global Administrator',
    'Privileged Role Administrator',
    'Security Administrator',
    'User Administrator',
    'Exchange Administrator',
    'SharePoint Administrator',
    'Application Administrator',
    'Cloud Application Administrator'
)

$findings = @()

foreach ($roleName in $privilegedRoles) {
    $role = Get-MgDirectoryRole -Filter "displayName eq '$roleName'" -ErrorAction SilentlyContinue
    if (-not $role) { continue }

    $members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id
    foreach ($member in $members) {
        $user = Get-MgUser -UserId $member.Id -Property `
            'displayName','userPrincipalName','onPremisesImmutableId','onPremisesSyncEnabled','onPremisesLastSyncDateTime'
        if ($user.onPremisesImmutableId -or $user.onPremisesSyncEnabled) {
            $findings += [PSCustomObject]@{
                Role                     = $roleName
                DisplayName              = $user.DisplayName
                UPN                      = $user.UserPrincipalName
                OnPremisesImmutableId    = $user.OnPremisesImmutableId
                SyncEnabled              = $user.OnPremisesSyncEnabled
                LastSync                 = $user.OnPremisesLastSyncDateTime
            }
        }
    }
}

$findings | Format-Table -AutoSize
$findings | Export-Csv -Path './privileged-sync-audit.csv' -NoTypeInformation

Any account in the output is a potential SyncJacking target if its onPremisesImmutableId is set and the June 2026 hard-match blocking has not been validated. Accounts with SyncEnabled = True are actively being managed by Entra Connect Sync, which is itself a finding for privileged roles.

Step 2: From on-premises AD, check which accounts have attributes that could be used as a sync anchor.

# Run on a domain-joined machine with RSAT tools installed
Import-Module ActiveDirectory

# Find AD accounts with msDS-ExternalDirectoryObjectId set (cloud-linked accounts)
Get-ADUser -Filter * -Properties 'msDS-ExternalDirectoryObjectId','adminCount','memberOf' | 
    Where-Object { $_.'msDS-ExternalDirectoryObjectId' } |
    Select-Object SamAccountName, UserPrincipalName, 'msDS-ExternalDirectoryObjectId', adminCount |
    Export-Csv -Path './ad-cloud-linked-accounts.csv' -NoTypeInformation

# Flag accounts in privileged AD groups that also have cloud linkage
$privilegedGroups = @('Domain Admins','Enterprise Admins','Schema Admins','Account Operators')
foreach ($group in $privilegedGroups) {
    $members = Get-ADGroupMember -Identity $group -Recursive
    foreach ($m in $members) {
        $u = Get-ADUser $m -Properties 'msDS-ExternalDirectoryObjectId'
        if ($u.'msDS-ExternalDirectoryObjectId') {
            Write-Host "[RISK] $($u.SamAccountName) is in $group and has cloud linkage: $($u.'msDS-ExternalDirectoryObjectId')" -ForegroundColor Red
        }
    }
}

Defense controls: breaking the sync path for privileged accounts

The core principle is straightforward: privileged cloud identities should be cloud-only. They should never appear in Entra Connect Sync scope, and their onPremisesImmutableId should be null.

Remove privileged accounts from sync scope

In Entra Connect Sync, configure filtering to exclude all accounts that hold or are candidates for privileged Entra roles. Options include OU-based filtering (place privileged accounts in a dedicated OU that is excluded from sync scope) or attribute-based filtering using an extension attribute that marks privileged accounts as out-of-scope.

For accounts already synced that you want to convert to cloud-only: disable sync for the account, remove the onPremisesImmutableId attribute from the cloud object using the Microsoft Graph API (requires a PATCH to the user resource), and re-enable the account as a pure cloud identity.

Enable Conditional Access for privileged account sign-ins

Even if an attacker hard-matches and resets credentials, Conditional Access for privileged accounts can block authentication from non-compliant devices, unexpected geographies, or high-risk sign-in conditions. Require phishing-resistant MFA (passkeys or FIDO2 keys) for all role-eligible accounts. Password-based MFA methods can be reset by an attacker who controls the AD object.

Enable Entra ID Protection sign-in risk policies

Entra ID Protection assigns a risk score to each sign-in based on signals including impossible travel, unfamiliar location, leaked credentials, and anomalous token use. Configure a sign-in risk policy at High severity to block or require MFA re-registration for any privileged account. A SyncJacking-based credential reset will often produce high-risk signals on first use.

Use PIM for all privileged role assignments

Privileged Identity Management converts role assignments from permanent to eligible. An attacker who completes a SyncJacking takeover gets a cloud account with no active role; they must still complete a PIM activation request that requires MFA, a business justification, and generates an audit event. This reduces the blast radius significantly even if the account takeover itself succeeds.

Harden non-human identity governance across the sync boundary

The Entra Connect Sync service account itself is a privileged identity that crosses the sync boundary. It should be treated with the same rigor applied to human privileged accounts. Apply non-human identity governance controls to all service accounts used by Entra Connect: monitor for unexpected credential usage, scope permissions to the minimum required, and rotate credentials on a defined schedule.

Detection: what to monitor for SyncJacking activity

Detection relies on correlation between Entra ID audit events and privileged role assignments. The following events are relevant:

Entra ID Audit Logs: filter for activity name Synchronize directory combined with a target that holds a directory role. Any sync operation on a role-assigned account post-June 2026 enforcement should be investigated immediately as a potential misconfiguration or enforcement bypass.

Entra ID Audit Logs: filter for Add member to role or Update user where the initiating actor is the Entra Connect Sync service account. Legitimate sync should not be adding role members.

The following Microsoft Sentinel KQL query correlates sync operations against role-bearing accounts:

// SyncJacking detection: sync operations on privileged Entra ID accounts
// Run in Microsoft Sentinel / Log Analytics workspace
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName in ('Synchronize directory', 'Update user', 'Hard match user')
| where InitiatedBy.app.displayName has_any ('Microsoft Azure AD Connect', 'ADSync', 'AADConnect')
| extend TargetUPN = tostring(TargetResources[0].userPrincipalName)
| extend TargetObjectId = tostring(TargetResources[0].id)
| join kind=leftouter (
    AuditLogs
    | where OperationName in ('Add member to role', 'Add eligible member to role in PIM')
    | extend RoleMemberUPN = tostring(TargetResources[0].userPrincipalName)
    | extend RoleAssigned = tostring(TargetResources[1].displayName)
    | project RoleMemberUPN, RoleAssigned, TimeGenerated
) on $left.TargetUPN == $right.RoleMemberUPN
| where isnotempty(RoleAssigned)
| project TimeGenerated, OperationName, TargetUPN, RoleAssigned, InitiatedBy
| order by TimeGenerated desc

Alert on any results from this query. A sync operation on a user who holds a directory role is either a misconfiguration or an active attack.

Priority remediation checklist

The following steps are ordered by the speed at which they reduce your attack surface:

1. Run the PowerShell audit above and produce the privileged-sync-audit.csv file. Any account with onPremisesImmutableId set and a directory role assigned needs immediate review.

2. Convert any synced privileged accounts to cloud-only. Remove the sync binding, clear the onPremisesImmutableId via Graph API, and confirm the account is out of Entra Connect Sync scope.

3. Require phishing-resistant MFA for all privileged role holders. FIDO2 security keys or passkeys registered against the cloud identity cannot be overwritten by AD attribute manipulation.

4. Enable PIM for all Entra directory roles. Convert permanent assignments to eligible-only. This limits what an attacker can do even after a successful account takeover.

5. Deploy the Sentinel KQL detection rule. Alert on any sync-service-initiated update to a role-assigned account.

6. Verify your Entra Connect Sync version is current. The June 2026 hard-match blocking enforcement applies to supported versions. Running an end-of-life Entra Connect version means you may not receive the platform-level protection.

Go deeper on Entra ID security

Entra ID security, including PIM configuration, Conditional Access policy design, and hybrid identity hardening, is core material for Microsoft's security engineer certification. AZ-500 retired on August 31, 2026, and its replacement is SC-500. If you want a structured learning path, the SC-500 course covers identity security in sequence.

For a quick snapshot of your current AD security posture before you start the audit above, the domain report tool at Protego can surface exposed attributes and misconfigurations at the domain level.

Frequently asked questions

Does Microsoft's June 2026 enforcement fully fix SyncJacking?

It blocks new hard-match attempts against accounts that hold or are eligible for privileged roles, and since July 1, 2026 it also stops sync from overwriting onPremisesObjectIdentifier. It does not clean up existing sync bindings on privileged accounts, and it does not protect tenants running unsupported Entra Connect Sync versions. Manual audit and remediation are still required.

Does MFA protect against SyncJacking?

Yes, it is the most important control after removing privileged accounts from sync. A successful SyncJacking gives the attacker the account's password, but MFA methods registered to the victim still stand between the attacker and a session, which is why Semperis recommends enforcing MFA on all synced users. Accounts with no MFA registered are fully exposed. Phishing-resistant methods such as FIDO2 keys and passkeys give the strongest protection.

What on-premises permissions does an attacker need to perform SyncJacking?

Semperis's research shows two permissions are enough: Write-all-Properties or GenericWrite on an unsynchronized on-premises account, and Delete on the target's synchronized account. Neither requires Domain Admin. Delegated helpdesk rights, Account Operators membership, or broad OU delegation often grant both, which is why auditing AD delegation matters as much as auditing Entra roles.

How long does Entra Connect Sync take to process a modified object?

Entra Connect Sync runs a delta sync cycle every 30 minutes by default. An attacker who modifies an AD attribute at 11:00 AM could have a hard-matched cloud account by 11:30 AM. Reducing the sync cycle frequency (or enabling sync disable for privileged OUs) reduces the window, but the only complete mitigation is removing privileged accounts from sync scope entirely.

Does Cloud Sync (the newer agent-based sync) have the same risk?

Yes. Microsoft's June 2026 hard-match blocking explicitly covers both Entra Connect Sync and Cloud Sync. Both products use the same hard-match mechanism and are affected by the same underlying trust relationship between on-premises AD and the Entra ID tenant.