Entra ID audit log: ændringer i brugere, apps og politikker

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

Entra ID’s revisionslog (audit log) registrerer ændringer i katalogets objekter: brugere, grupper, roller, applikationer, tjenesteprincipaler, godkendelsesmetoder, politikker og domæner. Hvor loginloggen viser, hvem der loggede ind, viser revisionsloggen, hvad der blev ændret, af hvem og med hvilke værdier før og efter. Microsoft angiver, at posterne er systemgenererede og ikke kan ændres eller slettes. Det gør loggen til en central kilde, men opbevaringen er kort.

Loginloggen er beskrevet i Entra ID sign-in logs, og rollehistorik i dybden i privilegerede roller. Denne artikel dækker revisionsloggen som helhed.

Felterne i en post

Hver post har nogle faste felter, som er vigtige at kende, før loggen fortolkes:

Tidspunkt (activityDateTime) i UTC.
Aktivitet (activityDisplayName), fx Update user eller Consent to application.
Kategori og tjeneste (category, loggedByService), fx UserManagement og Core Directory.
Igangsat af (initiatedBy): enten en bruger med UPN og IP-adresse eller en applikation eller tjenesteprincipal.
Mål (targetResources): det eller de objekter, der blev ændret, med modifiedProperties, hvor de gamle og nye værdier står.
Resultat og eventuel fejlårsag.
Korrelations-id (correlationId), der binder flere poster fra samme handling sammen.

Microsoft oplyser, at IP-adressen i revisionsloggen er klientens adresse set fra tjenesten. Det er ikke nødvendigvis brugerens offentlige adresse, hvis handlingen er udført af en tjeneste eller via en proxy.

Aktiviteter, der ofte er relevante

Add user, Delete user, Update user · Oprettelse, sletning og ændring af brugere, inkl. attributter
Reset password, Change user password, Reset password (by admin) · Nulstillinger og skift af adgangskode
Add member to role · Tildeling af en administratorrolle
Consent to application · Samtykke til, at en app får adgang til data
Add service principal credentials, Update application: Certificates and secrets management · Nye hemmeligheder eller certifikater til en app
Add, Update og Delete Conditional Access policy · Ændringer af betinget adgang
Set domain authentication, Set federation settings on domain · Ændring af, hvordan et domæne godkender brugere
Update StsRefreshTokenValidFrom Timestamp · Tilbagekaldelse af eksisterende sessioner

Ændringer af godkendelsesmetoder og MFA er beskrevet i MFA-ændringer og betinget adgang. Spørgsmålet om, hvem der nulstillede en adgangskode, er gennemgået i hvem nulstillede adgangskoden?.

Mønstre efter en kompromittering

Efter en overtaget administratorkonto eller et vellykket phishingangreb mod en privilegeret bruger ses ofte et genkendeligt mønster i revisionsloggen:

Samtykke til en ukendt app med brede rettigheder til mail eller filer.
Nye hemmeligheder eller certifikater på en eksisterende app eller tjenesteprincipal, så adgangen overlever et skift af adgangskode.
Nye ejere af apps eller grupper.
Svækkede eller deaktiverede politikker for betinget adgang.
Ændrede federationsindstillinger på et domæne.
Nye konti, eller eksisterende konti, der får roller.

Hver af disse handlinger kan være legitim drift. Det, der gør dem relevante, er tidspunktet, den igangsættende konto og sammenhængen med loginloggen.

Arbejdsgang ved en konkret ændring

Når en bestemt ændring skal undersøges, er rækkefølgen typisk:

Find posten for ændringen, og notér tidspunkt, aktivitet, mål og korrelations-id.
Saml alle poster med samme korrelations-id, så hele handlingen ses samlet.
Identificér den igangsættende konto eller app. Var det en bruger, så find kontoens login i loginloggen omkring tidspunktet: enhed, IP-adresse, godkendelsesmetode og session. Var det en app, så find ud af, hvem der ejer den, og hvornår den fik sine rettigheder.
Undersøg den igangsættende kontos egen historik. Fik kontoen sin rolle kort før ændringen? Blev dens metoder eller adgangskode ændret? En ændring udført af en nyligt kompromitteret administrator ser fuldstændig legitim ud, hvis man kun læser den ene post.
Sammenhold med Unified Audit Log og andre tjenesters logs for at se, hvad ændringen blev brugt til.

