DigitalForensics

70 13 63 23

Eksport af Entra ID‑loginlogs: fuldstændig og dokumenteret

Eksport af Entra ID-loginlogs: fuldstændig og dokumenteret

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

En eksport af loginlogs fra Microsoft Entra ID er kun et godt bevis, hvis den er fuldstændig, og hvis det kan vises, at den er det. Det lyder enkelt, men de fire veje til loggen, portalen, PowerShell, Microsoft Graph og et eget logarkiv, giver forskellige felter, forskellige grænser og forskellige muligheder for at gentage eksporten. De mest almindelige fejl er huller ved tidsvinduernes grænser, manglende ikke-interaktive logins og felter, der går tabt, når filen åbnes i et regneark.

Haster det? De ældste dage i loginloggen forsvinder først, efter 7 eller 30 dage afhængigt af licensen, så eksporten skal begynde med dem. Ved akut behov: akut forensisk sikring; hastesager koster ekstra.

Hvad loggen indeholder, og hvordan felterne tolkes, er beskrevet i Entra ID-loginlogs: felter, fejlkoder og fortolkning. Her handler det om selve eksporten.

De fire veje

  • Portalen · Styrke: Hurtig og uden scripts · Svaghed: Grænse for antal poster, flad CSV, svær at gentage præcist
  • PowerShell med Graph-modulet · Styrke: Kan scriptes og gentages · Svaghed: Kræver korrekt håndtering af sideopdeling og filtre
  • Microsoft Graph direkte · Styrke: Fuld kontrol over forespørgsel og format · Svaghed: Kræver app-registrering eller delegeret adgang med de rette rettigheder
  • Eget logarkiv (fx Log Analytics) · Styrke: Længere historik og forespørgsler på tværs · Svaghed: Kun data fra det tidspunkt, hvor videresendelsen blev sat op

Microsoft angiver på tidspunktet for gennemgangen (oktober 2026), at portalen kan hente op til 100.000 loginposter og 250.000 revisionsposter pr. fil. En fil, der rammer grænsen præcist, er derfor et tegn på, at der mangler poster.

Den sikreste fremgangsmåde i en sag er typisk en scriptet eksport via Graph eller PowerShell i JSON, suppleret med en eksport fra logarkivet, hvis det findes. Portalen kan bruges til en hurtig første sikring, når tiden er knap, men bør efterfølges af en fuldstændig eksport.

Alle kategorier skal med

Standardforespørgsler returnerer ofte kun interaktive brugerlogins. Ikke-interaktive brugerlogins, serviceprincipal-logins og logins fra administrerede identiteter skal hentes eksplicit, og i nogle grænseflader kræver det en anden version af API’et eller en særskilt tabel i logarkivet. I Microsoft Graph returnerer forespørgslen på loginloggen kun interaktive logins, medmindre der filtreres eksplicit på hændelsestypen, hvilket på tidspunktet for gennemgangen (oktober 2026) kun var dokumenteret i beta-versionen. I Log Analytics ligger kategorierne i hver sin tabel. Dokumentér for hver kategori, at den er hentet, og hvor mange poster der kom.

JSON frem for CSV

Loginposter har indlejrede strukturer: godkendelsesdetaljer med flere trin, en liste over politikker for betinget adgang med hvert sit resultat, enhedsoplysninger og placering. CSV-eksport flader strukturen ud, udelader dele af den eller splitter den i flere filer. JSON bevarer posten, som tjenesten returnerede den. Gem JSON som den primære eksport, og lav eventuelle tabeller til analyse som afledte filer.

Åbn aldrig den primære eksport direkte i et regneark og gem den igen. Regneark kan omformatere tidsstempler til lokal tid, afkorte lange id’er, fjerne foranstillede nuller og ændre tegnsæt. Lav en kopi til analyse, og lad originalen være urørt.

Tidsvinduer og sideopdeling

Store eksporter deles op i tidsvinduer, fx ét døgn ad gangen. To fejl går igen:

  • Grænserne: Vinduer, der både starter og slutter på samme klokkeslæt, kan give dubletter eller huller, afhængigt af om grænsen er inklusiv. Brug halvåbne intervaller, fx fra og med midnat til før næste midnat, og skriv det ned.
  • Sideopdeling: Graph returnerer resultatet i sider med et link til næste side. Afbrydes løkken, fx på grund af begrænsning af anmodninger eller et udløbet token, ser eksporten fuldstændig ud, men mangler resten. Scriptet skal logge hver side og fejle tydeligt, hvis en side ikke kan hentes.

Alle tider angives i UTC i forespørgslen. Lokale tider i scriptet er en klassisk kilde til en times forskydning, især omkring sommertid.

Filtrering på bruger

