Wie können Sie ein gesperrtes Active Directory-Konto verfolgen und auflösen? Finden Sie heraus, was passiert, wie Sie bestimmte Ereignisse finden und wie Sie Ereignisse analysieren können.
Active Directory (AD) ist ein wunderbarer Dienst. Sie können sich von überall im Netzwerk mit demselben Benutzernamen und Kennwort anmelden. Das heißt, bis Sie vergessen, eine Remote-Desktop-Sitzung zu schließen, oder sich ein Wurm im Netzwerk ausbreitet, oder Sie vergessen, dass Sie eine geplante Aufgabe als Ihr Benutzerkonto ausführen, oder… Nun, Sie wissen, worum es geht. AD ist ein äußerst nützliches Produkt; deshalb ist seine Akzeptanzrate so hoch. Das Problem ist, wenn ein Konto anfängt, sich grundlos zu sperren. Das denken Sie zumindest.
AD-Richtlinien zur Kontosperrung
Viele Organisationen haben (oder sollten) Richtlinien zur Kontosperrung. Diese Richtlinie ist eine Sicherheitsmaßnahme, um zu verhindern, dass Unbefugte versuchen, das Kennwort ständig zu erraten oder ein Kennwort mit Gewalt zu erzwingen. Kontosperrungsrichtlinien sind in Active Directory weit verbreitet und bestehen aus einem einfachen Ansatz zur Bekämpfung eines großen Sicherheitsproblems. Versuchen Sie das falsche Kennwort eine bestimmte Anzahl von Malen, und das Konto ist unbrauchbar, bis ein Administrator es manuell wieder freigibt. Die Absicht ist richtig, aber in manchen Fällen ist die Umsetzung nicht so einfach.
In manchen Situationen, insbesondere wenn ein Kennwort geändert wird, kann ein Konto plötzlich und ohne ersichtlichen Grund gesperrt werden. Ein Benutzer ruft den Helpdesk an, der Helpdesk schaltet das Konto wieder frei, und wenig später ist das Konto wieder gesperrt. Das ist sowohl für den Benutzer als auch für den Helpdesk eine frustrierende Erfahrung. Manchmal wird das Problem noch dadurch verschlimmert, dass der Ursprung der Sperrungen unbekannt ist. Irgendwo, irgendwie gibt es eine Person, ein Skript oder einen Prozess, der immer wieder dasselbe falsche Kennwort ausprobiert, aber niemand weiß, wo.
Wie kann man also diese lästigen Sperren aufspüren? Eine Möglichkeit ist die Verwendung eines PowerShell-Skripts. Aber zuerst wollen wir uns ansehen, was passiert, wenn ein Konto gesperrt wird.
Auflösen eines gesperrten AD-Kontos
In einer Windows Server 2008- oder neueren Umgebung gibt es ein kurzes Hin und Her zwischen dem Client-System, dem Domänencontroller des Client-Systems und dem Domänencontroller, der die Emulatorrolle des primären Domänencontrollers (PDC) innehat. Dies geschieht wie folgt:
- Wenn eine Benutzerkontoauthentifizierung versucht wird, werden die Anmeldeinformationen an den entsprechenden Domänencontroller für das Subnetz des Clientsystems gesendet.
- Wenn das Kennwort falsch ist, leitet der Domänencontroller des Client-Systems die Anforderung an den Domänencontroller mit der PDC-Emulatorrolle weiter. Dies liegt daran, dass der Domänencontroller des Client-Systems möglicherweise nicht über das aktuellste Kennwort verfügt, während der Domänencontroller, der die PDC-Emulatorrolle innehat, immer über das aktuellste Kennwort verfügt, was ein Designmerkmal von Active Directory ist.
- Der PDC-Emulator versucht das Kennwort erneut, und wenn es immer noch falsch ist, erhöht der PDC-Emulator das badPwdCount-Attribut für das Benutzerkonto.
- Eine Ereignis-ID 4740 wird auf dem PDC-Emulator mit der IP-Adresse des Client-Systems, das 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 dann das Client-System, dass das Kennwort falsch war.
Wo kann man die Quelle am besten finden? Die Antwort lautet: im PDC-Emulator. Der Grund dafür ist, dass dort jede Kontosperrung im Sicherheitsereignisprotokoll aufgezeichnet wird. Der PDC-Emulator ist ein zentraler Ort, der für alle Kontosperrungsereignisse abgefragt werden kann.
Verwenden von PowerShell zum Aufspüren der Quelle von AD-Kontosperrungen
Um den PDC-Emulator abzufragen, verwenden wir das Cmdlet „Get-WinEvent“ von PowerShell. Dies ist ein äußerst nützliches Cmdlet zum schnellen Durchsuchen eines oder mehrerer Ereignisprotokolle auf einem Server. Wir suchen nach einer Ereignis-ID von 4740. Zunächst müssen wir den Domänencontroller finden, der die PDC-Emulatorrolle innehat. Eine Möglichkeit, dies zu tun, ist die Verwendung des Cmdlets Get-AdDomain.
Wenn wir den PDC-Emulator kennen, müssen wir nur noch sein Sicherheitsereignisprotokoll nach der Ereignis-ID 4740 abfragen.
Ich habe ein Konto namens abertram, das gesperrt ist. Schauen wir uns an, wie wir den Übeltäter ausfindig machen können.
Wir haben jetzt den PDC-Emulator, also lassen Sie uns sein Sicherheitsprotokoll mit einem PowerShell-Skript abfragen.
## Definieren Sie den Benutzernamen, der ausgesperrt ist
$Username = ‚abertram‘
## Finden Sie die Domänencontroller-PDCe-Rolle
$Pdce = (Get-AdDomain).PDCEmulator
## Erstellen Sie die Parameter, die an Get-WinEvent übergeben werden
$GweParams = @{
‚Computername‘ = $Pdce
‚LogName‘ = ‚Security‘
‚FilterXPath‘ = „* und EventData=’$Username‘]]“
}
## Abfragen des Sicherheitsereignisprotokolls
$Events = Get-WinEvent @GweParams
So erhalten wir das Sperrereignis.
Aber wir haben noch nicht das auslösende Client-System. Um das herauszufinden, müssen wir ein wenig tiefer graben. Der tatsächliche Benutzername ist in den Eigenschaften eines jeden Ereignisses versteckt. Um den Benutzernamen in jedem Ereignis zu finden, können wir einfach diese Zeile verwenden.
$Events.Properties.Value
Damit finden wir den Benutzernamen im ersten Ereignis und in der ersten Instanz des Properties-Wertes. Glücklicherweise befindet sich das Client-System nur in der zweiten Instanz von Properties.
$Events.Properties.Value
Wenn man weiß, wo sich der Name des Client-Systems befindet, muss man ihn nur noch in eine Schleife einfügen, und schon haben wir den Übeltäter gefunden.
Jetzt sind Sie gewappnet und können loslegen, wenn der Helpdesk Sie das nächste Mal anruft, weil das AD-Benutzerkonto immer wieder gesperrt wird.