Active Directory og domænecontroller‑logs: konti, grupper og nulstillinger

Forside › Windows-forensik · Gennemgået oktober 2026 · Af John Nielsen

Active Directory er stedet, hvor konti oprettes, får rettigheder og mister dem igen, og domænecontrollerne er de maskiner, der registrerer det. Domænecontrollernes sikkerhedslog kan vise, hvilken konto der oprettede en ny bruger, tilføjede en konto til administratorgruppen eller nulstillede en adgangskode, og hvornår. Men hver hændelse logges kun på den domænecontroller, der udførte den, sikkerhedsloggen dækker ofte kort tid, og nogle af de mest interessante hændelser kræver revisionsindstillinger, der ikke er standard. AD’s egne attributter og replikationsmetadata er derfor et vigtigt supplement.

Haster det? Sikkerhedsloggen på en domænecontroller er ofte den hurtigst roterende log i miljøet, så de relevante dage kan være overskrevet, før undersøgelsen er besluttet. Kontakt os via akut forensisk sikring; hastesager koster ekstra.

Overblikket over Windows’ kanaler og id’er findes i Windows-hændelseslogs. Her gennemgås domæneniveauet.

Kontohændelser

4720 · Brugerkonto oprettet
4722 og 4725 · Konto aktiveret og deaktiveret
4726 · Konto slettet
4738 · Konto ændret
4781 · Kontonavn ændret
4723 · Forsøg på at skifte egen adgangskode
4724 · Forsøg på at nulstille en andens adgangskode
4740 og 4767 · Konto låst og låst op

Hver post angiver den konto, der udførte handlingen (Subject), og den konto, der blev påvirket (Target). Det er netop sammenhængen mellem de to, der gør loggen værdifuld: Hvem nulstillede direktørens adgangskode, og fra hvilken session?

Gruppehændelser

Tilføjelse og fjernelse af medlemmer logges med forskellige id’er afhængigt af gruppetypen: globale grupper (4728 og 4729), domænelokale grupper (4732 og 4733) og universelle grupper (4756 og 4757). En tilføjelse til en privilegeret gruppe som domæneadministratorer er et af de vigtigste spor i sager om misbrug af administratorrettigheder. Id’erne gælder sikkerhedsgrupper; for distributionsgrupper bruges andre id’er. Hændelserne registreres kun, hvis revisionen af konto- og gruppeadministration er slået til i den effektive politik på domænecontrollerne.

Godkendelse på domænecontrolleren

Domænecontrolleren registrerer godkendelser, ikke logons på klienterne:

4768: Kerberos-billet til en konto (typisk ved logon), med klientens adresse.
4769: Kerberos-billet til en tjeneste, fx en filserver.
4771: Kerberos-forhåndsgodkendelse mislykkedes, fx forkert adgangskode.
4776: NTLM-godkendelse valideret.

Med disse kan det vises, fra hvilken adresse en konto blev godkendt, og hvilke tjenester den efterfølgende tilgik. Selve sessionen på klienten ses i klientens egen log; se Event 4624 og 4625.

Ændringer i katalogobjekter

Med revision af katalogtjenesteændringer slået til, og med de nødvendige revisionsindstillinger på objekterne, registreres ændringer af enkelte attributter som hændelse 5136 med gammel og ny værdi, samt oprettelse (5137) og sletning (5141) af objekter. Det giver et langt mere detaljeret billede end 4738, men er ofte ikke slået til. Underkategorien registrerer kun på domænecontrollere og kun for objekter, hvis revisionsliste (SACL) dækker den pågældende handling. Hændelser for gendannede (5138) og flyttede objekter (5139) hører til samme underkategori.

AD’s egne metadata

Selv uden logs gemmer Active Directory oplysninger, der kan datere ændringer:

whenCreated og whenChanged på hvert objekt.
pwdLastSet: hvornår adgangskoden sidst blev sat.
lastLogon: seneste logon registreret på den enkelte domænecontroller; den replikeres ikke og skal læses på hver domænecontroller.
lastLogonTimestamp: replikeres, men opdateres med en bevidst forsinkelse på op til ca. to uger og er derfor kun egnet til grove vurderinger.
Replikationsmetadata: For hver attribut registreres, hvornår den sidst blev ændret, på hvilken domænecontroller ændringen opstod, og et versionsnummer. Det kan vise, hvornår et bestemt medlemskab blev tilføjet, eller hvornår en adgangskode blev nulstillet, selv når sikkerhedsloggen for længst er overskrevet.

Slettede objekter bevares en tid som gravsten eller, med AD’s papirkurv slået til, som fuldt gendannelige objekter. Levetiden styres af skovens tombstoneLifetime og, med papirkurven, af msDS-deletedObjectLifetime, der som standard følger tombstoneLifetime. I skove oprettet med nyere serverversioner er standardværdien 180 dage, i meget gamle skove 60 dage, og værdien kan være ændret, så den skal aflæses i den konkrete skov. Det gør det muligt at dokumentere, at en konto har eksisteret, og hvornår den blev slettet.

