Active-Directory-Kontosperrungen

Benutzer melden sich mit dem richtigen Kennwort an – und trotzdem wird ihr Active-Directory-Konto immer wieder gesperrt? Solche Fälle sind im Alltag oft mühsam: Das Konto wird entsperrt, der Anwender arbeitet kurz weiter, und wenig später ist die nächste Sperrung da.

Zwei Gründe haben uns motiviert, diesen Artikel zu schreiben: In einem vergangenen Artikel ging es um Bruteforce-Angriffe auf das Sophos VPN-Portal. Firewalls mit LDAP-Zugriff auf das AD haben oft zur Folge, dass AD-Konten mit Falschanmeldungen von außen gesperrt werden können. Zusätzlich treiben uns Kennwortwechsel manchmal zur Weißglut...

Die gute Nachricht: In vielen Fällen lässt sich relativ sauber nachvollziehen, von welchem System und mit etwas Geduld sogar von welchem Prozess oder Dienst die fehlerhaften Anmeldeversuche ausgehen.

Typisches Muster: Kennwort wurde geändert, irgendwo lebt das alte noch weiter

Besonders häufig tritt das Problem nach einer Kennwortänderung auf. Das neue Kennwort funktioniert interaktiv bereits, aber im Hintergrund versucht noch irgendwo ein alter Eintrag, sich mit dem bisherigen Kennwort zu authentifizieren. Typische Kandidaten sind gespeicherte Kennwörter in Diensten, geplanten Aufgaben, Netzlaufwerken, Anmeldeinformationsverwaltung, mobilen Geräten oder getrennten RDP-Sitzungen. Genau diese Spuren sollte man systematisch prüfen.

Zuerst prüfen: Ist das Konto wirklich gesperrt?

Bevor die eigentliche Suche beginnt, sollte der Status des Benutzerkontos geprüft werden. Das geht grafisch in „Active Directory-Benutzer und -Computer“ oder per PowerShell. Auch die Suche nach allen aktuell gesperrten Konten ist mit Bordmitteln möglich. In PowerShell sind vor allem Get-ADUser mit der Eigenschaft LockedOut sowie Search-ADAccount -UsersOnly -LockedOut hilfreich. 

Alle gesperrten Benutzer anzeigen:

Search-ADAccount -UsersOnly -LockedOut

Ein gesperrtes Konto kann bei Bedarf direkt wieder entsperrt werden:

Get-ADUser -Identity BENUTZERNAME | Unlock-ADAccount

Kontosperrungsrichtlinie im Blick behalten

Wie schnell ein Konto gesperrt wird, hängt von der Kontosperrungsrichtlinie der Domäne ab. Relevant sind vor allem drei Werte: die Anzahl zulässiger Fehlversuche, die Dauer der Sperrung und der Zeitraum, nach dem der Fehlversuchszähler zurückgesetzt wird. Diese Einstellungen finden sich typischerweise in der Domänenrichtlinie unter den Kontorichtlinien.

Für die Ursachenanalyse ist das wichtig: Je niedriger der Schwellenwert eingestellt ist, desto schneller führen veraltete gespeicherte Kennwörter zu wiederkehrenden Sperren.

Logging auf dem AD-Server per GPO aktivieren

Bevor sich fehlgeschlagene Anmeldungen sauber auswerten lassen, sollte geprüft werden, ob die nötigen Überwachungsrichtlinien auf den Domain Controllern überhaupt aktiv sind. Gerade in kleineren Umgebungen fehlt diese Konfiguration oft oder es werden nur die alten, groben „Basis-Auditrichtlinien“ verwendet. Für die Fehlersuche rund um Kontosperrungen ist es sinnvoller, gezielt mit den erweiterten Auditrichtlinien zu arbeiten. Microsoft stellt diese Einstellungen in der Advanced Audit Policy Configuration bereit.

Welche GPO sollte verwendet werden?

Am saubersten ist meist eine eigene GPO für Domain Controller, die auf die OU Domain Controllers verknüpft wird. So lässt sich das Auditing gezielt für DCs steuern, ohne andere Server unnötig mit zusätzlichen Security-Events zu belasten. 

Folgende Einstellungen müssen daran vorgenommen werden: Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Erweiterte Überwachungsrichtlinienkonfiguration > Überwachungsrichtlinien > Anmelden/Abmelden

Dort sind die Richtlinien mit Erfolg und Fehler zu konfigurieren.

