AD Account Lockout Troubleshooting

In den meisten Organisationen existieren Richtlinien zur Kontosperrung. Diese Richtlinie ist eine Sicherheitsmaßnahme, um zu verhindern, dass Unbefugte versuchen, das Kennwort fortlaufend zu erraten oder ein Kennwort per Brute-Force Attacke zu hacken. Kontosperrungsrichtlinien sind in Active Directory weit verbreitet und bestehen aus einem einfachen Ansatz zur Bekämpfung eines größeren Sicherheitsproblems. Wird mehrfach ein falsches Kennwort verwendet, wird das entsprechende Konto gesperrt, entweder temporär oder dauerhaft (bis zur Entsperrung durch einen Administrator).

Leider kommt es insbesondere nach Kennwortänderungen vor, dass ein Konto plötzlich und ohne erkennbaren Grund dauernd gesperrt wird. Wird das Konto entsperrt, ist es kurz darauf wieder gesperrt. Irgendwo, irgendwie gibt es eine Person, ein Skript oder einen Prozess, der immer wieder dasselbe falsche Passwort verwendet, aber niemand weiß, wo die Quelle der Eingabe ist.

Wie kann es zu Lockouts kommen?

In AD Umgebungen ab Windows Server 2008 erfolgt die Verifizierung der Benutzerdaten zwischen dem Client-System, dem Domänencontroller des Client-Systems und dem Domänencontroller, der die PDC Emulator Rolle (PDC) hält.

Bei jedem Versuch, ein Benutzerkonto zu authentifizieren, werden die Anmeldeinformationen an den entsprechenden Domänencontroller für das Subnetz des Client-Systems gesendet. Ist das Kennwort falsch, leitet der Domänencontroller des Client-Systems die Anforderung an den Domänencontroller mit PDC Emulator Rolle weiter. Grund hierfür ist, dass der Domänencontroller des Client-Systems möglicherweise nicht das aktuellste Kennwort kennt, während der Domänencontroller mit der PDC Emulator Rolle per Design immer über das aktuellste Kennwort verfügt. Der PDC-Emulator versucht erneut, das Kennwort zu verifizieren. Wenn sich weiterhin herausstellt, dass es falsch ist, erhöht der PDC-Emulator das Attribut badPwdCount für das Benutzerkonto. Auf dem PDC-Emulator wird ein Event ID 4740 mit der IP-Adresse des Client-Systems, die die ursprüngliche Anforderung initiiert hat, und mit dem Benutzerkonto generiert. Der PDC-Emulator informiert dann den Domänencontroller des Client-Systems, dass das Kennwort tatsächlich falsch ist. Der Domänencontroller des Client-Systems benachrichtigt weiterhin das Client-System, dass das Kennwort falsch war.

Der Domain Controller mit der PDC Emulator Rolle ist daher der beste Ort, um die Quelle des Lockouts zu ermitteln. Jede Kontosperrung wird dort im Sicherheitsereignisprotokoll aufgezeichnet. Dementsprechend wird das Security Event Log des PDC Emulators per PowerShell abgefragt, um zu ermitteln, von welchem Client aus die Lockouts generiert werden.

# Locked Out User definieren
$User = '<sAMAccountName>'

# Domain Controller mit PDC Emulator Rolle ermitteln
$PDC = (Get-AdDomain).PDCEmulator

# Parameterliste für die Event-Abfrage erstellen
$GweParams = @{
     'Computername' = $PDC
     'LogName' = 'Security'
     'FilterXPath' = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$User']]"
}

# Security Event Log abfragen
$Events = Get-WinEvent @GweParams

Die o.g. Befehle geben uns jetzt das Lockout Event aus:

ProviderName: Microsoft-Windows-Security-Auditing

Time created                Id LevelDisplayName Message
------------                -- ---------------- -------
4/19/2019 9:25:09 AM      4740 Information      A user account was locked out....

Aus der Ausgabe lässt sich leider noch nicht der Client herauslesen, von dem aus der Lockout Event generiert wurde. Dazu müssen die einzelnen Properties des Events angezeigt werden.

So ist der Username das erste Property (Property[0]), der Clientname hingegen ist das zweite Property (Property[1]).

Username:

$Events[0].Properties[0].Value

Client:

$Events[0].Properties[1].Value

Um nun den „Schuldigen“ zu finden, lässt sich das entsprechende Client-Property in einen Loop setzen, um alle entsprechenden Events danach zu durchforsten:

$Events | ForEach {$_.Properties[1].Value}

Quellen:
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4740

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.