AD-Kennwortrichtlinie, die wirkt: Länge, FGPP, Sperrlisten

Die meisten Active-Directory-Kompromittierungen, die mit einem Kennwort beginnen, erfordern kein raffiniertes Knacken. Sie beginnen mit Password Spraying gegen eine Richtlinie, die Welcome1! zulässt, mit einem Dienstkonto, dessen Kennwort 2014 gesetzt wurde, oder mit einem offline geknackten Hash, weil acht Zeichen plus Pflicht-Sonderzeichen einen winzigen Suchraum ergeben. Die Standard-Domänenrichtlinie spiegelt in vielen Umgebungen noch Empfehlungen von vor zwei Jahrzehnten wider: kurze Kennwörter, Komplexitätsregeln, Ablauf nach 90 Tagen und nichts, was prüft, ob ein Kennwort bereits in einer Leak-Sammlung auftaucht.

Dieser Leitfaden baut die Richtlinie auf Basis aktueller Erkenntnisse neu auf. Er behandelt, was NIST SP 800-63B heute sagt, wie Sie die Qualität bestehender Kennwörter messen, wie Sie fein abgestufte Kennwortrichtlinien für Admins und Dienstkonten staffeln, wie Sie beim Ändern Prüfungen gegen gesperrte und geleakte Kennwörter ergänzen und wie Sie den Wechselzwang sicher abschaffen.

Was die aktuellen Empfehlungen tatsächlich sagen

NIST SP 800-63B Revision 4 (2025 finalisiert) ist die Referenz, die die meisten Prüfer akzeptieren. Die für AD relevanten Punkte:

• Länge vor Komplexität. Mindestens 15 Zeichen, wenn das Kennwort der einzige Faktor ist, 8 Zeichen als Teil von MFA. Mindestens 64 Zeichen zulassen.
• Keine Zusammensetzungsregeln. Prüfinstanzen sollten keine Mischung von Zeichentypen verlangen; das treibt Benutzer zu vorhersehbaren Ersetzungen.
• Kein periodischer Wechsel. Kennwörter nur bei Anzeichen einer Kompromittierung ändern.
• Sperrlisten sind Pflicht. Neue Kennwörter gegen bekannt geleakte Kennwörter, Wörterbuchbegriffe und kontextspezifische Wörter (Firmenname, Produktnamen) prüfen.
• Online-Rateversuche drosseln, statt sich auf Komplexität zu verlassen.

Die Sicherheits-Baselines von Microsoft haben den Kennwortablauf 2019 aus demselben Grund gestrichen. Ihre Aufsichtsbehörde oder Ihr Cyberversicherer verlangt möglicherweise weiterhin Rotation; dokumentieren Sie die unten beschriebenen kompensierenden Kontrollen und verhandeln Sie auf dieser Grundlage.

Messen: Was die Domäne heute erzwingt

Get-ADDefaultDomainPasswordPolicy

Get-ADFineGrainedPasswordPolicy -Filter * |
  Select-Object Name, Precedence, MinPasswordLength, MaxPasswordAge, LockoutThreshold, AppliesTo

# Konten, die die Richtlinie vollständig umgehen
Get-ADUser -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=32)' | Select-Object SamAccountName   # PASSWD_NOTREQD
Get-ADUser -Filter 'PasswordNeverExpires -eq $true -and Enabled -eq $true' -Properties PasswordLastSet |
  Sort-Object PasswordLastSet | Select-Object SamAccountName, PasswordLastSet
Get-ADUser -Filter 'AllowReversiblePasswordEncryption -eq $true' | Select-Object SamAccountName

Konten mit PASSWD_NOTREQD können unabhängig von der Richtlinie ein leeres Kennwort haben; löschen Sie das Flag mit Set-ADUser -PasswordNotRequired $false, nachdem Sie bestätigt haben, dass jedes ein echtes Kennwort besitzt. Umkehrbare Verschlüsselung speichert ein wiederherstellbares Kennwort; die Anzahl sollte null sein.

Auditieren: die Qualität bestehender Kennwörter

Eine Richtlinie greift erst beim nächsten Wechsel; Sie müssen also wissen, was bereits vorhanden ist. Test-PasswordQuality aus dem Modul DSInternals vergleicht NT-Hashes mit einer Liste geleakter Hashes (zum Beispiel dem NTLM-Download von Have I Been Pwned) und meldet leere, doppelte, Standard- und schwache Kennwörter. Es repliziert dazu Hashes von einem DC, was den Lauf selbst zu einem Tier-0-Vorgang macht: Führen Sie ihn von einer Privileged Access Workstation mit einer zeitlich begrenzten Replikationsberechtigung aus, bewahren Sie die Ausgabe verschlüsselt auf und entfernen Sie die Rechte anschließend. Kommerzielle Werkzeuge wie Specops Password Auditor bieten denselben reinen Lesebericht.

Konzentrieren Sie sich auf drei Funde:

