Eksport via Microsoft Graph og PowerShell: dokumentation af kommandoerne

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

Når auditlog, loginlogs eller andre data fra Microsoft 365 eksporteres med PowerShell eller Microsoft Graph, er det selve forløbet, der skal kunne efterprøves: hvilken konto der kørte hvilke kommandoer, med hvilke parametre, mod hvilken tenant, med hvilke versioner af modulerne, og hvilke filer der kom ud. Et script giver bedre kontrol og mere fuldstændige data end eksport fra en brugerflade, men kun hvis det dokumenteres, så en anden sagkyndig kan forstå og gentage det. Uden den dokumentation er eksporten blot en fil, som ingen kan forklare.

Den generelle metode for indsamling via API og administratoreksport er beskrevet i Cloud-forensic: sikring via API og administratoreksport. Her går vi i dybden med dokumentationen af det scriptede arbejde.

Hvorfor script frem for brugerflade

Brugerflader har grænser for antal resultater, tidsvinduer og felter i eksporten, og de ændrer sig. Et script kan dele søgninger op, hente alle sider af et resultat, bevare det rå svar og gentages med samme parametre. Det gør det muligt at vise fuldstændighed. Omvendt kan et script fejle stille, fx hvis det rammer en grænse og stopper uden fejlmeddelelse. Derfor skal kontroller være bygget ind.

Typiske kilder, der eksporteres sådan:

Auditloggen via Exchange Online-modulets cmdlet til søgning i auditloggen eller via Graph-API’et til revisionssøgninger (auditLog queries). Cmdlet’en Search-UnifiedAuditLog returnerer som standard kun 100 poster pr. kald og højst 50.000 pr. søgesession med sideinddeling, og Graph-API’et har grænser for antal samtidige og daglige søgninger pr. tenant.
Loginlogs og ændringslogs i Entra ID via Graph; se Eksport af Entra ID-loginlogs.
Message trace via Exchange Online-modulet.
Konfiguration, fx postkasseregler, delegeringer, opbevaringspolitikker og app-registreringer.

Før første kommando

Brug en dedikeret konto eller app-registrering med de mindst nødvendige rettigheder, fx læseroller til revision. Notér konto, roller og tidspunkt for tildeling. Er det IT selv, der er bedt om at hente data om en kollega, se også Når IT bliver bedt om at undersøge en kollega.
Ved app-registrering: notér app-id, tilladelser (scopes), om de er delegerede eller applikationstilladelser, og hvem der godkendte dem. Brug certifikat frem for klienthemmelighed, og fjern adgangen efter sagen.
Notér tenant-id og domæne, så det er entydigt, hvilken organisation data kommer fra.
Notér modulversioner for PowerShell og de anvendte moduler. Funktionsmåden af cmdlets ændres mellem versioner.
Notér maskinens ur og tidszone, og synkronisér uret med en pålidelig kilde.

Under kørslen

Start en transskription af PowerShell-sessionen med den indbyggede funktion til transskription. Den logger kommandoer og output til en tekstfil og bør gemmes som en del af sagens materiale. Den erstatter ikke scriptet, men viser, hvad der faktisk blev kørt.

Gem scriptet selv i den version, der blev brugt, og beregn dets hashværdi. Ændres scriptet undervejs, gemmes hver version.

Del søgningen op. Søg i tidsintervaller, der er så korte, at intet interval rammer grænsen for antal resultater. Notér for hvert interval start, slut, antal returnerede poster og eventuel fejl. Rammer et interval grænsen, deles det yderligere op.

Håndtér sideinddeling. Graph returnerer store resultater i sider med et link til næste side. Scriptet skal følge alle links og logge antal sider og poster. Et script, der kun henter første side, giver en ufuldstændig eksport uden fejl.

Håndtér begrænsning og genforsøg. Microsoft begrænser antallet af kald. Scriptet skal registrere svar om begrænsning, vente og prøve igen, og loggen skal vise, at det skete. Notér også dubletter, der kan opstå ved genforsøg, og hvordan de håndteres.

Bevar det rå svar. Gem JSON-svaret, som det kom fra tjenesten, før nogen form for bearbejdning. Bearbejdning som udpakning af AuditData, filtrering og konvertering til regneark sker i en separat kopi.

Efter kørslen

