Account Lockout Policy Settings und der spezielle Einfluss des PDCs
Unter den Active Directory Administratoren ist Accont Lockout ein heißes Thema. Viel von der Brisanz entsteht aus den unterschiedlichen Zielen, die die Manager, AD Admins und Security Administratoren haben. In der Diskussion kommen die technischen Aspekte oft zu kurz und führen zu Missverständnissen.
Oft kommen Techniker aus einer Welt, wo die Eingabe eines falschen Kennworts einen Anmeldefehlversuch zur Folge hatte, der Unix oder IBM Host lässt grüßen. In einem verteilten Verzeichnissystem wie Active Directory es ist und den aktuell im Markt befindlichen Applikationen ist das jedoch nicht mehr so einfach zu rechnen.
Es gibt nämlich etliche Applikationen, welche bei einem Anmeldefehler etliche Wiederholungen machen, mit den gleichen falschen Informationen. Als Applikationen gelten hier auch die Synchronisations-Clients auf mobilen Geräten. Auch Microsoft-Applikationen haben sowas gemacht, zum Beispiel ältere Versionen von Outlook. Es gibt aktuell ein Szenario mit dem Kerberos-Client, wo der Kerberos-Client einen Retry macht, siehe diesen englischen Blog.
Das ist jedoch nur ein Aspekt für frühzeitige Aussperrungen und ich denke den meisten unserer Leser ist das Thema im Allgemeinen bekannt.
Wir sind neulich jedoch auf eine interessante Kombination von Events gestoßen, wo eine Aussperrung stattfindet, ohne dass man an die üblichen Limits stößt.
Ausschlaggebend für das Problem ist ein sehr niedriger Wert für die Fehlversuche (LockoutThreshold). Sehr strenge Security Officers nehmen da gerne einstellige Werte. Der zweite treibende Aspekt ist ein langes Beobachtungsintervall (ObservationWindow).
Wenn ein Domain Controller ein falsches Kennwort hat bei der lokalen Prüfung, leitet er die Anfrage standardmäßig an den Primary Domain Controller (PDC) weiter. Der macht die gleiche Prüfung, und sein Ergebnis ist dann maßgeblich.
Wenn beide DCs das falsche Kennwort feststellen, erhöhen sie den „BadPwdCount“ um eins und „BadPasswordTime“ wird auf die aktuelle Uhrzeit gestellt. Solange der „LockoutThreshold“ nicht überschritten wird, passiert nichts weiter, denn die beiden Attribute werden nicht repliziert.
Wenn „LockoutThreshold“ überschritten wird, sperren beide DCs das Konto und das wird dann repliziert (als Attribut „LockoutTime“).
Es gibt zwei Events, die den „BadPwdCount“ zurücksetzen auf 0:
Der Benutzer übergibt in einem Folgeversuch das korrekte Kennwort.
Das „ObservationWindow“ läuft ab.
Das Fenster für frühzeitige Aussperrungen entsteht nun durch den Fall 1. „BadPwdCount“ bleibt auf dem PDC bestehen. Denn der PDC ist der DC, der wohl recht selten eine Anmeldung mit einem korrekten Kennwort bekommt.
Das ganze passiert dann so, dass der Benutzer einige Male hintereinander zuerst ein falsches Kennwort und dann das korrekte verwendet. Beim PDC laufen aber nur die Fehlversuche auf. Wenn die Versuche von einer Applikation kommen, die etliche Retries macht, können je nach „LockoutThreshold“ schon zwei Versuche reichen.
Bei langem „ObservationWindow“ wird das Problem verschärft. Denn dann hat der Benutzer keinen Bezug mehr zu vergangenen Fehlversuchen. Ich spreche hier von einem Intervall von mehreren Stunden oder sogar Tagen, denn das Maximum liegt bei 70 Tagen.
Das ist im Support dann manchmal der Fall, wenn Kunden Service Requests erstellen und von „unerwarteten Kontensperrungen“ sprechen.
Die Fehlversuche können sich neben dem PDC auch auf anderen DCs kumulieren, die aus bestimmten Gründen ebenfalls nur Fehlversuche bekommen. Zum Beispiel von Scripts die DCs oder bestimmte Server angehen, welche per NTLM dann an den bei ihnen lokalen DC gehen. Und wenn diese DCs AvoidPdcOnWan=1 verwenden, wird der Benutzer dort ausgesperrt, und nicht auf dem PDC.
Wo ich schon AvoidPdcOnWan erwähne: Die DCs in der Site des PDC sind natürlich auch alle Kandidaten für lokal generierte Aussperrungen, dort wirkt die Einstellung nicht.
Ich denke die Moral der Geschichte ist, dass Kontensperrungen ein haariges Thema sind und bleiben. Ihr müsst Euch genau überlegen, ob bei der Abwägung von Nutzen und Kosten das Pendel für Sperrungen ausschlägt. Denn egal ob man Kontensperrungen nutzt oder nicht, Auditing für fehlgeschlagene Anmeldungen und eine (automatisierte) Auswertung der Security Logs der DCs bedingen einander.
Kontensperrungen erzeugen eine User-Downtime, ich nenne das immer „DDoS“ gegen Benutzerkonten (Distributed Denial of Service). Wenn Eure Domains angegriffen werden durch Brute-Force Attacken, dann ist der Kampf dagegen der gleiche, mit oder ohne Sperrungen.
Ohne Kontensperrungen ist der Effekt „nur“ überlastete DCs. Die Kennwörter müssen so oder so sicher sein, und Social Engineering und MalWare welche bereits Credentials hat kann keiner der Ansätze bekämpfen.
Als Security Administrator muss man sich dann zwischen einem Stein und einem harten Platz entscheiden…
Rock On!
Herbert