Entra ID sign‑in logs: felter, fejlkoder og fortolkning

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

Loginloggen i Microsoft Entra ID er den centrale kilde, når spørgsmålet er, hvem der loggede ind på en konto i Microsoft 365, hvorfra og hvordan. Hver post er rig på detaljer: klientapp, enhed, godkendelsesmetode, resultatet af politikker for betinget adgang og en fejlkode, hvis noget gik galt. Men posterne er fordelt på flere kategorier, felterne betyder ikke altid det, navnene antyder, og den samme handling kan give mange poster. En korrekt tolkning kræver, at man kender opbygningen.

Haster det? Loginloggen gemmes kun 7 dage uden betalt Entra ID-licens og 30 dage med, så de ældste relevante dage forsvinder hver dag, sagen venter. Kontakt os via akut forensisk sikring; hastesager koster ekstra.

Mekanismerne bag sessioner og tokens og de generelle fejlkilder ved IP-adresser og placering er beskrevet i Sessioner, tokens og loginlogs. Den praktiske håndtering af et mistænkeligt login står på bevissikring-digitalt.dk. Her går vi i dybden med selve loggen. Hvordan loggen eksporteres fuldstændigt, står i Eksport af Entra ID-loginlogs, og de typiske angrebsmønstre i AiTM-phishing og Password spray og brute force.

Fire kategorier

Interaktive brugerlogins · Logins, hvor brugeren selv angav noget, fx adgangskode eller totrinsgodkendelse
Ikke-interaktive brugerlogins · Logins udført af en klient på brugerens vegne, typisk med et eksisterende token
Serviceprincipal-logins · Apps og automatiseringer, der logger ind med egne legitimationsoplysninger
Administrerede identiteter · Azure-ressourcer, der logger ind med en identitet styret af platformen

De ikke-interaktive logins er langt de fleste og overses ofte. De er dog afgørende, når en angriber bruger et stjålet token, fordi den efterfølgende brug af tokenet typisk kun ses dér. En undersøgelse af en brugerkonto skal altid omfatte begge brugerkategorier.

De vigtigste felter

Tidspunkt i UTC.
Anmodnings-id og korrelations-id, der binder poster fra samme loginforløb sammen.
Sessions-id, der kan følge en session på tværs af tokenfornyelser. Det optræder også i fx Graph-aktivitetslogs og postkasseauditering, men ikke i auditloggen.
Applikation og ressource: Hvilken app der loggede ind, og hvilken tjeneste der blev bedt om adgang til, fx Exchange Online eller SharePoint.
Klientapp: Browser, moderne mobil- og skrivebordsklienter eller en ældre protokol som IMAP, POP, SMTP eller Exchange ActiveSync.
Brugeragent, som klienten selv opgiver.
IP-adresse og omtrentlig placering.
Enhedsoplysninger: Enheds-id, styresystem, browser, og om enheden er tilmeldt, administreret og compliant.
Godkendelseskrav og -detaljer: Enkelt- eller flerfaktor, hvilken metode der blev brugt, og om kravet blev opfyldt af et krav i et eksisterende token.
Betinget adgang: Samlet status og resultatet for hver politik, inklusive politikker i rapporteringstilstand.
Status og fejlkode.
Risikofelter, hvis organisationen har licens til risikobaseret identitetsbeskyttelse.

Godkendelse: hvad betyder “MFA opfyldt”?

Feltet for godkendelseskrav viser, om der krævedes flerfaktorgodkendelse. Detaljerne viser, hvordan kravet blev opfyldt. Står der, at kravet blev opfyldt af et krav i tokenet, er der ikke udført ny totrinsgodkendelse i dette login; den blev udført tidligere, og tokenet bærer resultatet videre. Det er normalt for en bruger, der arbejder løbende, men det er også præcis det mønster, der ses, når et stjålet token genbruges fra en anden enhed. Kendetegnene ved den situation er beskrevet i AiTM-phishing: kendetegn på stjålne sessioner i loginloggen.

Fejlkoder

Hver mislykket post har en numerisk fejlkode med en kort forklaring. Nogle af de hyppigste i undersøgelser:

0 · Lykkedes
50126 · Forkert brugernavn eller adgangskode
50053 · Kontoen er låst efter mange forsøg, eller login blev blokeret fra en IP-adresse med ondsindet aktivitet; årsagen står i loggens fejlbeskrivelse
50074 og 50076 · Stærk godkendelse kræves; brugeren blev bedt om totrinsgodkendelse
500121 · Stærk godkendelse mislykkedes eller blev afvist
53003 · Blokeret af en politik for betinget adgang
50057 · Kontoen er deaktiveret

Kode 500121 står ikke i Microsofts oversigt over AADSTS-koder; brug loggens fejlbeskrivelse.

