Active Directory Passwortrichtlinie

Eine gute Passwortrichtlinie für das Active Directory festzulegen, ist leider schwierig. Dies liegt auch daran, dass es mehrere Best Practices gibt, die sich teilweise widersprechen. In diesem Beitrag werde ich versuchen, auf die verschiedenen Best Practices einzugehen und meine eigene Empfehlung abzugeben.

Inhaltsverzeichnis:

Bestehende Good Practices

NIST Password Guidelines

Diese Guideline ist heutzutage der Quasi-Standard und kann hier gefunden werden: https://pages.nist.gov/800-63-3/sp800-63b.html

Die NIST empfiehlt hier Einstellungen für verschiedene Arten von Passwörtern. Normale User im Active Directory haben normalerweise ein „Memorized Secret“, das sie ja bei jedem Login manuell eingeben müssen. Für diese Art von Passwort empfiehlt die NIST zusammengefasst folgende Policy (wichtig: SHALL ist ein bisschen verwirrend. Das ist aber einfach ein Synonym von MUST):

Passwortlänge mindestens 8 Zeichen. Das kann allerdings je nach Kontext höher gesetzt werden.
- Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length.
- The minimum password length that should be required depends to a large extent on the threat model being addressed.
Komplexitätsanforderung wird nicht empfohlen.
- Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.
Regelmäßiger Passwortwechsel wird nicht empfohlen.
- Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

Es klingt eigentlich ganz einfach. Es gibt allerdings ein paar weitere Voraussetzungen:

Das Passwort muss als Salted Hash abgespeichert werden, der resistent gegen Offline-Angriffe ist.
- Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks.
Es muss eine Blockliste von schwachen Passwörtern geben (z.B. „Summer2024“, „aaaaaaaa“).
- […] verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised.
Es muss einen Brute-Force-Schutz geben.
- Verifiers SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account […]

Wichtiger Punkt: Hier handelt es sich um eine Passwortrichtlinie, das ist keine Empfehlung für sichere Passwörter. Es sollte jeder Person freistehen, ein 50 Zeichen langes Passwort zu wählen und das Passwort alle 90 Tage zu ändern. Die Idee hinter der Guideline ist, dass zu strenge Passwortrichtlinien nicht zur Sicherheit beitragen, sondern einfach nur die User nerven und im Endeffekt dazu führen, dass die User kreativ werden, um die Policy zu umgehen (z.B. ein Rufzeichen anhängen, damit die Komplexität gegeben ist).

Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as blacklists, secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed.

Es wäre jetzt natürlich viel zu einfach, wenn wir diese Policy 1:1 im Active Directory umsetzen könnten. Die Probleme sind folgende:

Active Directory bietet keinen sicheren Passwort-Hash an. Der beste Passwort-Hash, der angeboten wird, ist der NT-Hash. NT-Hashes haben keinen Salt und sind nicht resistent gegen Offline-Angriffe. Ein 8 Zeichen langes alphanumerisches Passwort kann in Minuten geknackt werden.
Active Directory bietet Out-of-the-Box keine Lösung für eine Blockliste von unsicheren Passwörtern an.

Microsoft-Empfehlungen für Passwortrichtlinien

Die Microsoft-Empfehlung ist leider etwas verwirrend und widerspricht sich auf den ersten Blick. Der erste Artikel, den man zu diesem Thema findet, ist dieser: https://learn.microsoft.com/en-us/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide

Die Empfehlungen in diesem Artikel sind sehr ähnlich zu denen in der NIST-Passwortrichtlinie. Das Problem: der Artikel bezieht sich auf M365, nicht auf On-Premise Active Directory. Daher sind diese Empfehlungen in unserem Fall nicht wirklich anwendbar.

Die empfohlene Passwortrichtlinie für Active Directory findet sich hier: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/password-policy. Beziehungsweise in den darunter verlinkten Artikeln.

Die Good Practice schaut zusammengefasst folgendermaßen aus:

Passwort muss alle 30-90 Tage geändert werden (Maximum Password Age).
Es werden die letzten 24 Passwörter gespeichert (Password History), um die Wiederverwendung früherer Passwörter zu verhindern.
Das Passwort darf maximal einmal am Tag geändert werden (Minimum Password Age), um die Umgehung der Passwortrichtlinie durch wiederholte Änderungen zu verhindern.
Passwortlänge mindestens 8 Zeichen (Minimum Password Length).
Passwörter müssen komplex sein, mindestens 3 aus den 4 Komplexitätsklassen erfüllen (Must Meet Complexity Requirements).
Passwörter dürfen nicht mit umkehrbarer Verschlüsselung gespeichert werden (Reversible Encryption). Dies ist eine legacy Einstellung, die niemals aktiviert werden sollte. Ist sie aktiv, werden Passwörter quasi im Klartext gespeichert.