Filtrér på brugerens objekt-id frem for brugernavnet, hvis det er muligt. Brugernavne kan ændres, og en konto kan have haft et andet navn i perioden. Gæstebrugere og konti fra andre tenants logger ind med deres hjemmeidentitet, og deres poster kan se anderledes ud. Se Gæsteadgang og B2B i Microsoft 365-loggene. Overvej, om der også bør eksporteres ufiltreret for perioden, så logins fra ukendte konti mod samme ressourcer kommer med.

Kontrol af fuldstændighed

  1. Optælling pr. døgn og kategori: Sammenlign med det antal, portalen eller logarkivet viser for samme periode.
  2. Kontinuitet: Kontrollér, at der ikke er døgn uden poster, hvor brugeren normalt arbejdede.
  3. Gentagelse: Kør eksporten af et udvalgt døgn igen, og sammenlign antal og id’er. Nye poster kan være kommet til på grund af forsinkelse, men ingen må være forsvundet.
  4. Grænseposter: Kontrollér poster tæt på vinduernes grænser.

Loginposter kan dukke op med forsinkelse. En eksport, der tages lige efter en hændelse, kan mangle de seneste poster. Tag en supplerende eksport senere for den sidste del af perioden.

Når loggen er ved at udløbe

Opbevaringen i Entra ID er kort, og den afhænger af licensen; hvad det betyder for virksomheden, er beskrevet på bevissikring-digitalt.dk. Er hændelsen tæt på grænsen, gælder en anden prioritering end ved en rolig eksport. Tag først de ældste dage, fordi de forsvinder først, og brug den hurtigste vej, der giver fuldstændige poster, også selv om det betyder en portaleksport i første omgang. Notér klokkeslættet for eksporten, så det kan ses, hvor langt tilbage loggen rakte på det tidspunkt. Sæt derefter videresendelse til et eget logarkiv op, så de kommende dage ikke går tabt, mens resten af undersøgelsen planlægges.

Auditloggen i samme omgang

Entra ID har ud over loginloggen en auditlog over ændringer i katalog, roller, apps og godkendelsesmetoder. Den har samme opbevaringsbegrænsning og bør eksporteres i samme omgang og efter samme principper, fordi mange spørgsmål om logins først kan besvares med ændringerne ved siden af: Hvornår blev en ny godkendelsesmetode registreret, hvornår blev en app godkendt, og hvornår blev en rolle tildelt?

Rettigheder og konto

Eksporten kræver læserettigheder til revisions- og loginlogs. Brug en konto eller app med netop de rettigheder og ikke mere, og notér, hvilken identitet der blev brugt. Er det en administrators konto, der er under mistanke, bør eksporten foretages med en anden identitet, og helst af en uafhængig part. Auditloggen registrerer ændringer, ikke læsninger, så eksporten efterlader normalt ikke spor dér. Har organisationen slået Microsoft Graph-aktivitetslogs til, registreres API-kaldene dog i dem, hvilket kan bruges til at dokumentere eksporten. Ellers er eksportørens egen log af kommandoer og tidspunkter dokumentationen.

Dokumentation af kommandoerne

Gem scriptet i den version, der blev kørt, med modulversioner, forespørgsler og filtre. Gem konsollens output eller en logfil fra kørslen. Den generelle metode til at dokumentere kommandoer er beskrevet i Eksport via Microsoft Graph og PowerShell.

Hash og opbevaring

Beregn hashværdier for hver eksportfil umiddelbart efter kørslen, og registrér dem i en hashlog sammen med periode, kategori og antal poster; se Skabelon: hash-log. Bemærk, at en ny eksport af samme periode sjældent giver samme hashværdi, fordi rækkefølge, forsinkede poster og formatering kan variere. Det er forventeligt og forklaret i Mobiludtræk og cloud-eksporter: hvorfor hashværdien ikke kan gentages. Det er den første eksport og dens hashværdi, der fastholder beviset.

Typiske fejlkilder

  • Kun interaktive logins eksporteret.
  • Portalens grænse ramt uden at det blev opdaget.
  • CSV åbnet og gemt i et regneark.
  • Huller ved vinduesgrænser eller afbrudt sideopdeling.
  • Opbevaringsgrænsen passeret: Den tidligste del af perioden findes ikke længere og skal angives som en begrænsning.

Hvad eksporten kan og ikke kan bevise

En dokumenteret eksport kan vise, hvad loggen indeholdt for perioden på eksporttidspunktet. Den kan ikke vise poster, der var udløbet, og den kan ikke rette op på, at logning ikke var sat op til et arkiv i tide. Begrænsningerne hører med i rapporten.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Microsoft 365 og Entra ID: logkilderne

Læs også: Entra ID sign-in logs: felter, fejlkoder og fortolkning · MFA-ændringer og betinget adgang i Entra ID-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

John Nielsen, IT-sagkyndig

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.