Hard match-overname in Entra Connect: de blokkade van juni 2026 en wat er openblijft

15-04-2026 · Samantha Kloos-Kilkens

Vanaf 1 juni 2026 weigert Microsoft Entra ID nog een nieuwe Active Directory-gebruiker te hard-matchen op een bestaande cloud-managed gebruiker met een Microsoft Entra-rol. Daarmee gaat de meest directe route naar wat Semperis SyncJacking noemde dicht, maar alleen voor één specifieke groep accounts, terwijl de tenantinstellingen die cloud object takeover volledig blokkeren al lang beschikbaar zijn. In deze blog: hoe matching echt werkt, hoe de overname verloopt, hoe je de kwetsbare admin-accounts in je tenant vandaag vindt en wat ik vóór juni zou aanzetten.

Een meertouw om een kikker op een houten steiger Foto: Renato Leal via Unsplash

Hoe hard match en soft match werken

Als Entra Connect Sync of Cloud Sync een gebruiker exporteert die voor de sync-client nieuw is, zoekt de service eerst naar een bestaand object waarvan onPremisesImmutableId gelijk is aan de binnenkomende sourceAnchor: bij elke recente Connect-installatie de Base64-vorm van ms-DS-ConsistencyGuid, die Connect vult met de objectGUID als hij leeg is. Is er een hit, dan is dat een hard match: de source of authority van het cloudobject gaat naar on-premises en elk attribuut dat in AD een waarde heeft, overschrijft de cloudwaarde. Zo staat het in Microsoft Entra Connect: When you have an existing tenant. Met password hash sync aan hoort de wachtwoordhash daar ook bij.

Zonder hit probeert Entra een soft match op het primaire SMTP-adres, en op userPrincipalName als SoftMatchOnUpn aanstaat (dat kun je na het aanzetten niet meer uitzetten). Soft match kijkt alleen naar cloudobjecten die nog geen immutableId hebben, en na een soft match wordt de sourceAnchor op het cloudobject gezet, zodat het vanaf dan een hard match-doelwit is. Beide vormen van matching gebeuren alleen voor objecten die als nieuw binnenkomen.

De asymmetrie waar het om draait: soft match op een cloudgebruiker met een admin-rol is al jaren geblokkeerd. Dat is de Existing Admin Role Conflict uit de referentie met sync-fouten. Voor hard match werd een vergelijkbare controle tot de wijziging van juni 2026 niet afgedwongen. De InvalidHardMatch-sectie van hetzelfde artikel beschrijft al een geblokkeerde hard match voor gebruikers met privileged roles, maar volgens Microsofts aankondiging begint de handhaving pas op 1 juni. Voor zover ik kan zien hield de rol op het doelaccount tot dan een hard match dus niet tegen als je de immutableId had.

Hoe de overname werkt

Er zijn twee varianten. Het oorspronkelijke SyncJacking-onderzoek van Semperis, in oktober 2022 bij MSRC gemeld, richt zich op een gesynchroniseerd account: met schrijfrechten op een niet-gesynchroniseerde AD-gebruiker en verwijderrechten op het gesynchroniseerde doelaccount kopieert de aanvaller de anchor naar zijn eigen object, verwijdert het doelaccount in AD en laat sync de cloudidentiteit opnieuw koppelen aan het object dat hij beheert. De tweede variant richt zich op cloud-managed accounts die nog een onPremisesImmutableId hebben, en daar gaat de wijziging van juni over. De stappen:
  1. De aanvaller beheert een AD-identiteit die een gebruiker mag aanmaken, of ms-DS-ConsistencyGuid mag schrijven op een bestaande gebruiker, in een OU die in sync-scope valt. Gedelegeerde OU-beheerders, servicedeskgroepen en oude provisioning-serviceaccounts hebben doorgaans precies dat recht.
  2. Hij achterhaalt de onPremisesImmutableId van het doelaccount. Dat is een property op het gebruikersobject en geen geheim, en bij een admin die ooit gesynchroniseerd was is het de Base64-vorm van een GUID die mogelijk nog op een object in AD staat.
  3. Hij schrijft de gedecodeerde bytes in ms-DS-ConsistencyGuid van zijn object en geeft het een wachtwoord dat hij kent.
  4. Bij de volgende sync-cyclus (standaard elke 30 minuten bij Connect Sync, om de paar minuten bij Cloud Sync) wordt het object als nieuw geëxporteerd, hard-matcht Entra het op de cloud-admin en wordt dat account gesynchroniseerd. Met password hash sync komt de hash van de aanvaller op het account; bij pass-through authentication of federatie gaat de authenticatie naar AD, waar de aanvaller het wachtwoord al in handen heeft.
  5. De roltoewijzingen blijven waar ze waren, op hetzelfde object. Tussen de aanvaller en een admin-sessie staan dan alleen nog Conditional Access en de MFA-methodes die op het account geregistreerd zijn.

Cloud-only admin-accounts die nog een onPremisesImmutableId hebben

