Hva er nytt

Microsoft har annonsert en sikkerhetsendring for Microsoft Entra Connect Sync og Microsoft Entra Cloud Sync.

Fra 1. juni 2026 vil Microsoft Entra ID blokkere forsøk på å hard-matche et nytt Active Directory-brukerobjekt til en eksisterende skystyrt Entra ID-bruker når den skystyrte brukeren har en Microsoft Entra-rolle tilordnet.

Hard match er prosessen der Entra Connect Sync eller Cloud Sync matcher et innkommende Active Directory-objekt til et eksisterende skyobjekt ved å bruke source anchor / onPremisesImmutableId. Hvis matchen lykkes, kan det synkroniserte objektet overta autoritetskilden for skyobjektet.

For vanlige brukere er denne oppførselen en del av mange hybrididentitetsmigrasjonsmønstre. For privilegerte skykontoer er den mer risikabel. Microsoft sier den nye sikkerhetsmekanismen er ment å forhindre angripere i å overta privilegerte skystyrte brukere ved å manipulere Active Directory-attributter.

Hvorfor administratorer bør bry seg

Dette er ikke en kosmetisk endring. Det påvirker hybrididentitetsoperasjoner, spesielt i miljøer som fortsatt har en blanding av skystyrte og synkroniserte identiteter.

Det viktige er omfanget:

  • Det gjelder skystyrte brukere som har Microsoft Entra-roller.
  • Det blokkerer nye hard-match-overskrivingsforsøk for disse privilegerte brukerne.
  • Det påvirker ikke skybrukere uten Microsoft Entra-roller.
  • Soft match-atferd er ikke endret.
  • Eksisterende tidligere hard-matchede objekter fortsetter å synkronisere.

I praksis er dette en god sikkerhetsstandard. Men det kan overraske administratorer under migrasjoner, tenant-opprydding, kontogjenoppretting eller hybrididentitetskonsolidering hvis privilegerte skykontoer ikke er gjennomgått først.

Hva jeg ville sjekket først

Før enhver hybrididentitetsmigrering eller opprydding ville jeg sjekket tre ting:

  1. Hvilke skystyrte kontoer har Microsoft Entra-roller tilordnet.
  2. Om noen av disse kontoene allerede har onPremisesImmutableId utfylt.
  3. Om noe planlagt synkroniseringsarbeid forventer å konvertere disse kontoene fra skystyrte til synkroniserte via hard match.

Jeg ville også skilt menneskelige admin-kontoer fra break-glass- og tjenestelignende admin-kontoer. Målet er ikke å tvinge alle kontoer inn i samme mønster. Målet er å unngå uventede autoritetskildeendringer for privilegerte identiteter.

Praktisk utrulling / valideringstrinn

For et Microsoft 365- eller Entra-adminteam ville jeg behandlet dette som en liten identitetsstyringssjekk:

  1. Gå til Microsoft Entra admin center > Roles & admins og se gjennom brukere med aktive eller kvalifiserte privilegerte roller.
  2. I Microsoft Entra admin center > Users, bekreft hvilke privilegerte brukere som er skystyrte versus synkroniserte.
  3. For eventuelt kommende Entra Connect Sync- eller Cloud Sync-arbeid, dokumenter om hard match er forventet.
  4. Hvis en privilegert skykonto må håndteres under migrering, test sekvensen i en pilot først og følg Microsofts veiledning hvis den nye konflikten oppstår.
  5. Hold break-glass-kontoer skybare med mindre det er en tydelig dokumentert grunn til å endre dem.

Det som endret seg for meg etter å ha lest denne kunngjøringen, er rekkefølgen på forhåndssjekkene. Jeg ville nå satt privilegert-rolle-gjennomgang før hard-match-planlegging, ikke etter at synkroniseringsfeilen dukker opp.

Hva du bør passe på

Hovedrisikoen er operativ friksjon under migrasjoner. En blokkert hard match er bedre enn en stille privilegert konto-overskriving, men den kan fortsatt avbryte en planlagt cutover hvis ingen forventet den nye oppførselen.

Ikke behandle onPremisesImmutableId som bare nok et oppryddingsattributt. For privilegerte kontoer er det en del av kontrollplanet for autoritetskildebeslutninger.

Dette er også et godt tidspunkt å vurdere om privilegerte kontoer bør synkroniseres i det hele tatt. Mange miljøer har nytte av å holde nødkontoer skybare og tett styrt.

Offisielle Microsoft-kilder