Entra Connect og hybrid identitet: hvor blev ændringen lavet?

Forside › Microsoft 365 og Entra ID: logkilderne · Gennemgået oktober 2026 · Af John Nielsen

I et hybridt miljø, hvor det lokale Active Directory synkroniseres til Entra ID med Entra Connect Sync, er det kildemyndigheden, der afgør, hvor sporet efter en ændring ligger. For synkroniserede brugere og grupper er det lokale AD kilden. En ændring, der ses i Entra ID’s auditlog, er derfor ofte kun aftrykket af en handling, der blev udført lokalt, og den, der stod bag, findes kun i domænecontrollerens log. Undersøgelsen skal altså bruge tre steder: domænecontrolleren, synkroniseringsserveren og Entra ID.

Artiklen gennemgår, hvordan man fastslår, hvor en ændring opstod, og hvilke spor synkroniseringsserveren selv efterlader. Domænecontrollerens hændelser er beskrevet i Active Directory og domænecontroller-logs.

Kildemyndighed: hvem ejer objektet?

Et objekt i Entra ID er enten oprettet i skyen eller synkroniseret fra det lokale AD. I Microsoft Graph viser egenskaben onPremisesSyncEnabled, om brugeren synkroniseres, og onPremisesLastSyncDateTime, hvornår objektet sidst blev synkroniseret. I administrationscentret vises det som “Directory synced”.

For et synkroniseret objekt gælder:

Attributter, der kommer fra AD, kan som udgangspunkt ikke ændres i Entra ID. Ændringen skal laves lokalt og flyder så op ved næste synkronisering.
Gruppemedlemskab for synkroniserede grupper styres lokalt. En gruppe oprettet i skyen styres i skyen.
Adgangskoden ligger lokalt. Med synkronisering af adgangskodehash sendes en afledt hashværdi op; med pass-through-godkendelse eller føderation kontrolleres adgangskoden lokalt.

Det første spørgsmål i en undersøgelse er derfor ikke “hvem ændrede det i Entra ID?”, men “hvor ejes objektet?”. Svaret bestemmer, hvilken log der rummer den ansvarlige konto.

Sådan ser en synkroniseret ændring ud i skyen

Når Entra Connect skriver en ændring til Entra ID, registrerer Entra ID’s auditlog handlingen som udført af synkroniseringstjenestens egen identitet, ikke af den administrator, der lavede ændringen lokalt. Tidspunktet i Entra ID er tidspunktet for synkroniseringen, ikke for den lokale ændring. Med standardplanlægningen kører synkroniseringen ca. hver 30. minut, så forskydningen kan være op til en halv time eller mere, hvis planlæggeren har været stoppet eller ændret.

Det giver to typiske fejlslutninger:

At synkroniseringskontoen tolkes som den ansvarlige. Den er kun budbringeren.
At Entra-tidsstemplet bruges som handlingstidspunkt. Det korrekte tidspunkt findes i domænecontrollerens log, fx 4738 for ændring af en brugerkonto, 4728 eller 4732 for tilføjelse til en sikkerhedsgruppe og 4724 for nulstilling af adgangskode, og i AD’s replikeringsmetadata.

Ændringer foretaget direkte i skyen på objekter, der ejes i skyen, ses derimod med den rigtige konto i Entra ID. Hvordan man læser og eksporterer Entra ID’s auditlog, er beskrevet i Entra ID audit log: ændringer i brugere, apps og politikker.

Synkroniseringsserveren som datakilde

Serveren, der kører Entra Connect Sync, er en selvstændig og ofte overset datakilde. Den rummer:

Konfigurationen: hvilke domæner og OU’er der synkroniseres, filtreringsregler, synkroniseringsregler og loginmetode. Get-ADSyncScheduler viser planlæggerens interval, og om den er slået til.
Kørselshistorikken: Synchronization Service Manager viser kørsler med import, synkronisering og eksport pr. connector, herunder antal tilføjelser, opdateringer og sletninger og fejl pr. objekt. Historikken ryddes efter en periode, så den skal sikres tidligt.
Applikationsloggen: Fra version 2.4.129.0 logger Entra Connect Sync administratorhandlinger i Windows’ applikationslog under kilden Entra Connect Admin Actions. Det omfatter fx ændring af synkroniseringsregler (2610), ændring af OU-filtrering (2612), ændring af loginmetode (2613) og ændring af connectorens legitimationsoplysninger (2618). Microsoft anbefaler selv at øge applikationsloggens størrelse, fordi standardstørrelsen hurtigt overskrives.