• Kontosperrung überwachen
• Abmelden überwachen
• Anmelden überwachen
• Spezielle Anmeldung überwachen

Weitere Einstellungen sind unter folgendem Ordner zu setzen: Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Erweiterte Überwachungsrichtlinienkonfiguration > Überwachungsrichtlinien > Kontenverwaltung

Dort sind die Richtlinien mit Erfolg und Fehler zu konfigurieren.

• Benutzerkontenverwaltung überwachen

Diese Audit-Subkategorien sind für die Analyse besonders hilfreich

Für die Suche nach der Ursache von Kontosperrungen und fehlerhaften Anmeldungen sind vor allem diese Subkategorien relevant:

Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Erweiterte Überwachungsrichtlinienkonfiguration > Überwachungsrichtlinien > Kontoanmeldung

Dort sind die Richtlinien mit "Erfolg und Fehler" zu konfigurieren.

• Kerberos Authentifizierungsdienst überwachen
• Ticketvorgänge des Kerberos-Diensts überwachen

Diese Richtlinien steuern unter anderem Ereignisse rund um Kennwortprüfung und Kerberos-Ticketanforderungen auf Domain Controllern. Genau daraus stammen später wichtige Events wie Kerberos-Fehler und weitere Hinweise auf die Quelle der fehlerhaften Anmeldung. Microsoft beschreibt diese Subkategorien explizit als Teil der erweiterten Audit-Konfiguration für die Kontodatenbank auf DCs. 

Erfolg, Fehler oder beides?

Für die meisten der oben genannten Richtlinien ist es sinnvoll, mindestens Fehler zu aktivieren. Bei der Ursachenanalyse hilft häufig auch Erfolg, weil sich damit Zusammenhänge besser erkennen lassen. Microsoft dokumentiert bei den erweiterten Audit-Richtlinien, dass sich die Einstellungen gezielt pro Subkategorie für Erfolg und Fehler setzen lassen.

In produktiven Umgebungen gilt aber wie immer: Je mehr Auditing aktiviert wird, desto stärker wachsen die Security-Logs. Deshalb sollte man die Einstellungen bewusst wählen und nicht pauschal „alles“ einschalten. Microsoft weist bei mehreren dieser Kategorien ausdrücklich auf teils hohe Event-Mengen hin, etwa bei Kerberos- oder Prozessereignissen. 

GPO anwenden und prüfen

Nach der Änderung der GPO sollte die Richtlinie auf dem Domain Controller aktualisiert werden, zum Beispiel mit:

gpupdate /force

Anschließend lässt sich per

auditpol /get /category:*

prüfen, welche Auditkategorien und Subkategorien tatsächlich aktiv sind. Microsoft nennt auditpol selbst als geeignetes Mittel, um die wirksame Konfiguration zu kontrollieren. Danach sollte man im Sicherheitsprotokoll des Domain Controllers prüfen, ob die erwarteten Events tatsächlich geschrieben werden.

Wie wird nun weiter analysiert?

In realen Kundenumgebungen gehen wir meist in dieser Reihenfolge vor:

1. Benutzerkonto prüfen und entsperren

2. 4740 auf dem PDC auswerten

3. Rechnername oder IP der Quelle identifizieren

4. Auf dem Quellsystem geplante Aufgaben, Dienste, Credential Manager, Outlook-/Mail-Profile, Mobilgeräte und RDP-Sitzungen prüfen

Der wichtigste erste Schritt: Event ID 4740 auf dem PDC prüfen

Sobald ein Benutzerkonto gesperrt wird, ist Event ID 4740 der zentrale Startpunkt. Microsoft beschreibt dieses Ereignis als „A user account was locked out“. In AD-Umgebungen ist es besonders hilfreich, dieses Ereignis auf dem PDC-Emulator auszuwerten, weil dort Sperrungen zentral verarbeitet werden und sich die Quelle häufig am schnellsten eingrenzen lässt. Im Ereignis ist insbesondere das Feld Caller Computer Name interessant.

Den PDC-Emulator der Domäne können Sie mit folgendem Powershell-Befehl ermitteln:

(Get-ADDomain).PDCEmulator

Im Sicherheitsprotokoll des PDC filtern Sie dann nach 4740. Findet sich dort das betroffene Benutzerkonto, ist der im Ereignis genannte Rechnername oft bereits der erste verwertbare Hinweis.

Wenn nur der Rechnername nicht reicht: 4771 und 4625 auswerten

