Windows-Überwachungsrichtlinie mit auditpol: Subkategorien auslesen, durchsetzen und das Security-Log dimensionieren

Ziel

Die aktuell wirksame erweiterte Überwachungsrichtlinie auf einem Windows-Server-Host auslesen, verstehen, warum ihre Konfiguration unbemerkt wirkungslos bleiben kann, und das Security-Log so dimensionieren, dass überwachte Ereignisse nicht verloren gehen.

Voraussetzungen

Eine Sitzung mit erhöhten Administratorrechten; auditpol.exe (ab Windows Server 2016 fester Bestandteil von Windows). Auf nicht englischen Installationen sind die Namen der Subkategorien lokalisiert; die GUIDs aus auditpol /list /subcategory:* /v funktionieren in jeder Sprache.

Schritte

1. Die vollständige wirksame Richtlinie ausgeben: auditpol /get /category:*. Der Unterbefehl /get von auditpol "displays the current audit policy" (zeigt die aktuelle Überwachungsrichtlinie an), und /category:* fragt alle Kategorien statt nur einer ab.
2. Einen einzelnen Bereich betrachten, z. B. die Anmeldung: auditpol /get /subcategory:"Logon". Die Referenz zu /get dokumentiert /category und /subcategory als alternative Möglichkeiten, die Abfrage einzugrenzen.
3. Prüfen, welche Ebene Vorrang hat. Die Sicherheitsoption "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" (Registrywert SCENoApplyLegacyAuditPolicy unter HKLM\SYSTEM\CurrentControlSet\Control\Lsa, 1 = aktiviert) bewirkt, dass die Subkategorie-Einstellungen Vorrang haben; Microsoft nennt als wirksamen Standardwert «Aktiviert» für eigenständige Server, Mitgliedsserver und Domänencontroller. Wurde die Option per GPO deaktiviert, gilt die Überwachungsrichtlinie auf Kategorieebene (einfache Richtlinie) aus der Gruppenrichtlinie oder der lokalen Sicherheitsrichtlinie vorrangig vor den Subkategorie-Einstellungen, und eine mit auditpol /set gesetzte Subkategorie kann überschrieben werden. Für denselben Host nicht sowohl einfache als auch erweiterte Überwachungsrichtlinie konfigurieren.
4. Eine Subkategorie setzen: auditpol /set /subcategory:"Logon" /success:enable /failure:enable.
5. Prüfen, ob die Änderung wirksam ist: auditpol /get /subcategory:"Logon" erneut ausführen und kurz danach auf einen echten erfolgreichen bzw. fehlgeschlagenen Anmeldevorgang prüfen.
6. Das Security-Log so dimensionieren, dass eine Häufung überwachter Ereignisse die Historie nicht überschreibt, bevor sie gesammelt wurde: Limit-EventLog -LogName Security -MaximumSize 200MB -OverflowAction OverwriteAsNeeded in Windows PowerShell 5.1. Das Cmdlet ist dokumentiert als Mittel, um "the maximum size of a classic event log" festzulegen (der Wert muss durch 64 KB teilbar sein). Die EventLog-Cmdlets fehlen in PowerShell 7; dort leistet wevtutil sl Security /ms:209715200 dasselbe. OverwriteAsNeeded verwirft bei vollem Log weiterhin die ältesten Ereignisse; wenn die Historie wichtig ist, sind Ereignisse daher an einen Collector weiterzuleiten.

Erwartetes Ergebnis

Die Ausgabe von auditpol /get /category:* entspricht der vorgenommenen Konfiguration, die Subkategorie-Einstellungen werden beachtet (bestätigt durch das Erzeugen eines echten passenden Ereignisses), und die Grösse des Security-Logs ist ausdrücklich festgelegt, statt auf dem Installationsstandard zu bleiben.

Grenzen und Prüfbasis

Auf einem domänenverbundenen Host haben aus Gruppenrichtlinien stammende Überwachungseinstellungen normalerweise Vorrang vor einem lokalen auditpol /set und werden bei der nächsten Richtlinienaktualisierung erneut angewendet. Bleibt eine lokale Änderung nicht bestehen, ist daher die GPO zu prüfen. Um die aktuelle Richtlinie vor einer Änderung zu sichern, dient auditpol /backup /file:auditpolicy-before.csv; wiederhergestellt wird sie mit auditpol /restore /file:auditpolicy-before.csv. Keiner dieser Schritte erfordert einen Neustart.