Diese Richtlinie widerspricht der NIST in fast allen Punkten und ist sehr nervig für die User. Angewandt sieht das Ganze dann so aus:

C:\Users\alice>net accounts
Force user logoff how long after time expires?:       Never
Minimum password age (days):                          1
Maximum password age (days):                          90
Minimum password length:                              8
Length of password history maintained:                24
Lockout threshold:                                    Never
Lockout duration (minutes):                           10
Lockout observation window (minutes):                 10
Computer role:                                        WORKSTATION
The command completed successfully.

Daher schlage ich vor, dass wir unsere eigene Good Practice entwickeln! Natürlich gibt es dazu einen XKCD (https://xkcd.com/927/):

XKCD on Standards

Die VidraSec Empfehlung

Ich lehne mich jetzt ein wenig aus dem Fenster und gebe eine konkrete Empfehlung ab. Ich freue mich über jedes Feedback und adaptiere die Empfehlung gerne.

Es gibt grundsätzlich zwei Probleme, die die Anwendung der NIST-Empfehlung verhindern:

Abspeichern der Passwörter mit schwachem Hash (NT Hash).
Verwendung des Passworts bzw. des Hashes in Authentifizierungsprotokollen (NTLM), die schwächer sind als moderne Hash-Funktionen (argon2, bcrypt).
Keine Out-of-the-Box-Lösung für Blocklisten von schwachen Passwörtern.
Multi-Faktor-Authentifizierung wäre wünschenswert.

Lassen wir uns diese Punkte einzeln betrachten.

Probleme

Offline Speicherung mit schwachem Hash (NT Hash)

Leider gibt es in Windows Active Directory keinen besseren Hash-Algorithmus, hier kann man leider nichts machen. Die Frage ist jedoch: Kann ich das Problem umgehen, indem ich eine andere Passwortrichtlinie setze? Die NIST sagt hier ganz klar, dass weder häufige Passwortänderungen noch Komplexitätsanforderungen zu besseren Passwörtern führen (z.B. „Sommer2024!“):

Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules.

Aus diesem Grund würde ich dieses Risiko akzeptieren. Es wird leider noch eine Weile dauern, bis wir einen besseren Hash-Algorithmus bekommen. Eine Passwortrichtlinie kann uns hier leider auch nicht helfen.

Verwendung von schwachen Protokollen

Hier handelt es sich um ein ähnliches Thema wie oben: eine Passwortrichtlinie hilft mir hier nicht.

Ich will hier nicht zu sehr ins Detail gehen, es sollten aber auf jeden Fall folgende Punkte beachtet werden:

Wo möglich, Kerberos statt NTLM verwenden.
Service-Accounts und andere hochprivilegierte Accounts (z.B. Domain Admins) sollten eine eigene Passwortrichtlinie haben. Deren Passwörter sollten sowieso zufällig generiert und lang sein und in einem Passwort-Manager gespeichert werden.

Blocklisten für schwache Passwörter

Dies ist zwar kein Out-of-the-Box-Feature, es gibt aber mittlerweile eine Lösung von Microsoft: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad-on-premises

Es gibt auch Open-Source-Lösungen und Lösungen von Drittanbietern. Eine dieser Lösungen sollte implementiert werden, damit die Empfehlung der NIST umgesetzt ist.

Multi-Faktor-Authentifizierung (MFA)

MFA ist zwar keine Voraussetzung, verbessert die Sicherheit jedoch erheblich. Daher sollte MFA auf möglichst allen internen und externen Schnittstellen implementiert werden.

Im Active Directory bzw. Client-Umfeld kann hier Windows Hello for Business zum Einsatz kommen. Das Schöne an Windows Hello ist, dass der Login am Windows-Client beispielsweise mit einem PIN funktioniert und nicht mit dem Passwort, das im Active Directory gesetzt wird. Das hat den Vorteil, dass User theoretisch ihr eigentliches Passwort gar nicht kennen müssen. Das Passwort wird im Hintergrund zwar immer noch von Windows Hello verwendet, das ist aber transparent für den User. Bekommt ein Angreifer auf irgendeine Weise den PIN, kann er damit relativ wenig anfangen, solange er nicht auch das Notebook besitzt.

Umsetzung

Um die vorgeschlagenen Änderungen umzusetzen, muss man üblicherweise die Group Policy Default Domain Policy anpassen. Die Einstellungen finden sich unter Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\. Hier setzen wir folgende Werte:

Einstellung	Neuer Wert	Begründung
Maximum password age	0	Passwörter müssen nicht regelmäßig geändert werden.
Minimum password length	10	Je nach Schutzniveau kann das auch höher oder niedriger gesetzt werden. Ich empfehle mindestens 10, besser 12.
Password must meet complexity requirements	Disabled	Wir wollen keine komplexen Passwörter erzwingen.
Store passwords using reversible encryption	Disabled	Ist die Standardeinstellung und verhindert, dass Passwörter im Klartext gespeichert werden.

Diese Einstellungen entsprechen der NIST-Empfehlung, mit einer höheren minimalen Passwortlänge aufgrund des schwachen Hash-Typs.

Die folgenden Einstellungen sind etwas kontroverser und werden leider in der NIST Guideline nicht behandelt:

Einstellung	Neuer Wert	Begründung
Minimum password age	0	Erlaubt Usern ihr Passwort jederzeit zu ändern.
Enforce password history	0	Deaktiviert die Passworthistorie komplett.

⚠️ Diese beiden Einstellungen widersprechen eigentlich gängigen Good Practices [1], [2]. Allerdings habe ich noch keine ähnliche Empfehlung außerhalb des Active Directory-Umfelds gesehen, daher traue ich mich, dieser Empfehlung zu widersprechen. Aber bitte selbst durchdenken! Ich begründe meine Entscheidung in den nächsten Zeilen.

Wenn ich verhindern will, dass ein User absichtlich ein schwaches Passwort setzt, ist es besser, das Passwort in meine Blockliste aufzunehmen. Die Lösung mit der langen Passworthistorie ist nicht ideal.

Die Passworthistorie hat jedoch ein noch größeres Problem: Sie speichert eine riesige Liste an ehemaligen Passwörtern der User. Selbst wenn das alte Passwort in meinem System nicht mehr aktiv ist, könnte es dennoch genutzt werden, um einen anderen Account des Users zu kompromittieren. Für einen Angreifer sind diese Informationen wertvoll; für mich bietet es vielleicht nur einen geringen Sicherheitsgewinn. Daher bin ich der Meinung, dass die Passworthistorie deaktiviert werden sollte.

$ python3 ./secretsdump.py -just-dc-user test -history -k -no-pass vidrasec.lab/bobadmin@dc.vidrasec.lab
Impacket v0.12.0.dev1+20240418.131633.ea96b63a - Copyright 2023 Fortra
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
vidrasec.lab\test:1111:aad3b435b51404eeaad3b435b51404ee:3e24dcead23468ce597d6883c576f657:::
vidrasec.lab\test_history0:1111:aad3b435b51404eeaad3b435b51404ee:9e59e0541eb4c6ab1ac978eb512c2a3a:::
vidrasec.lab\test_history1:1111:aad3b435b51404eeaad3b435b51404ee:b32272b8729f92d524d3c90f2217c88f:::
[...]

Für einen Angreifer sind das super Informationen; für uns stellt es jedoch nur einen marginalen Sicherheitsgewinn dar. Daher bin ich der Meinung, dass die Passwort History deaktiviert werden sollte.

Unsere neue Passwortrichtlinie sieht daher folgendermaßen aus:

C:\Users\alice>net accounts
Force user logoff how long after time expires?:       Never
Minimum password age (days):                          0
Maximum password age (days):                          Unlimited
Minimum password length:                              10
Length of password history maintained:                None
Lockout threshold:                                    Never
Lockout duration (minutes):                           10
Lockout observation window (minutes):                 10
Computer role:                                        PRIMARY
The command completed successfully.

Zusammenfassung

Einige wichtige Punkte zum Abschluss:

Spezifische Richtlinien für unterschiedliche Usertypen: Die vorgeschlagene Passwortrichtlinie ist für normale User gedacht. Für hochprivilegierte Accounts und Service-Accounts sollte eine strengere Richtlinie angewendet werden, bei der auch eine regelmäßige Passwortänderung sinnvoll ist.
Aktivierung der Richtlinie: Eine neue Passwortrichtlinie tritt erst mit dem nächsten Passwortwechsel in Kraft. Ich sehe oft, dass Accounts alte Passwörter verwenden, die nicht den aktuellen Richtlinien entsprechen.
Regelmäßige Überprüfungen notwendig: Die Passwörter im Active Directory sollten regelmäßig überprüft werden. Gibt es Accounts, die denselben Hash verwenden? Existieren hochprivilegierte Accounts mit sehr alten Passwörtern? Wie hoch ist der Prozentsatz der Passworthashes, die innerhalb einer bestimmten Zeit geknackt werden können?

🦦 Für weitergehende Fragen oder Interesse an einem Active Directory Audit oder Penetrationstest, wie immer, einfach kontaktieren! Kontaktieren Sie mich hier