Highlights
- Lernen Sie die sieben Windows-Event-IDs kennen, die für AD-Logon-Audits zählen, und warum echte Logoffs nur auf Workstations entstehen.
- Bauen Sie ein parallelisiertes PowerShell-Skript, das die Logon-Historie in Sekunden von jedem Domain Controller abruft.
- Planen Sie die Log-Aufbewahrung mit einer Sizing-Formel, GPO-Einstellungen und Windows Event Forwarding in ein SIEM.
- Vergleichen Sie native Audits, Drittanbieter-Auditoren und FIDO2-Prävention als drei Antworten auf eine Frage.
User-Logon und -Logoff im Active Directory verfolgen heißt: Group-Policy-Audit-Einstellungen, die richtigen Windows-Event-IDs (4624, 4625, 4634, 4647, 4768, 4769, 4776), PowerShell im großen Stil, Log-Forwarding ins SIEM und eine Retention-Strategie kombinieren, die SOX, HIPAA, PCI DSS 4.0, NIS2 und DORA gerecht wird. Domain Controller stellen Kerberos-Tickets aus, sehen aber das Session-Ende nie – Workstation-Event-Forwarding ist daher in jeder modernen hybriden Umgebung Pflicht.
Drei Tage. So weit zurück reichen die Sicherheits-Logs der meisten Domain Controller, bevor sie sich selbst überschreiben – und Administratoren stehen blind da, sobald ein Account-Lockout, ein Insider-Vorfall oder eine Untersuchung kompromittierter Credentials auf dem Tisch liegt. Native Active Directory-Audits wurden für statische Workstations und On-Premises-Domänen entworfen – nicht für RDS-Farms, VPN-Tunnel, hybride Identitäten und parallel laufende SaaS-Sessions. Dieser Leitfaden geht Schicht für Schicht durch – von Event 4624 auf dem Domain Controller bis zur phishing-resistenten FIDO2-Authentifizierung, die den Großteil passwortbezogener Geräusche bereits an der Quelle aus Ihrer Audit-Pipeline entfernt.
Native AD-Logon-Audits: GPO-Setup, Event-IDs und reale Grenzen
Logon/Logoff-Audits über die Advanced Audit Policy Configuration aktivieren
Standardmäßige Audit-Logon-Einstellungen einer frischen Domäne sind für Forensik zu permissiv und für Compliance zu leise. Öffnen Sie die Default Domain Controllers Policy und gehen Sie zu Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Erweiterte Überwachungsrichtlinienkonfiguration > Anmelden/Abmelden. Aktivieren Sie Erfolg und Fehler bei Logon, Logoff, Account-Lockout und Special Logon. Kombinieren Sie das mit Kontoanmeldung > Kerberos-Authentifizierungsdienst überwachen und Anmeldeinformationsüberprüfung überwachen, um NTLM-Fallback-Versuche zu erfassen.
Event-ID-Referenz (4624, 4625, 4634, 4647, 4768, 4769, 4776) und warum Domain Controller keine echten Logoff-Events erfassen
| Event-ID | Bedeutung | Wo geloggt |
|---|---|---|
| 4624 | Erfolgreicher Logon | DC + Workstation |
| 4625 | Fehlgeschlagener Logon | DC + Workstation |
| 4634 / 4647 | Logoff / nutzerinitiierter Logoff | Nur Workstation |
| 4768 / 4769 | Kerberos-TGT / Service-Ticket | Domain Controller |
| 4776 | NTLM-Credential-Validierung | Domain Controller |
Domain Controller stellen Kerberos-Tickets aus, sehen aber das Session-Ende nie – echte Logoffs leben auf Endpoints, nicht auf dem DC. Microsoft Learns Referenz zu Event 4624 dokumentiert das vollständige Schema und die Logon-Type-Codes, die die Interpretation downstream verschieben.
PowerShell-Skripte zum Abruf der Logon-Historie über alle Domain Controller
Modernes Get-WinEvent + FilterHashtable-Skript mit Parallelverarbeitung
Get-EventLog ist seit PowerShell 5 deprecated und kollabiert in großen Forests. Nutzen Sie Get-WinEvent mit einer FilterHashtable und befragen Sie jeden Domain Controller parallel:
powershell
$DCs = (Get-ADDomainController -Filter *).HostName
$DCs | ForEach-Object -Parallel {
Get-WinEvent -ComputerName $_ -FilterHashtable @{
LogName='Security'; ID=4624,4625; StartTime=(Get-Date).AddDays(-7)
} | Select TimeCreated, MachineName, @{n='User';e={$_.Properties[5].Value}}
} -ThrottleLimit 10 | Export-Csv .\logons.csv -NoTypeInformation
Bauen Sie try/catch um jeden Remote-Aufruf, um nicht erreichbare DCs abzufangen, ohne den Lauf abzubrechen.
4624/4634-Paare korrelieren und RDS/VPN-Sessions verfolgen
Die echte Session-Dauer ergibt sich nur, indem jedes 4624 mit dem passenden 4634/4647 über die LogonID (Properties[7]) gepaart wird. Für RDS fragen Sie Microsoft-Windows-TerminalServices-LocalSessionManager/Operational (IDs 21, 23, 25) auf den Session-Hosts ab. Für VPN parsen Sie RRAS oder Ihre Konzentrator-Logs und joinen über Username plus Zeitstempel.
Logon-Logs zentralisieren und aufbewahren, ohne Daten zu verlieren
Standard-Caps für das Security-Log (oft 128 MB) erklären, warum Admins auf Spiceworks immer wieder berichten: „Die Logs reichen nur drei Tage zurück." Retention muss konstruiert, nicht angenommen werden.
Sizing-Formel und GPO-Einstellungen, damit Logs nicht überschrieben werden
Verwenden Sie diese Formel: Events/Nutzer/Tag × Nutzer × Retention-Tage × 1,5 KB = benötigte Log-Größe. Für 500 Nutzer mit ~80 Events/Tag über 90 Tage planen Sie ~5,4 GB pro DC. Konfigurieren Sie über Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Ereignisprotokoll: maximale Größe setzen, Log archivieren, wenn voll statt überschreiben wählen und den Disk-Druck auf den Domain Controllern überwachen.
Windows Event Forwarding (WEF) + SIEM/Splunk-Setup für hybride AD- und Entra-ID-Umgebungen
Stellen Sie einen WEF-Collector bereit, verteilen Sie eine GPO mit der Subscription-Manager-URL und filtern Sie die Event-IDs 4624/4625/4634/4647/4776 über XPath. Leiten Sie über einen Heavy Forwarder an Splunk weiter und importieren Sie zusätzlich die Entra ID-Sign-in-Logs über die Graph API, um hybride Identitäten in einer einzigen Ansicht zu korrelieren.
Von Detection zu Prevention: Wie FIDO2 und Passwordless Ihre Audit-Oberfläche schrumpfen lassen
Detection skaliert linear mit Passwort-Geräusch. Der Verizon 2025 DBIR verortet Credential-Missbrauch in 22 % aller Breaches – und gestohlene Credentials plus Phishing zusammen treiben über die Hälfte aller Vorfälle mit menschlicher Beteiligung. Entfernen Sie das Passwort, und dieser Vektor kollabiert an der Quelle: Brute-Force, Spraying und NTLM-Downgrade-Versuche verschwinden. Ihr SOC hört auf, 4625-Stürme zu triagieren, und beginnt, echte Anomalien zu jagen.
SIEM-Volumen vorher/nachher und MITRE ATT&CK-Pattern-Rezepte (T1078, T1110, T1558)
Auf einem Bestand mit 1.000 Nutzern können Sie davon ausgehen, dass 4625/4776-Events nach einem Hideez-FIDO2-Rollout um eine Größenordnung sinken. Hardware-gebundene Credentials neutralisieren T1110 (Brute-Force), T1558 (Kerberoasting) und die meisten T1078-Varianten (Valid Accounts), weil der private Schlüssel den Security-Key nie verlässt.
Compliance-Mapping: SOX, HIPAA, PCI DSS 4.0, NIS2 und DORA
PCI DSS 4.0 §8.4 und NIS2 Artikel 21 verlangen explizit phishing-resistente Authentifizierung. FIDO2 erfüllt beide und produziert dabei manipulationssichere Logon-Records, die Auditoren akzeptieren.
DORA Artikel 9 dehnt dieselbe Erwartung auf EU-Finanzunternehmen aus, und NIST SP 800-63B definiert das Assurance Level AAL3, auf das alle fünf Frameworks letztlich verweisen.
Entscheidungs-Framework: Native Audits vs. Drittanbieter-Auditor vs. Authentication-Layer-Lösung
Die Wahl zwischen nativen AD-Audits, einem dedizierten Auditor und einer Authentication-Layer-Kontrolle ist keine binäre Entscheidung. Jede Schicht beantwortet eine andere Frage: was ist passiert, was passiert gerade und was sollte überhaupt nie passieren.
Scoring-Matrix: Kosten, Hybrid-Coverage, Echtzeit-Alerting und Prevention vs. Detection
| Kriterium | Native AD | Drittanbieter-Auditor | Hideez (Auth-Layer) |
|---|---|---|---|
| Kosten | Kostenlos | 3–8 $/Nutzer/Jahr | Pro Key + Lizenz |
| Hybrid-Entra-ID-Coverage | Teilweise | Variabel | Vollständig |
| Echtzeit-Alerting | Nein | Ja | Entfällt (verhindert) |
| Ansatz | Detection | Detection | Prevention |
Wann ADAudit Plus, UserLock oder Netwrix ausreichen – und warum Hideez sie ergänzt
Wenn Ihre Priorität forensische Beweise und SOC-2-Reporting sind, deckt ein Drittanbieter-Auditor die Detection-Schicht gut ab. Hideez ersetzt sie nicht; es entfernt die Credential-basierten Events, mit deren Triage sie Zyklen verbringen, in einer geschichteten Architektur – sodass die Regeln des Auditors sich auf echte Anomalien konzentrieren können statt auf Passwort-Geräusche.
Hideez ersetzt die Credential-Angriffsfläche durch phishing-resistente FIDO2-Logins, die Auditoren akzeptieren und SOCs lieben. Demo buchen, um zu sehen, wie das in Ihre AD- oder hybride Entra-ID-Umgebung passt – oder Hideez-Partner werden, um Ihren Kunden denselben Vorteil zu bieten.
Häufig gestellte Fragen
Warum erfasst Active Directory keine echten Logoff-Events auf dem Domain Controller?
Das Kerberos-Ticket-Modell authentifiziert den Nutzer einmal, danach lebt die Session auf der Workstation. Der DC stellt ein TGT aus, weiß aber nicht, wann der Nutzer seine Session schließt. Logoff-Events (4634, 4647) werden lokal auf dem Endpoint geschrieben, nicht zentral. Um sie zu erfassen, leiten Sie Workstation-Logs über Windows Event Forwarding an einen Collector oder das SIEM weiter.
Wie bekomme ich die AD-User-Logon-Historie über alle Domain Controller per PowerShell?
Verwenden Sie Get-WinEvent -FilterHashtable gegen jeden DC, den Get-ADDomainController -Filter * zurückliefert, mit ForEach-Object -Parallel für Skalierung. Filtern Sie auf Logon-Event-ID 4624, exportieren Sie nach CSV und korrelieren Sie anschließend mit 4634, um die echte Session-Dauer zu berechnen.
Logon-Auditing vs. passwortlose Authentifizierung: was reduziert Credential-Risiken tatsächlich?
Auditing erkennt im Nachhinein. FIDO2-Hardware-Authentifizierung eliminiert die Angriffsfläche und neutralisiert Brute-Force, Phishing und Password-Spraying an der Wurzel.