1. Gemeinsame Kennwörter zwischen Admin- und Standardkonto derselben Person.
2. Geleakte Kennwörter auf privilegierten oder Dienstkonten.
3. Doppelte Hashes über Dienstkonten hinweg; sie offenbaren wiederverwendete Anmeldeinformationen, die ein einziger geknackter Kerberoasting-Hash freilegen würde.

Erzwingen Sie in den privilegierten und geleakten Fällen sofort ein Zurücksetzen; warten Sie nicht auf die neue Richtlinie.

Durchsetzen: die Domänen-Baseline

Die Domänenkennwortrichtlinie wird aus der am Domänenstamm verknüpften GPO gelesen, normalerweise der Default Domain Policy, unter Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy. Mit OUs verknüpfte Kennwortrichtlinien-GPOs wirken sich nicht auf Domänenkonten aus.

Der Gruppenrichtlinien-Editor begrenzt die Mindestlänge auf 14. Neuere Windows-Versionen ergänzen im selben Knoten Relax minimum password length limits und Minimum password length audit, die höhere Werte erlauben; jeder DC und jeder Client, der die Richtlinie auswertet, muss das unterstützen – testen Sie es also, bevor Sie sich darauf verlassen. PSOs hatten diese Grenze nie und sind der einfachere Weg zu 15+.

Für die Kontosperrung verwendet die Windows-Sicherheits-Baseline einen Schwellenwert von 10 Fehlversuchen mit 15 Minuten Sperrdauer und Zurücksetzungszeitraum. Das reicht, um Spraying auszubremsen, ohne einem Angreifer zu erlauben, das ganze Unternehmen auszusperren.

Durchsetzen: fein abgestufte Kennwortrichtlinien

PSOs erfordern eine Domänenfunktionsebene von Windows Server 2008 oder höher und werden in CN=Password Settings Container,CN=System,DC=... gespeichert. Bauen Sie eine kleine, bewusst gewählte Menge auf:

New-ADFineGrainedPasswordPolicy -Name "PSO-AllUsers-15" -Precedence 100 `
    -MinPasswordLength 15 -ComplexityEnabled $false -PasswordHistoryCount 24 `
    -MaxPasswordAge "365.00:00:00" -MinPasswordAge "1.00:00:00" `
    -LockoutThreshold 10 -LockoutDuration "00:15:00" -LockoutObservationWindow "00:15:00" `
    -ReversibleEncryptionEnabled $false

New-ADFineGrainedPasswordPolicy -Name "PSO-Admins-20" -Precedence 10 `
    -MinPasswordLength 20 -ComplexityEnabled $false -PasswordHistoryCount 24 `
    -MaxPasswordAge "365.00:00:00" -MinPasswordAge "1.00:00:00" `
    -LockoutThreshold 10 -LockoutDuration "00:15:00" -LockoutObservationWindow "00:15:00" `
    -ReversibleEncryptionEnabled $false

New-ADFineGrainedPasswordPolicy -Name "PSO-ServiceAccounts-30" -Precedence 5 `
    -MinPasswordLength 30 -ComplexityEnabled $false -PasswordHistoryCount 24 `
    -MaxPasswordAge "365.00:00:00" -MinPasswordAge "0.00:00:00" `
    -LockoutThreshold 0 -ReversibleEncryptionEnabled $false

Add-ADFineGrainedPasswordPolicySubject "PSO-AllUsers-15"        -Subjects "PSO-Scope-AllUsers"
Add-ADFineGrainedPasswordPolicySubject "PSO-Admins-20"          -Subjects "PSO-Scope-Admins"
Add-ADFineGrainedPasswordPolicySubject "PSO-ServiceAccounts-30" -Subjects "PSO-Scope-ServiceAccounts"

Hinweise zum Design:

• PSOs gelten nur für Benutzer und globale Sicherheitsgruppen, nicht für OUs. Verwenden Sie per Skript gepflegte Schattengruppen, wenn Sie in OUs denken.
• Die niedrigste Rangfolge gewinnt; eine direkt mit einem Benutzer verknüpfte PSO schlägt gruppenverknüpfte PSOs unabhängig von der Rangfolge. Halten Sie Abstände zwischen den Rangfolgewerten.
• Die Dienstkonten-PSO deaktiviert die Kontosperrung, weil ein gesperrtes Dienstkonto ein Ausfall ist, den ein Angreifer nach Belieben auslösen kann; sie kompensiert mit Länge und sollte schrumpfen, während Konten zu gMSA wechseln.
• Das Höchstalter von 365 Tagen ist ein Zwischenwert. Sobald die unten beschriebenen kompensierenden Kontrollen aktiv sind, deaktivieren Sie Enforce maximum password age in jeder PSO im Active Directory-Verwaltungscenter.

Kombinieren Sie bei privilegierten Konten Länge mit stärkerer Authentifizierung statt mit häufigerer Rotation: Smartcard oder FIDO2-gestütztes Windows Hello for Business, Mitgliedschaft in Protected Users sowie Authentifizierungsrichtlinien und -silos. Ab der Domänenfunktionsebene Windows Server 2016 kann für Konten mit Smart card is required for interactive logon das NTLM-Geheimnis automatisch erneuert werden, wenn msDS-ExpirePasswordsOnSmartCardOnlyAccounts für die Domäne aktiviert ist.

Durchsetzen: Prüfung gegen gesperrte und geleakte Kennwörter

Eine Sperrliste ist die Kontrolle, die Komplexität und Rotation ersetzt. Optionen:

• Microsoft Entra Password Protection für AD DS. Ein DC-Agent (eine Kennwortfilter-DLL) und ein Proxydienst erzwingen bei jeder lokalen Kennwortänderung die globale Sperrliste von Microsoft und Ihre eigene Liste. Für die lokale Erzwingung sind Lizenzen für Entra ID P1 oder P2 erforderlich, und die Installation des Agenten erfordert einen Neustart des DC. Beginnen Sie im Modus Audit, prüfen Sie, welche Änderungen abgelehnt worden wären, und wechseln Sie dann zu Enforce.
• Lithnet Password Protection (Open Source) oder kommerzielle Filter wie Specops Password Policy, die ohne Cloud-Anbindung gegen eine lokale Kopie geleakter Hashes prüfen können.

Was auch immer Sie wählen, es läuft als Kennwortfilter innerhalb von LSASS auf jedem DC; behandeln Sie Installation, Updates und Konfigurationsspeicher daher als Tier-0-Änderung.

# Entra Password Protection: bestätigen, dass jeder DC den Agenten ausführt und sich kürzlich gemeldet hat
Get-AzureADPasswordProtectionDCAgent | Format-Table ServerFQDN, HeartbeatUTC

Den Wechselzwang sicher abschaffen

Entfernen Sie den Ablauf erst, wenn Folgendes zutrifft: Die Sperrliste wird erzwungen, die Mindestlänge beträgt 14+, MFA deckt Fernzugriff und Cloud-Apps ab, und Sie haben einen Prozess, um bei Anzeichen einer Kompromittierung ein Zurücksetzen zu erzwingen (Leak-Feeds, Warnungen zu riskanten Anmeldungen, Incident Response). Setzen Sie dann Maximum password age in der Domänen-GPO auf 0 und deaktivieren Sie Enforce maximum password age in den PSOs für Benutzer und Admins. Der Ablauf wird aus pwdLastSet und der wirksamen Richtlinie berechnet; ausstehende Ablaufwarnungen verschwinden daher sofort, sonst ändert sich nichts.

Überprüfen

# Wirksame Richtlinie für repräsentative Konten
"jdoe","adm-jdoe","svc_legacyapp" | ForEach-Object {
    $pso = Get-ADUserResultantPasswordPolicy -Identity $_
    [pscustomobject]@{ User = $_; PSO = $pso.Name; MinLength = $pso.MinPasswordLength }
}

# Keine Flags zur Umgehung der Richtlinie mehr vorhanden
(Get-ADUser -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=32)').Count

Ein Benutzer ohne PSO liefert bei Get-ADUserResultantPasswordPolicy nichts zurück – für ihn gilt die Domänenrichtlinie. Testen Sie eine Änderung mit einem bekannt gesperrten Kennwort, etwa dem Firmennamen plus Jahreszahl, und bestätigen Sie, dass es abgelehnt wird. Wiederholen Sie das Audit der Kennwortqualität vierteljährlich und verfolgen Sie die Anzahl geleakter und gemeinsam genutzter Hashes als Kennzahl.

Was dabei kaputtgeht

• Vorhandene kurze Kennwörter funktionieren weiter. Eine höhere Mindestlänge wird nicht gegen aktuelle Kennwörter geprüft; Benutzer müssen sie erst beim nächsten Kennwortwechsel einhalten. Self-Service-Portale und skriptgesteuerte Zurücksetzungen, die kurze Kennwörter erzeugen, scheitern jedoch sofort.
• Anwendungen, die Kennwörter selbst validieren (manche VPNs, HR-Systeme mit Kennwortsynchronisierung), lehnen möglicherweise Längen über 14 oder 16 Zeichen ab.
• Das Entfernen der Kontosperrung bei Dienstkonten macht Online-Rateversuche gegen sie möglich; das ist nur mit 30+ zufälligen Zeichen und Überwachung der Fehlschläge 4625 und 4771 akzeptabel.
• Kennwortfilter-DLLs auf DCs können sämtliche Kennwortänderungen blockieren, wenn der Agent schwerwiegend ausfällt; führen Sie sie zuerst auf einem DC ein und halten Sie einen Rückfallplan bereit.
• Das Abschaffen der Rotation kann einer schriftlich festgelegten Compliance-Kontrolle widersprechen, bis das Richtliniendokument aktualisiert ist.

Weiterführende Lektüre: das Thema Kennwörter & Dienstkonten, der Grundlagenleitfaden zur Dienstkontenhärtung und Kerberos-Härtung, wo die Kennwortlänge direkt bestimmt, wie lange ein Offline-Angriff auf ein Dienstticket dauert.