Nicht immer ist der „Caller Computer Name“ sofort eindeutig. Gerade bei Fremdsystemen, Nicht-Windows-Geräten oder Altanwendungen hilft der Blick auf weitere Security-Events.

Event ID 4771: Kerberos-Fehler mit Client-Hinweis

4771 steht für eine fehlgeschlagene Kerberos-Vorauthentifizierung. Microsoft dokumentiert, dass dieses Ereignis auf Domain Controllern erzeugt wird, wenn der KDC kein Ticket ausstellen kann. In solchen Fällen lassen sich häufig Benutzername und Client-Adresse korrelieren. Das ist besonders hilfreich, wenn Kerberos im Spiel ist und ein DNS-Name allein nicht weiterhilft.

Event ID 4625: Fehlgeschlagene Anmeldung mit Zusatzdetails

4625 ist das klassische Ereignis für fehlgeschlagene Anmeldungen. Microsoft weist darauf hin, dass dieses Event erzeugt wird, wenn ein Anmeldeversuch scheitert. Je nach Fall liefern Felder wie Workstation Name, Source Network Address, Logon Type und teils auch Process Name zusätzliche Hinweise darauf, woher die Fehlversuche kommen und ob sie z. B. von einem Dienst, einer Netzwerkanmeldung oder einer Anwendung ausgelöst wurden.

Gerade bei NTLM-basierten Fällen kann 4625 sehr aufschlussreich sein.

PowerShell: Sperrquelle schnell aus dem PDC auslesen

Wer nicht jedes Mal manuell im Event Viewer suchen möchte, kann die Sperrquelle auch per PowerShell aus dem Security-Log des PDC ziehen. Der Ansatz: 4740 filtern und die relevanten Eigenschaften ausgeben. Das Prinzip wird in der Vorlage sauber beschrieben und lässt sich gut in eigene Admin-Workflows übernehmen. 

Beispiel:

$Usr = "gesperrterbenutzer"
$Pdc = (Get-ADDomain).PDCEmulator

$Params = @{
    ComputerName = $Pdc
    LogName      = "Security"
    FilterXPath  = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Usr']]"
}

Get-WinEvent @Params | ForEach-Object {
    [PSCustomObject]@{
        Zeit   = $_.TimeCreated
        Quelle = $_.Properties[1].Value
        DC     = $_.MachineName
    }
}

Damit erhält man schnell eine erste Liste, von welchem System die Sperrung ausgelöst wurde.

Auf dem verdächtigen Rechner weitersuchen

Hat man den betroffenen Client oder Server identifiziert, beginnt die zweite Phase der Analyse: Welcher Prozess verwendet noch das alte Kennwort?

In der Praxis sollte man insbesondere folgende Stellen prüfen:

• geplante Aufgaben

• Windows-Dienste mit Domänenkonto

• gespeicherte Anmeldeinformationen

• verbundene Netzlaufwerke

• Mobilgeräte mit Mailprofilen

• getrennte oder schlafende RDP-Sitzungen

• Anwendungen mit hinterlegten Zugangsdaten

• Autologon- oder RunAs-Konfigurationen

Gerade nach Kennwortänderungen sind dies die häufigsten Ursachen.

Lokales Auditing auf dem betroffenen System aktivieren

Wenn der Rechner als Quelle feststeht, aber der eigentliche Verursacher noch unklar ist, kann man auf diesem System gezielt zusätzliches Auditing von Anmeldeereignissen und Prozessverfolgung aktivieren. Danach wartet man auf die nächste Sperrung und sucht lokal wieder nach 4625. In günstigen Fällen taucht dann direkt ein Prozessname auf, der den Schuldigen verrät. 

Wichtig ist dabei: Diese erweiterten Audits sollten nur gezielt und möglichst zeitlich begrenzt aktiviert werden, weil sie zusätzliche Logmengen erzeugen.

Besonders interessant ist der Anmeldetyp. Die Logon Types werden von Microsoft entsprechend unterschieden.

Fazit

Wiederkehrende AD-Kontosperrungen wirken oft wie ein Rätsel, folgen aber meist einem recht klaren Muster: Irgendwo ist noch ein veraltetes Kennwort hinterlegt. Wer zuerst auf dem PDC nach 4740 sucht, dann 4771 und 4625 zur Korrelation nutzt und anschließend den verdächtigen Client gezielt untersucht, kommt in vielen Fällen schnell ans Ziel.