Hændelserne viser, hvem der ændrede selve synkroniseringen. Det er afgørende i sager, hvor en OU er fjernet fra synkroniseringen, så brugere forsvandt fra Entra ID, eller hvor en regel er ændret, så en attribut pludselig blev overskrevet.

Typiske spørgsmål og hvor svaret ligger

Hvem føjede brugeren til den privilegerede gruppe? · Domænecontrollerens sikkerhedslog, hvis gruppen synkroniseres; ellers Entra ID’s auditlog
Hvorfor blev en konto slettet i Entra ID? · Kørselshistorikken på synkroniseringsserveren og AD (slettet objekt, ændret filtrering)
Hvem ændrede synkroniseringsreglerne? · Applikationsloggen på synkroniseringsserveren
Hvem nulstillede adgangskoden? · AD ved lokal nulstilling; Entra ID ved selvbetjening med tilbageskrivning

Den sidste række kræver opmærksomhed: Ved selvbetjent nulstilling med tilbageskrivning starter handlingen i skyen og afsluttes lokalt, så begge logs skal læses. Se Hvem nulstillede adgangskoden? og privilegier i skyen i Privilegerede roller i Entra ID.

Sikring

Synkroniseringsserveren bør sikres som en server med høj værdi, også fordi den har vidtgående rettigheder i både AD og Entra ID og derfor selv kan være et mål. Rækkefølgen kan være:

Eksportér applikationsloggen og sikkerhedsloggen fra synkroniseringsserveren som EVTX, før de overskrives.
Dokumentér konfigurationen: planlægger, connectorer, filtrering og synkroniseringsregler. Gem output med dato og administratorkonto.
Gem kørselshistorikken for den relevante periode.
Eksportér domænecontrollernes sikkerhedslogs fra alle domænecontrollere, da en ændring kun logges på den domænecontroller, der udførte den.
Eksportér Entra ID’s audit- og loginlogs for samme periode. Hash alle eksporter.

Stop ikke synkroniseringen uden en dokumenteret grund. Et stop ændrer tilstanden i skyen fremover og kan skjule, hvad der ville være sket. Er det nødvendigt at stoppe den af sikkerhedshensyn, noteres tidspunktet i indgrebsloggen.

Fejlkilder

Tidsforskydning: Lokal ændring og synkronisering i skyen ligger minutter eller timer fra hinanden. Korrelér på objekt og attribut, ikke kun på tid. Se Logkorrelation.
Flere domænecontrollere: Den lokale hændelse ligger kun på den domænecontroller, der behandlede ændringen.
Cloud Sync: Med Entra Cloud Sync i stedet for Connect Sync ligger synkroniseringens spor i Entra ID’s provisioneringslog og agentens lokale logs, ikke i Synchronization Service Manager.
Blandede objekter: Nogle objekter i samme tenant er synkroniserede, andre ikke. Kontrollér onPremisesSyncEnabled for hvert objekt i sagen.
Tilbageskrivning: Grupper og adgangskoder, der skrives tilbage fra skyen, vender kilden om for netop disse handlinger.

Dokumentation

Rapporten bør for hvert relevant objekt angive, om det var synkroniseret eller skyejet i hele perioden, og hvordan det er fastslået. Beskriv synkroniseringens opsætning på sikringstidspunktet: version af Entra Connect Sync, planlæggerens interval, filtrering og eventuelle ændringer i perioden med tidspunkt og konto fra applikationsloggen. Når en ændring i Entra ID føres tilbage til en lokal hændelse, skal begge poster gengives med tidsstempel i UTC, objekt-id og attribut, så læseren kan se koblingen. Angiv også, hvilke domænecontrollere der er sikret, og om nogen manglede. Mangler en domænecontroller, eller er loggen overskrevet, skal det stå som en begrænsning, ikke som fravær af handling.

Hvad sporene kan og ikke kan bevise

Kombinationen af AD, synkroniseringsserver og Entra ID kan normalt vise, hvilken konto der lavede en ændring, og hvornår den blev synlig i skyen. Den viser ikke, hvem der sad ved tastaturet. En administratorkonto kan være brugt af flere eller være kompromitteret, og koblingen til en person kræver andre spor. Skriv i rapporten, hvilken kilde der er primær for hvert fund, og hvilken der kun bekræfter.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Microsoft 365 og Entra ID: logkilderne

Læs også: Audit Standard eller Premium: hvad licensen betyder for undersøgelsen · Gæsteadgang og B2B i Microsoft 365-loggene

→ Microsoft 365-forensik · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik