Gibt ein Benutzer sein Kennwort öfter falsch ein, als es in der Kontosperrungsrichtlinie oder in einem PSO (Password Setting Objects, ab Windows Server 2008) konfiguriert ist, wird sein Benutzerkonto gesperrt. Einige Administratoren verwechseln das mit einem deaktivierten Benutzerkonto. Das Deaktivieren eines Benutzerkontos ist jedoch ein administrativer Vorgang, der manuell mit entsprechenden administrativen Rechten durchgeführt werden muss.
Das Attribut, in dem der Zeitpunkt der Kontosperrung gespeichert ist, lautet lockoutTime.
Das Attribut lockoutTime kann dabei folgende Werte enthalten:
- Bei einem Benutzerkonto, das noch nie gesperrt wurde, der Benutzer sich also bisher immer erfolgreich an der Domäne authentisieren konnte, enthält das Attribut lockoutTime als Wert <Nicht festgelegt>. Wie oft der Benutzer ein falsches Kennwort eingeben darf bis sein Benutzerkonto gesperrt wird, kann von der Kontosperrungsrichtlinie, bzw. ab Windows Server 2008 durch ein PSO, vorgegeben werden.
- Hat ein Benutzer sein Kennwort häufiger falsch eingegeben, als es in der Kontosperrungsrichtlinie oder in einem PSO definiert ist, wird sein Benutzerkonto gesperrt. Dabei wird in lockoutTime ein Large Integer Wert eingetragen, der den Zeitpunkt der Kontosperrung darstellt.
- Wenn ein Benutzerkonto nach den Vorgaben der Kontosperrungsrichtlinie oder durch ein PSO automatisch wieder entsperrt wurde, bleibt in lockoutTime vorerst weiterhin der Zeitpunkt der Kontosperrung als ein Large Integer Wert gespeichert. Das Attribut lockoutTime enthält dann zwar weiterhin einen Zeitwert, aber der Haken Konto ist gesperrt in den Eigenschaften des Benutzerkontos ist nicht mehr gesetzt.
- Wenn sich jedoch der Benutzer nach der Kontosperrdauer an der Domäne erfolgreich authentisiert, wird lockoutTime genullt. Als Wert wird in lockoutTime „0“ gespeichert. Auch wenn ein gesperrtes Benutzerkonto vom Administrator entsperrt wurde, erhält das Attribut lockoutTime in den Eigenschaften des entsprechenden Benutzerkontos den Wert 0.
Der LDAP-Filter, mit dem man die gesperrten Benutzerkonten beispielsweise mit einer benutzerdefinierten gespeicherten Abfrage in der MMC Active Directory-Benutzer und -Computer ermitteln kann, lautet:
(&(sAMAccountType=805306368)(lockoutTime>=1))
Wenn jedoch in der Kontosperrungsrichtlinie oder in dem zugewiesenen PSO definiert ist, dass ein Benutzer nach einer bestimmten Zeit automatisch entsperrt wird, greift diese Abfrage nach den tatsächlich gesperrten Benutzerkonten nicht! Denn nach der automatischen Entsperrung des Benutzerkontos bleibt der Zeitpunkt der Kontosperrung in lockoutTime, noch bevor sich der Benutzer erfolgreich an der Domäne authentisiert, gespeichert. Dadurch werden mit dem genannten LDAP-Filter auch die mittlerweile automatisch entsperrten Benutzerkonten angezeigt.
Insbesondere, wenn man Besuch vom Conficker Wurm hat, der alle Benutzer im AD sperrt, möchte man zügig die echten gesperrten Benutzer finden und idealerweise alle gleichzeitig entsperren.
Mit dem oben genannten LDAP-Filter funktioniert die Suche nach den tatsächlich gesperrten Benutzerkonten nur, wenn ein möglichst aktueller Zeitwert verwendet wird. Wenn beispielsweise der Conficker Wurm am 10.10.2010 um 08:05 Uhr alle Benutzerkonten im AD sperrt, könnte man als Zeitangabe den 10.10.2010 – 08:00 Uhr verwenden. Der umgerechnete Large Integer Wert lautet 129311640045030000 und demnach würde der LDAP-Filter wie folgt aussehen:
(&(sAMAccountType=805306368)(lockoutTime>=129311640045030000))
Aber die Suche nach den tatsächlich gesperrten und vor allem das Entsperren dieser Benutzerkonten, lässt sich ganz einfach realisieren. Die Lösung ist wieder einmal die AD-PowerShell! Mit diesem State of the Art Werkzeug lässt sich das schnell und einfach mit einem Einzeiler erledigen.
Mit diesem Befehl werden alle tatsächlich gesperrten Benutzer angezeigt:
Search-ADAccount –LockedOut | FT Name
Mit dem folgenden Befehl werden alle tatsächlich gesperrten Benutzer entsperrt:
Search-ADAccount -LockedOut | Unlock-ADAccount
Danach bleibt, bis zur erfolgreichen Authentisierung des entsprechenden Benutzers an der Domäne, der Zeitpunkt der Kontosperrung weiterhin in lockoutTime gespeichert, aber die Benutzerkonten sind entsperrt!
Wer noch eine Windows Server 2003 bzw. Windows Server 2008 Umgebung betreibt und unter anderem von der AD-PowerShell noch nicht sofort profitieren kann, der kann die „AD Management Gateway Services“ installieren und kommt somit ebenfalls in den Genuß der AD-PowerShell.
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Weitere Informationen:
Password Setting Objects erstellen und verwalten
Einen Large Integer Wert umrechnen
AD-PowerShell Befehle
Gespeicherte Abfragen
Gespeicherte Abfragen für dsa.msc
Objektdelegierungen einrichten
Der Objektdelegierungsassistent
Comments are closed, but trackbacks and pingbacks are open.