Ausgangslage: ohne Schwellwert bleibt Online-Raten zu billig

In vielen Active-Directory-Umgebungen ist der Account Lockout Threshold historisch gewachsen. Manchmal steht er auf 0, damit niemand durch vergessene Passwörter oder alte Dienste ausgesperrt wird. Manchmal ist er extrem niedrig, weil "drei Fehlversuche" sauber klingt. Beides ist selten ein gutes Zielbild.

Ein deaktivierter Lockout macht Online-Raten gegen Domänenkonten unnötig billig. Ein zu aggressiver Lockout kann dagegen Helpdesk, Admins und produktive Anwendungen lahmlegen. Besonders kritisch wird es, wenn alte Dienste, geplante Tasks, mobile Clients oder gespeicherte Anmeldeinformationen dauerhaft falsche Passwörter verwenden. Dann entsteht kein Security-Signal, sondern ein Lockout-Sturm.

Der Threshold ist deshalb keine isolierte Checkbox. Er hängt an:

  • der Default Domain Password Policy,
  • Fine-Grained Password Policies für definierte Gruppen,
  • Authentifizierungswegen wie VPN, RDP, IIS, ADFS, Entra Connect, Legacy-Apps und Dateiablagen,
  • Monitoring auf Domain Controllern und im SIEM,
  • Helpdesk-Prozessen für gesperrte Konten,
  • Service-Account-Hygiene und Passwortrotation.

Wichtig ist auch die Erwartungshaltung: Account Lockout stoppt kein schwaches Passwortmodell und ersetzt keine MFA an extern erreichbaren Zugängen. Er begrenzt Online-Versuche, erzeugt verwertbare Signale und zwingt alte Fehlkonfigurationen ans Licht.

Zielbild: ein messbarer Grenzwert mit kontrollierten Ausnahmen

Ein belastbares Zielbild sieht nicht so aus: "Wir setzen überall drei Versuche und hoffen." Es ist konkreter:

  1. Domänenkonten haben einen wirksamen Lockout Threshold. 0 ist für normale Benutzerkonten kein akzeptabler Dauerzustand.
  2. Threshold, Beobachtungsfenster und Lockout-Dauer passen zusammen. Ein Beispiel ist ein Schwellwert im Bereich von 5 bis 10 Fehlversuchen mit einem kurzen Beobachtungs- und Sperrfenster. Der konkrete Wert muss aus Betriebsdaten kommen.
  3. Fine-Grained Password Policies sind dokumentiert. Niemand muss raten, welche Richtlinie für Admins, privilegierte Rollen oder Sondergruppen tatsächlich wirkt.
  4. Service-Accounts werden nicht durch pauschale Ausnahmen versteckt. Stale Credentials, manuelle Passwörter und interaktive Nutzung werden bereinigt oder auf gMSA umgestellt.
  5. Lockouts werden überwacht und triagiert. Ein gesperrtes Konto ist ein Betriebsereignis und ein Security-Signal.
  6. Externe Zugänge haben zusätzliche Kontrollen. VPN, RDP-Gateways, ADFS, Entra ID und veröffentlichte Webdienste brauchen eigene Schutzmaßnahmen wie MFA, Rate-Limits und Conditional Access.

Das Ziel ist ein Threshold, der Angriffe verlangsamt und sichtbar macht, ohne die Domäne als Denial-of-Service-Hebel gegen sich selbst zu verwenden.

Umsetzung: Policies, Telemetrie, dann Change

1) Wirksame Richtlinien read-only erfassen

Starte mit einer Bestandsaufnahme. Die folgenden Abfragen verändern nichts:

Import-Module ActiveDirectory

Get-ADDefaultDomainPasswordPolicy |
  Select-Object LockoutThreshold,LockoutObservationWindow,LockoutDuration,ComplexityEnabled,MinPasswordLength

Get-ADFineGrainedPasswordPolicy -Filter * |
  Select-Object Name,Precedence,LockoutThreshold,LockoutObservationWindow,LockoutDuration,AppliesTo

Für Stichproben lohnt sich zusätzlich die tatsächlich wirksame Policy einzelner Konten:

Get-ADUserResultantPasswordPolicy -Identity "alice"

Wenn hier mehrere Fine-Grained Policies mit unklarer Zielgruppe auftauchen, ist das bereits ein Vorprojekt: erst Richtlinienbereinigung, dann Threshold-Änderung.

2) Lockout- und Fehlanmeldedaten vor dem Change sammeln