De meeste organisaties waar ik werk houden admin-accounts cloud-only, zoals Microsoft al jaren adviseert. Het addertje: "On-premises sync enabled: No" in het admin center zegt niets over de vraag of het account nog een anchor heeft. De gebruikelijke manieren waarop een admin-account cloud-managed wordt (of zo lijkt) mét onPremisesImmutableId:
  • Het was ooit gesynchroniseerd en is later omgezet door directory synchronization op de tenant uit te zetten, of het is door het oude trucje gegaan van uit sync-scope halen en terugzetten uit de prullenbak. In beide gevallen blijft de anchor staan. De tweede route levert een gebruiker op met OnPremisesSyncEnabled False die Microsoft nog steeds als gesynchroniseerd object ziet en die expliciet opnieuw gematcht kan worden, wat hem een nog makkelijker doelwit maakt.
  • Het is aangemaakt in een gefedereerd domein, waar Microsoft Graph onPremisesImmutableId verplicht bij het aanmaken.
  • Het is door de nieuwe user Source of Authority-overdracht gegaan, die een gesynchroniseerde gebruiker cloud-managed maakt en zo is ontworpen dat het AD-object hem bij een rollback weer kan overnemen.
  • Een migratietool of script heeft hem ooit gezet.
Emergency access-accounts zou ik als eerste controleren: cloud-only by design, vaak uitgesloten van minstens een deel van Conditional Access, en na het aanmaken zelden nog bekeken.

Admin-accounts met een anchor vinden

Het script hieronder verzamelt actieve roltoewijzingen en PIM-eligibility, klapt role-assignable groups uit naar hun leden en rapporteert elke rolhouder met een onPremisesImmutableId. Eligibility schedules vereisen Entra ID P2; zonder P2 laat je die regel weg.
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: rapporteer de leden
$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
Regels waar OnPremisesSyncEnabled leeg of False is, zijn cloud-managed admins met een anchor: precies de groep waar de wijziging van juni op mikt. Regels met True zijn gesynchroniseerde admins, wat Microsoft sowieso afraadt en wat het doelwit is van de oorspronkelijke SyncJacking-variant.

Heeft een cloud-managed admin geen reden om zijn anchor te houden, haal hem dan weg. ADSyncTools 2.5.0 en hoger bevat daarvoor Get-ADSyncToolsOnPremisesAttribute en Clear-ADSyncToolsOnPremisesAttribute, bijvoorbeeld Clear-ADSyncToolsOnPremisesAttribute -Id <objectId> -onPremisesImmutableId. Niet doen bij gebruikers in een gefedereerd domein die de immutableId nog als claim nodig hebben. Voordat je hem wist, zou ik aan de AD-kant ook controleren of er nog een object met die anchor bestaat, want een object buiten sync-scope met de anchor van een admin erop kun je voor een overname gebruiken zodra iemand het naar een gesynchroniseerde OU verplaatst:
$immutableId = '<onPremisesImmutableId uit het rapport>'
$bytes = [Convert]::FromBase64String($immutableId)
$ldap  = ($bytes | ForEach-Object { '\{0:x2}' -f $_ }) -join ''
Get-ADObject -LDAPFilter "(mS-DS-ConsistencyGuid=$ldap)" -IncludeDeletedObjects -Properties whenChanged

Wat de wijziging van juni wel en niet afdekt

MC1262584, gepubliceerd op 26 maart en opgenomen in What's new voor Microsoft Entra, meldt dat Entra ID vanaf 1 juni 2026 voorkomt dat Connect Sync en Cloud Sync een nieuwe AD-gebruiker hard-matchen op een bestaande cloud-managed gebruiker met Microsoft Entra-rollen. De sync-client krijgt dan een InvalidHardMatch-fout, en de gedocumenteerde route voor een bedoelde match is: rollen weghalen, de match laten afronden en de rollen opnieuw toewijzen. Expliciet ongewijzigd: hard match voor cloudgebruikers zonder Entra-rol, soft match, en de lopende sync van objecten die al eerder gematcht zijn.

Als ik de aankondiging naast de InvalidHardMatch-sectie leg, zou ik rekening houden met deze gaten:
  • Accounts zonder Entra-rol die toch veel kunnen: Owners op Azure-subscriptions, eigenaren van app registrations met zware Graph-permissies, houders van Exchange- of Intune RBAC-rollen. Geen daarvan is een Entra-rol.
  • PIM-eligible accounts en roltoewijzingen via role-assignable groups. Beide teksten spreken over rollen die toegewezen of in bezit zijn, dus ik ga er niet van uit dat eligibility of groepslidmaatschap meetelt.
  • Rollen zonder het label privileged: What's new zegt "Microsoft Entra roles", het troubleshooting-artikel zegt "privileged roles", en ik zou van de smalste lezing uitgaan.