Beregn hashværdier for alle outputfiler, transskriptionen og scriptet. Se Hashalgoritmer i forensic.
Kontrollér fuldstændighed: Summen af poster i delintervallerne bør svare til det samlede antal i outputfilerne efter fjernelse af dubletter. Forklar afvigelser.
Stikprøvekontrol: Udvælg poster og find dem i brugerfladen for at vise, at eksporten svarer til kilden.
Gentag en delsøgning senere og sammenlign. Forsinket indlæste hændelser kan give flere poster ved anden kørsel.
Notér i bevisloggen, hvor filerne ligger, og hvem der har adgang.

Konfiguration er også data

Ved mange undersøgelser er det ikke kun logs, der skal eksporteres, men tilstanden af konfigurationen: indbakkeregler, videresendelse på postkasser, delegeringer og rettigheder til postkasser, transportregler, app-registreringer og samtykker, betingede adgangspolitikker og opbevaringspolitikker. Konfiguration har ingen historik i sig selv. Det, der eksporteres, er tilstanden på eksporttidspunktet, og den kan ændres af oprydning kort tid efter.

Eksportér derfor konfigurationen tidligt og før afhjælpning, med samme dokumentation som for logs: kommando, parametre, tidspunkt, rå output og hashværdi. Gentag eksporten efter afhjælpningen, så forskellen kan vises. Hvornår en regel eller rettighed blev oprettet, findes ikke i konfigurationen, men i auditloggens administrative hændelser, og de to kilder skal kobles.

En handlingslog, der kan læses af andre

Transskriptionen er detaljeret, men svær at læse. Før derfor også en kort handlingslog med tidspunkt i UTC, handling, formål og resultat for hvert trin. Den gør det muligt for en advokat eller en anden sagkyndig at følge forløbet uden at læse PowerShell. Felterne er beskrevet i Skabelon: handlingslog.

Typiske fejl

Eksport til CSV direkte fra cmdlet uden rå JSON. Indlejrede felter flades ud eller afkortes, og den oprindelige struktur kan ikke genskabes.
Regneark åbnet og gemt igen. Regnearksprogrammer kan ændre datoformater, fjerne foranstillede nuller og omforme lange tal. Gem altid originalen uændret.
Lokal tid i filnavne og logs uden angivelse af tidszone.
Ubegrænsede tilladelser til app-registreringen, som giver adgang til langt mere end sagen kræver.
Manglende versionering af scriptet, så det ikke kan vises, hvilken udgave der lavede hvilken fil.
Fejl, der skjules af scriptets fejlhåndtering, så et mislykket interval ser tomt ud i stedet for fejlet.

Undersøgerens spor i tenanten

Kørsel af søgninger og eksporter registreres i auditloggen og i Entra ID’s logs for den konto eller app, der er brugt. Det er en del af dokumentationen: Det kan vises, at der kun er læst, og hvornår. Sørg for, at kontoen ikke bruges til andet under sagen, så sporene er rene.

Hvad eksporten kan og ikke kan bevise

En veldokumenteret eksport kan vise, at bestemte data fandtes i tjenesten på eksporttidspunktet, og at de ikke er ændret siden. Den kan ikke vise, at tjenesten selv havde registreret alt, og den kan ikke rette op på data, der var udløbet før eksporten. Fuldstændigheden er altid relativ til kilden: Eksporten kan vise, at alt, hvad tjenesten returnerede for de valgte kriterier, er med. Om tjenesten selv manglede hændelser, fx fordi logning var slået fra for en postkasse eller en hændelsestype, skal undersøges særskilt og beskrives i rapporten. Det gælder også, når kriterierne er valgt snævert af hensyn til persondata, for så er det et bevidst fravalg, der skal begrundes.

Dokumentation til rapporten

Angiv konto eller app med rettigheder, tenant, modulversioner, scriptets hashværdi, delintervaller med antal, håndtering af sider, begrænsning og dubletter, outputfiler med hashværdier, stikprøver og afvigelser. Vedlæg handlingsloggen som bilag.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Microsoft 365 og Entra ID: logkilderne

Læs også: Message trace, indholdssøgning eller auditlog: hvilket værktøj til hvilket spørgsmål · Defender XDR og Defender for Office 365 som datakilde

→ 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