Vor einer Änderung sollten mindestens ein bis zwei normale Geschäftszyklen ausgewertet werden. Relevante Signale sind:

  • Account-Lockout-Events auf Domain Controllern,
  • fehlgeschlagene Anmeldungen nach Konto, Quelle und Authentifizierungsart,
  • wiederkehrende Sperrungen derselben Konten,
  • Quellsysteme mit vielen falschen Anmeldeversuchen,
  • Service-Accounts mit interaktiven oder Remote-Anmeldeversuchen,
  • Helpdesk-Tickets zu Passwortproblemen.

Die Daten entscheiden, ob ein niedriger Threshold realistisch ist oder ob zuerst alte Clients, Dienste und gespeicherte Credentials bereinigt werden müssen. Ohne diese Telemetrie ist der Change geraten.

3) Baseline mit Betriebsverträglichkeit festlegen

Ein praxistauglicher Startwert liegt oft nicht bei drei Fehlversuchen. Drei kann für privilegierte, stark kontrollierte Konten sinnvoll sein, ist für breite Benutzergruppen aber häufig zu empfindlich. Viele Umgebungen landen nach Auswertung eher in einem Bereich von 5 bis 10 Fehlversuchen, kombiniert mit einem kurzen Beobachtungsfenster und einer Lockout-Dauer, die Helpdesk und Betrieb verkraften.

Die drei Parameter müssen gemeinsam betrachtet werden:

  • LockoutThreshold: Wie viele Fehlversuche bis zur Sperre?
  • LockoutObservationWindow: Nach welcher Zeit wird der Fehlversuchszähler zurückgesetzt?
  • LockoutDuration: Wie lange bleibt das Konto gesperrt?

Ein Schwellenwert ohne Monitoring ist schwach. Eine Sperrdauer ohne Helpdesk-Prozess ist riskant. Ein Beobachtungsfenster ohne Verständnis der normalen Benutzerfehler erzeugt Rauschen.

4) Änderung kontrolliert über Domain Policy oder FGPP ausrollen

Die Default Domain Password Policy betrifft normale Domänenkonten. Fine-Grained Password Policies sind für klar abgegrenzte Gruppen sinnvoll, etwa privilegierte Rollen oder Sonderfälle. OU-verknüpfte GPOs sind hier eine häufige Fehlannahme: Für Domänenkonten zählt die Domänen-Account-Policy beziehungsweise die wirksame Fine-Grained Password Policy, nicht irgendeine OU-Policy.

Beispiel für eine kontrollierte Default-Domain-Anpassung:

Set-ADDefaultDomainPasswordPolicy -Identity "contoso.local" `
  -LockoutThreshold 10 `
  -LockoutObservationWindow (New-TimeSpan -Minutes 15) `
  -LockoutDuration (New-TimeSpan -Minutes 15)

Das ist kein universeller Zielwert, sondern ein Beispiel. In produktiven Umgebungen gehört der Change in ein Wartungsfenster mit Rollback-Plan, Helpdesk-Briefing und aktiver Überwachung.

5) Service-Accounts nicht als Ausnahme-Müllhalde behandeln

Service-Accounts sind der häufigste Grund, warum Teams Lockout-Richtlinien zu weich setzen. Das ist verständlich, aber gefährlich. Ein Dienst mit altem Passwort sollte nicht zur Begründung werden, alle Benutzerkonten ohne Lockout zu betreiben.

Pragmatischer Umgang:

  • Service-Accounts inventarisieren und Owner festlegen.
  • Interaktive Anmeldung, RDP und lokale Anmeldung für Service-Accounts einschränken.
  • Gespeicherte Passwörter in Diensten, Tasks, IIS-App-Pools und Drittanwendungen bereinigen.
  • Wo möglich gMSA nutzen.
  • Unvermeidbare Ausnahmen befristen und kompensierende Kontrollen dokumentieren.

Eine Fine-Grained Policy mit LockoutThreshold 0 für eine breite Service-Account-Gruppe ist fast immer ein Zeichen, dass das eigentliche Problem nur verschoben wurde.

6) Lockouts als Security- und Betriebsprozess behandeln

Nach dem Rollout braucht die Umgebung eine klare Auswertung:

  • Welche Konten werden wiederholt gesperrt?
  • Welche Systeme lösen Lockouts aus?
  • Welche Quellen erzeugen viele Fehlversuche ohne Lockout?
  • Welche Sperrungen betreffen privilegierte Konten?
  • Welche Fälle sind Benutzerfehler, welche sind Fehlkonfiguration, welche sind verdächtig?

Der Prozess muss Helpdesk und Security verbinden. Helpdesk sieht die akuten Sperrungen, Security sieht Muster über Quellen, Zeiten und Zielkonten. Erst zusammen entsteht ein brauchbarer Schutzmechanismus.

Vorteile

  • Online-Raten wird begrenzt: Angreifer können nicht unbegrenzt gegen Domänenkonten testen.
  • Password-Spraying wird sichtbarer: Niedrigfrequente Fehlversuche bleiben ein Thema, aber Lockout- und Fehlanmeldedaten liefern bessere Signale.
  • Alte Fehlkonfigurationen werden sichtbar: Dienste, Tasks und Clients mit gespeicherten falschen Passwörtern fallen auf.
  • Geringe technische Einstiegshürde: Die Kontrolle ist in AD vorhanden und braucht keine neue Infrastruktur.
  • Messbarer Zustand: Threshold, Lockouts, Top-Quellen und betroffene Konten lassen sich sauber reporten.
  • Gute Ergänzung zu MFA und Conditional Access: Besonders für hybride Identitäten entsteht ein klarerer Basisschutz auf der On-Prem-Seite.

Nachteile und Grenzen

  • Denial-of-Service-Risiko: Ein zu niedriger Threshold kann Benutzer, Admins oder Servicekonten massenhaft sperren.
  • Nicht ausreichend gegen langsames Spraying: Sehr niedrige Versuchsraten können unter dem Beobachtungsfenster bleiben.
  • Keine Passwortqualitätskontrolle: Schwache Passwörter bleiben schwach; Lockout begrenzt nur Online-Versuche.
  • Legacy-Systeme können Betrieb stören: Alte gespeicherte Credentials erzeugen wiederholte Sperrungen.
  • Privilegierte Konten brauchen Sonderplanung: Admin-Lockouts können Incident Response und Betrieb behindern, wenn Break-Glass-Prozesse fehlen.
  • Cloud- und On-Prem-Signale müssen zusammengeführt werden: AD-Lockout allein schützt keine externen Authentifizierungsflächen.

Typische Stolperfallen

  • 0 als "stabiler Betrieb" verkaufen: Kein Lockout ist bequem, aber für normale Benutzerkonten ein dauerhaft schlechtes Zielbild.
  • Zu niedrig starten: Ein aggressiver Threshold ohne Telemetrie erzeugt Helpdesk-Last und Akzeptanzprobleme.
  • OU-GPOs falsch verstehen: Account Policies für Domänenkonten wirken nicht wie normale Computer- oder Benutzer-GPOs auf OU-Ebene.
  • Fine-Grained Policies nicht dokumentieren: Dann ist unklar, welcher Schwellwert für welches Konto tatsächlich gilt.
  • Service-Account-Lockouts ignorieren: Wiederholte Sperrungen zeigen meistens ein echtes Betriebs- oder Credential-Problem.
  • Keine Quelle ermitteln: "Benutzer ist gesperrt" reicht nicht; entscheidend ist das auslösende System.
  • Helpdesk nicht vorbereiten: Ohne Runbook werden Security-Signale zu Einzelfall-Tickets ohne Mustererkennung.

Projekt-Checkliste

  • [ ] Default Domain Password Policy und alle Fine-Grained Password Policies read-only erfassen.
  • [ ] Resultant Policy für Stichproben aus normalen Benutzern, Admins und Service-Accounts prüfen.
  • [ ] Lockout- und Fehlanmeldedaten über mindestens einen normalen Geschäftszyklus auswerten.
  • [ ] Zielwerte für Threshold, Beobachtungsfenster und Sperrdauer dokumentieren.
  • [ ] Service-Accounts mit Lockout-Risiko inventarisieren und Owner zuweisen.
  • [ ] Gespeicherte falsche Credentials in Diensten, Tasks, App-Pools und Clients bereinigen.
  • [ ] Helpdesk-Runbook für Lockouts und Quellenanalyse erstellen.
  • [ ] SIEM- oder Eventlog-Monitoring für Lockouts, Fehlversuche und privilegierte Konten aktivieren.
  • [ ] Änderung in einem kontrollierten Fenster ausrollen und aktiv beobachten.
  • [ ] Ausnahmen befristen, begründen und regelmäßig neu bewerten.