Gesynchroniseerde accounts vallen onder een aparte wijziging. MC1263280, gepubliceerd op 27 maart en volgens mc.merill.net alleen gezien in Education-tenants, meldt dat Entra vanaf 1 juli 2026 Connect blokkeert bij het wijzigen van OnPremisesObjectIdentifier zodra die aan een gesynchroniseerde gebruiker gekoppeld is. Daarmee kan een gesynchroniseerde cloudidentiteit niet meer aan een ander AD-object worden gehangen. In de What's new-vermelding van december 2025 stond eerst maart 2026 als handhavingsdatum; nu is het 1 juli. Geblokkeerde operaties geven "Hard match operation blocked due to security hardening. Review OnPremisesObjectIdentifier mapping.", de audit log legt wijzigingen in OnPremisesObjectIdentifier en DirSyncEnabled vast, en voor een legitieme herkoppeling wis je de waarde met PATCH https://graph.microsoft.com/beta/users/{id} en body {"onPremisesObjectIdentifier": null}. Daarvoor heb je User-OnPremisesSyncBehavior.ReadWrite.All nodig plus Global Administrator of Hybrid Identity Administrator.

Tenantinstellingen die je zelf kunt aanzetten

Je hoeft niet op juni te wachten. Het onPremisesDirectorySynchronization-object heeft twee features die het meeste werk doen: blockCloudObjectTakeoverThroughHardMatchEnabled blokkeert hard match-overname van cloudobjecten voor elke gebruiker, met of zonder rol, en blockSoftMatchEnabled blokkeert soft match voor alle objecten.
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 doet Set-EntraDirSyncFeature met de features BlockCloudObjectTakeoverThroughHardMatch en BlockSoftMatch hetzelfde. Beide vlaggen blokkeren ook de legitieme gevallen: een bestaande cloud-only gebruiker onder sync brengen, een gebruiker die buiten scope was en uit de prullenbak is teruggezet opnieuw in scope nemen, of directory sync op een tenant opnieuw aanzetten. Microsoft adviseert ze alleen uit te zetten zolang zo'n matching-klus loopt. In een grote omgeving zou ik het uit- en weer aanzetten als vaste stappen in het runbook van elke matching-klus opnemen.

Deze vlaggen gaan over cloudobjecten. Semperis meldde dat hun variant op gesynchroniseerde accounts nog steeds werkte met hard match-overname geblokkeerd, en dat is te verklaren: die variant koppelt een object dat al gesynchroniseerd is opnieuw, en dat is precies wat de OnPremisesObjectIdentifier-handhaving van juli aanpakt. Tot die tijd zijn de nieuwe audit-events je detectie. In Log Analytics:
AuditLogs
| where OperationName in ("Update user", "Set DirSyncEnabled flag")
| where tostring(TargetResources) has_any ("OnPremisesObjectIdentifier", "DirSyncEnabled")
| project TimeGenerated, InitiatedBy, TargetResources
Aan de AD-kant is het recht om ms-DS-ConsistencyGuid te schrijven op gebruikers in scope, of gebruikers aan te maken in gesynchroniseerde OU's, in feite een cloudprivilege. Dat hoort dus in je tiering-review thuis. Hetzelfde geldt voor iedereen die de credentials van de Connect Sync-applicatie kan beheren.

Draai deze week het inventarisatiescript, wis de anchor bij elke cloud-managed rolhouder die hem niet nodig heeft (emergency access-accounts eerst) en zet blockCloudObjectTakeoverThroughHardMatchEnabled en blockSoftMatchEnabled vóór 1 juni aan.

Update april 2026: Een dag na deze blog heeft Microsoft de rollbackstappen voor source of authority van gebruikers aangepast: ze beginnen nu met het uitzetten van blockCloudObjectTakeoverThroughHardMatchEnabled. De vlag die ik hierboven aanraad, blokkeert dus ook het terugdraaien van een source of authority-overdracht totdat je hem uitzet. Zet die stap in hetzelfde runbook, zodat niemand de bescherming voor een rollback uitzet en vergeet hem daarna weer aan te zetten.

Update juli 2026: Sinds 1 juli 2026 blokkeert Entra ID een hard match ook als de cloudgebruiker al een onPremisesObjectIdentifier heeft of eligible is voor een privileged rol, dus niet alleen bij een toegewezen rol, en die controle wordt in de cloud afgedwongen voor zowel Connect Sync als Cloud Sync. Cloud-managed accounts met writeback zijn uitgezonderd, en allowOnPremUpdateOfOnPremisesObjectIdentifierEnabled is beschikbaar als tijdelijke bypass tijdens het herstel. Zie Troubleshoot InvalidHardMatch errors.

Geschreven door een expert van Argus IT

Zo’n expert in je team, of zelf zo werken in security, IAM of cloud?

Samantha Kloos-Kilkens

Samantha Kloos-Kilkens

Samantha Kloos-Kilkens werkt al meer dan tien jaar in security en identity, waarvan acht jaar bij Microsoft in de productgroep Identity and Network Access. In 2023 richtte ze Argus IT op en ze heeft een zwak voor de verborgen pareltjes in Entra ID. CISSP, CCSP, CISM, CCSK en Microsoft Certified Trainer.

Blijf op de hoogte

Schrijf je in voor onze nieuwsbrief en ontvang een seintje wanneer we een nieuw artikel publiceren of nieuws te delen hebben.