Windows logger kun de hændelser, revisionspolitikken beder om. Kontrollen består i at læse den gældende politik på domænecontrollere og servere, underkategori for underkategori, og holde den op mod en baseline for lykkede og mislykkede hændelser.
Det er den indstilling, alle senere spørgsmål om loggen hviler på. En central opsamling kan ikke samle hændelser, der aldrig blev skrevet, og en alarmregel kan ikke reagere på en hændelse, Windows ikke logger.
Windows’ standard er ikke en baseline
Microsoft offentliggør en tabel over revisionsindstillinger, som SAMSIK’s vejledning om logning henviser til. For hver underkategori viser tabellen Windows’ standard, en grundanbefaling og en stærkere anbefaling. Et par eksempler for Windows Server viser afstanden:
- Credential Validation: standard ingen, grundanbefaling succes og fejl.
- Security Group Management: standard ingen, grundanbefaling succes og fejl.
- Process Creation: standard ingen, grundanbefaling succes.
- Audit Policy Change: standard kun succes, grundanbefaling succes og fejl.
- Directory Service Access og Directory Service Changes anbefales på domænecontrollere.
Microsoft kalder anbefalingerne et udgangspunkt for en baseline. Hver organisation beslutter selv og bør teste ændringer, før de sættes i produktion. Microsoft anbefaler også at overvåge klienterne ud over servere og domænecontrollere.
Læs den gældende politik
Den politik, der faktisk gælder på en maskine, læses med den indbyggede kommando auditpol /get /category:*. Tilføjes /r, kommer svaret som CSV, der kan lægges i et regneark. Kommandoen kræver læseret til objektet eller rettigheden Manage auditing and security log, så driften kan køre den uden at have fulde administratorrettigheder overalt.
Kør kommandoen på mindst én domænecontroller og på en stikprøve af servere pr. rolle. Svaret viser den effektive indstilling, også når den kommer fra en gruppepolitik, der er arvet flere niveauer oppe. Sammenlign derefter linje for linje med jeres baseline. Afvigelserne er fundene.
Et tænkt udtræk kan vise, at Security Group Management står til “No Auditing” på en filserver. Så bliver det aldrig logget, når nogen lægges i en lokal administratorgruppe på netop den server.
Hvad der skal med
SAMSIK’s vejledning nævner lykkede og mislykkede revisionshændelser på tværs af platforme og blokerede PowerShell-scripts blandt de kilder, der bør overvejes. For de enheder, der er omfattet af forordning 2024/2690, lister bilagets punkt 3.2.3 blandt andet nye og ændrede brugere og rettigheder, logon og brug af privilegerede konti som noget, logfilerne skal rumme, hvor det er relevant. Det svarer til underkategorierne for kontoadministration, legitimationskontrol og ændringer i gruppemedlemskab.
Microsoft beskriver to slags hændelser, der bør overvåges og give alarm. Den ene er enkeltstående hændelser, der i sig selv er stærke tegn på uautoriseret aktivitet. Den anden er en ophobning af hændelser ud over en forventet basislinje. SAMSIK bruger samme opdeling i afsnittet om autentificeringsservere. Revisionspolitikken skal skrive begge slags, ellers har alarmerne intet at arbejde med.
Scriptkørsel i PowerShell 7
For PowerShell 7 beskriver Microsoft script block logging, som registrerer indholdet af alle scriptblokke, når den er slået til. Den slås til med gruppepolitikken “Turn on PowerShell Script Block Logging”, og hændelserne står som 4104 i Operational-loggen. Microsoft anbefaler samtidig beskyttet hændelseslogning, fordi scriptindhold kan rumme følsomme oplysninger.
Forbehold: Microsofts beskrivelse gælder PowerShell 7. Windows PowerShell 5.1, der følger med Windows, har sin egen dokumentation, som ikke er læst til denne artikel. Hvad 5.1 logger som standard, står derfor ikke her. Kontrollér gruppepolitikken for den version, I faktisk bruger.
Stikprøven og de maskiner, der falder udenfor
Revisionspolitikken kommer typisk fra en gruppepolitik, der er koblet på en bestemt organisationsenhed. Servere, der står et andet sted i kataloget, får den ikke. Det gælder også maskiner, der ikke er med i domænet, fx en enkeltstående server i et adskilt net. Vælg derfor stikprøven, så den rammer hver organisationsenhed med servere, og mindst én maskine uden for domænet, hvis I har sådanne.
Ser udtrækkene ens ud på alle maskiner i stikprøven, er det et godt tegn. Afviger én, er spørgsmålet, om det skyldes en lokal ændring, en anden placering i kataloget eller en gruppepolitik med højere prioritet. Svaret afgør, hvor rettelsen skal laves.
Fra udtræk til fund
En brugbar dokumentation har fire felter pr. underkategori: baselinens krav, den effektive indstilling fra auditpol, hvilke maskiner der afviger, og hvilken gruppepolitik der styrer indstillingen. Det sidste felt gør rettelsen let at finde. Gem CSV-filen med dato og maskinnavn, så samme udtræk kan tages igen efter rettelsen.
Hvad det kræver, og hvad det koster at lade være
Kontrollen kræver en konto med de nævnte rettigheder og en baseline at sammenligne med. At hæve revisionsniveauet giver flere hændelser, og loggens størrelse skal derfor ses efter samtidig, så de ældste hændelser ikke overskrives hurtigere end før.
Uden kontrollen kan I have en central opsamling og alarmregler, der ser fine ud, men som aldrig får de hændelser, de er bygget til. Fejlen viser sig først, når en undersøgelse står uden spor.
Det skal I lade være med
- At gå ud fra, at Windows’ standard dækker det nødvendige · flere centrale underkategorier står til ingen revision.
- At læse gruppepolitikken i stedet for den effektive indstilling · arv og lokale ændringer kan give et andet resultat.
- At hæve revisionen uden at se på loggens størrelse · flere hændelser fylder loggen hurtigere.
Det skal gennemgangen kunne vise
- ☐ Udtræk fra auditpol /get /category:* /r fra domænecontrollere og en stikprøve af servere med dato.
- ☐ En baseline med beslutning pr. underkategori.
- ☐ En liste over afvigelser med den gruppepolitik, der styrer indstillingen.
- ☐ Status for scriptlogning i den PowerShell-version, der bruges.
Kilder
- Microsoft, System Audit Policy recommendations, læst 13. november 2026.
- Microsoft, auditpol get, læst 13. november 2026.
- Microsoft, about_Logging_Windows, PowerShell 7.6, læst 13. november 2026.
- SAMSIK, Logning, en del af et godt cyberforsvar, 3. udgave januar 2023, s. 4 og 7, læst 13. november 2026.
- Gennemførelsesforordning (EU) 2024/2690, dansk tekst, bilagets punkt 3.2.3, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Kør auditpol /get /category:* /r på én domænecontroller, og sammenlign de fem underkategorier ovenfor med jeres baseline.
Læs også: Alarmer: findes reglerne, og reagerer nogen? · Den effektive indstilling og den tiltænkte
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