Flere domænecontrollere

En handling logges på den domænecontroller, der behandlede den. I et domæne med flere domænecontrollere skal sikkerhedslogs derfor sikres fra dem alle, ellers kan en afgørende hændelse mangle. Replikationsmetadata angiver, hvilken domænecontroller en ændring opstod på, og viser dermed, hvor loggen skal findes.

Sikkerhedsloggen på en domænecontroller er ofte den hurtigst roterende log i hele miljøet. Er der en central logsamler eller et SIEM, vil den typisk være den bedste kilde for perioder længere tilbage; se SIEM-data som bevis.

Hybride miljøer

Synkroniseres AD med Entra ID, kan en ændring opstå lokalt og slå igennem i skyen eller omvendt. Hvordan ændringens oprindelse findes, står i Entra Connect og hybrid identitet. En gruppeændring i AD vises da i Entra ID som en ændring udført af synkroniseringstjenesten, ikke af den person, der lavede den. Den egentlige ophavskonto findes kun i den lokale domænecontrollers log. Privilegerede roller i skyen har deres egen historik; se Privilegerede roller i Entra ID.

Sikring

Eksportér Security-kanalen fra alle domænecontrollere som EVTX, og notér logstørrelse og ældste post; se Eksport af Windows-hændelseslogs.
Eksportér de relevante objekter med attributter og replikationsmetadata med AD’s egne værktøjer, og gem output i et format, der bevarer alle felter.
Dokumentér revisionspolitikken, som den var på sikringstidspunktet.
Overvej, om en kopi af hele katalogdatabasen er nødvendig. Den indeholder hashværdier af alle adgangskoder og skal i givet fald behandles med høj sikkerhed og kun bruges, hvor det er begrundet.

Sådan rekonstrueres en ændring

Et typisk spørgsmål er, hvem der nulstillede en bestemt kontos adgangskode, og hvad der skete bagefter. Fremgangsmåden kan være:

Læs pwdLastSet og replikationsmetadata for kontoen. Det giver tidspunktet og den domænecontroller, ændringen opstod på.
Find 4724 på den domænecontroller omkring tidspunktet. Posten angiver den udførende konto og dens logon-id.
Følg logon-id’et tilbage til den session, ændringen blev udført fra, og find kildeadressen.
Find 4768 og 4769 for den påvirkede konto efter nulstillingen. Det viser, om kontoen blev brugt, og hvorfra.
Sammenhold med klientens logs og eventuelle VPN-logs for at placere den udførende session på en bestemt maskine.

Samme fremgangsmåde kan bruges ved en gruppeændring: replikationsmetadata for gruppens medlemsattribut viser, hvornår et bestemt medlem blev tilføjet, også selvom sikkerhedsloggen er overskrevet. Metadata for flerværdiattributter kan opgøres pr. værdi, hvilket gør det muligt at datere hvert enkelt medlemskab.

Hvad loggene kan og ikke kan bevise

Domænecontrollerens logs og metadata kan vise, at en bestemt konto udførte en bestemt ændring på et bestemt tidspunkt fra en bestemt session. De viser ikke, hvilken person der brugte den udførende konto, og de viser ikke formålet. En nulstilling af en adgangskode kan være en helt almindelig supportopgave. Vurderingen kræver kendskab til de interne procedurer, fx om der findes en sag i supportsystemet, der svarer til ændringen.

Fejlkilder

Kun én domænecontroller sikret, så hændelser fra de andre mangler.
lastLogonTimestamp tolkes som præcis tid for seneste logon.
Synkroniseringskontoen tolkes som ophavsmand til ændringer, der reelt er foretaget lokalt.
Automatisering: Identitetsstyring, HR-integrationer og scripts opretter og ændrer konti under tjenestekonti.
Delte administratorkonti gør det umuligt at udpege en person ud fra loggen.

Er den undersøgte selv domæneadministrator, kan lokale logs og metadata være påvirket. Uafhængige kilder bliver da afgørende; se Undersøgelse af en administrator, der kan slette loggen. Virksomhedens side af en tidligere medarbejder, der stadig kan logge ind, er beskrevet i En tidligere medarbejder logger stadig ind.

Dokumentation

Angiv for hver afgørende ændring: domænecontroller, id, EventRecordID, tidspunkt, udførende og påvirket konto med SID, logon-id og kildeadresse, samt bekræftelse i replikationsmetadata, hvor det er muligt. Beskriv revisionspolitikken og loggenes dækningsperiode for hver domænecontroller.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: Autostart, planlagte opgaver og tjenester: spor efter fastholdt adgang · Defender-logs og karantæne som kilde

→ Forensisk undersøgelse af en computer · 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