Koderne skal læses i sammenhæng. Forkert adgangskode fra mange adresser er typisk automatiserede forsøg; se Password spray og brute force. Korrekt adgangskode efterfulgt af et krav om totrinsgodkendelse, der ikke blev gennemført, betyder derimod, at adgangskoden var kendt. Det er et vigtigt fund, selv om login ikke lykkedes.

Betinget adgang

For hvert login viser loggen, hvilke politikker for betinget adgang der blev evalueret, og resultatet: opfyldt, ikke opfyldt eller ikke anvendt. Politikker i rapporteringstilstand vises med det resultat, de ville have haft. Det gør det muligt at vise, hvorfor et login fra et bestemt land blev tilladt eller blokeret, og om en politik, der burde have stoppet det, ikke omfattede den pågældende app eller klient. Politikkernes indhold i perioden skal sikres sammen med loggen, fordi de kan være ændret siden.

Ældre protokoller

Logins med IMAP, POP, SMTP med godkendelse og andre ældre protokoller understøtter ikke moderne totrinsgodkendelse og har været et kendt angrebsmål. Microsoft har udfaset grundlæggende godkendelse for de fleste protokoller i Exchange Online. SMTP AUTH var ved gennemgangen stadig tilgængelig med grundlæggende godkendelse, men med en annonceret udfasning, så status i den konkrete tenant og periode skal kontrolleres. Findes der lykkedes logins med ældre protokoller i perioden, skal det undersøges, hvordan det var muligt.

Serviceprincipaler og apps

Logins fra apps med egne legitimationsoplysninger optræder ikke i brugerens loginlog, men i loggen for serviceprincipaler. Det er relevant, når en angriber har oprettet en app, tilføjet en hemmelighed eller et certifikat til en eksisterende app eller fået samtykke til en app med brede rettigheder. Brugen af appen ses så som serviceprincipal-logins fra adresser, der ikke passer til appens normale drift. Sammenhold med auditloggens hændelser om oprettelse af apps, tilføjelse af legitimationsoplysninger og samtykke. Hvor de forskellige logs i Microsoft 365 og Entra ID hører hjemme, og hvad de hver især dækker, er samlet på siden Microsoft 365 og Entra ID: logkilderne samlet.

Fra poster til forløb

En god arbejdsmetode er at gruppere posterne, før de tolkes. Først efter korrelations-id, så hvert loginforløb står samlet med sine delresultater. Dernæst efter sessions-id eller enheds-id, så det kan ses, hvilke forløb der hører til samme klient over tid. Til sidst lægges forløbene ind i en tidslinje sammen med auditlogs og postkassehændelser. Det reducerer ofte tusindvis af poster til et overskueligt antal sessioner, hvoraf de fleste kan forklares som ejerens egne enheder. Tilbage står de sessioner, der kræver en forklaring.

Opbevaring og eksport

Loginloggen gemmes kun en begrænset periode i Entra ID, og perioden afhænger af licensen; på tidspunktet for gennemgangen (oktober 2026) angav Microsoft 7 dage uden betalt Entra ID-licens og 30 dage med. Længere historik kræver, at organisationen på forhånd har sendt loggen til et eget logarkiv. Eksport fra portalen har begrænsninger i antal poster og felter; den fuldstændige metode er beskrevet i Eksport af Entra ID-loginlogs.

Typiske fejlkilder

Kun interaktive logins gennemgået: Den efterfølgende brug af et stjålet token overses.
Placering tages bogstaveligt: IP-baseret placering er usikker; se IP-adresser som bevis.
Et login er mange poster: Ét loginforløb kan give flere poster med samme korrelations-id, herunder mislykkede trin, der hører til et samlet lykkedes forløb.
Brugeragent er brugerangivet: Den kan forfalskes og skal støttes af andre felter.
Status “ikke anvendt”: Betyder, at politikken ikke omfattede login, ikke at den blev opfyldt.

Hvad loggen kan og ikke kan bevise

Loginloggen kan vise, at kontoen blev brugt fra en bestemt klient, enhed og netværksadresse, hvordan godkendelsen skete, og hvilke politikker der blev anvendt. Den kan ikke alene vise, hvem der betjente klienten. Konklusioner bygger på mønstre på tværs af poster og på kobling til enheder og andre logs.

Dokumentation

Angiv kategorier, periode, licens og opbevaring, eksportmetode og hashværdier, de felter konklusionerne bygger på, politikkerne for betinget adgang i perioden og tidszonen. De afgørende poster gengives med korrelations- og anmodnings-id, så de kan genfindes i den rå eksport.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Microsoft 365 og Entra ID: logkilderne

Læs også: Indbakkeregler og videresendelse: opdagelse og datering i Microsoft 365 · Eksport af Entra ID-loginlogs: fuldstændig og dokumenteret

→ Microsoft 365-forensik · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · 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