Kend det normale

Revisionsloggen er fyldt med rutineændringer: synkronisering, licenstildeling, automatiske processer og administratorernes daglige arbejde. Uden et billede af, hvad der normalt sker i tenanten, er det svært at se, hvad der skiller sig ud. En optælling af aktiviteter og igangsættende konti over en normal periode giver en baseline, som afvigelser kan måles mod.

Opbevaring

Ifølge Microsoft gemmes revisionsloggen ved gennemgangen (oktober 2026) i 7 dage med Entra ID Free og i 30 dage med P1 eller P2. En opgradering af licensen virker ikke tilbage i tid. Længere opbevaring kræver, at loggen sendes videre via diagnostiske indstillinger til Log Analytics, en lagerkonto eller en SIEM. Microsoft nævner også, at Purview Audit (Premium) kan bruges til at bevare Entra ID-revisionsposter længere. Mange af de samme hændelser findes desuden i Microsoft 365’s samlede auditlog med dens egen opbevaring; se Unified Audit Log.

Det betyder i praksis, at den første opgave ved en hændelse er at afklare, hvor langt tilbage de forskellige kopier af loggen rækker, og at eksportere med det samme.

Eksport og dokumentation

Portalen kan downloade poster som CSV eller JSON, men den egner sig bedst til overblik. Til en sag er Microsoft Graph mere robust: endpointet auditLogs/directoryAudits kan hentes med Get-MgAuditLogDirectoryAudit i PowerShell med et filter på tid og aktivitet. JSON bevarer den fulde struktur, inklusive modifiedProperties, som CSV-eksport kan forenkle. Gem kommandoen, tidspunktet, den konto og de rettigheder, der blev brugt, og beregn hashværdier af de eksporterede filer. Se eksport via Graph og PowerShell.

Er loggen sendt til Log Analytics, ligger den i tabellen AuditLogs. Forespørgslen og dens resultat dokumenteres på samme måde. Sammenlign antallet af poster i Log Analytics med en eksport fra Graph for samme periode, hvis begge findes. Afvigelser kan skyldes forsinkelse i videresendelsen eller filtre i de diagnostiske indstillinger og skal forklares.

Typiske fejlkilder

Igangsat af en tjeneste. Mange poster er igangsat af en tjenesteprincipal eller af Microsofts egne systemer, fx synkronisering mellem Exchange Online og Entra ID. Det er ikke en person, og det skal forstås, før posten tolkes.
Synkronisering fra lokalt AD. I hybride miljøer kan en ændring i Entra ID være resultatet af en ændring i det lokale Active Directory, synkroniseret af en tjenestekonto. Den egentlige handling skal så findes i domænecontrollerens log.
Manglende værdier. modifiedProperties er ikke altid udfyldt, og nogle værdier forkortes. Fravær af en gammel værdi betyder ikke, at feltet var tomt.
Flere poster for én handling. En handling i portalen kan give flere poster med samme korrelations-id. De skal læses samlet.
Tidszoner. Portalen viser lokal tid, eksporten UTC.

Hvad loggen kan og ikke kan bevise

Revisionsloggen kan vise, at en bestemt konto eller app udførte en bestemt ændring på et bestemt tidspunkt, og hvad der blev ændret. Den viser ikke, hvem der sad bag kontoen, og den viser ikke, hvad den ændrede konfiguration efterfølgende blev brugt til. Det kræver loginlog, Unified Audit Log og eventuelt data fra endpoints. Rapporten bør angive, hvilken periode den eksporterede log dækker, og om der fandtes kopier med længere opbevaring. Konklusionen bør derfor altid bygge på en sammenkobling af revisionsloggen med mindst én anden kilde.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Microsoft 365 og Entra ID: logkilderne

Læs også: Teams-opkald og møder: opkaldsposter, deltagerdata og optagelser · Hvem nulstillede adgangskoden? Spor i AD, Entra ID og Google Workspace

→ 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