# Authentifizierungs- & Passwort-Richtlinien > Passwort- und Lockout-Entscheidungen, Fine-Grained Password Policies, Authentication Policies und Silos sowie gMSA als betriebliche Sicherheitsgrenzen statt pauschaler Härtung. Track: [Active Directory](https://physar.tech/learn/active-directory) Kanonische Fassung: https://physar.tech/learn/active-directory/auth-policies Stand: 2026-07-27 Interaktiver Teil: 13 Checks (nur im Browser) ## Authentifizierungsrichtlinien: Creds begrenzen, statt nur Kennwörter zu verschärfen ### Die Betriebsfrage: Welche Identität darf sich wo und wie lange ausweisen? Eine Passwort-Richtlinie ist kein Sicherheitsziel für sich. Sie soll das Risiko einer **kompromittierten oder geratenen Identität** senken, ohne den Betrieb durch Lockouts oder Umgehungswege zu verschlechtern. Die bessere Frage ist daher: Wer braucht welche Anmeldeart, auf welchen Hosts und mit welchem Blast Radius? > **Merksatz:** Länge, MFA und gesperrte schwache Passwörter verhindern viele Angriffe; **Silos, gMSA und Anmeldebeschränkungen** begrenzen zusätzlich, was ein kompromittiertes Credential überhaupt erreichen kann. ### Basispolicy, PSO und Lockout sind unterschiedliche Hebel | | | | --- | --- | | Domänen-Password-Policy | Ein Standard für die Domäne. Sie ist die Default-Schicht, nicht der Ort für jede Sonderrolle. | | Fine-Grained Password Policy (PSO) | Abweichende Passwort- und Lockout-Einstellungen für **Benutzer oder globale Sicherheitsgruppen**. Bei mehreren zutreffenden PSOs gewinnt die niedrigste `msDS-PasswordSettingsPrecedence`. | | Lockout | Bremst Online-Rate-Angriffe, kann aber gezielt einen Verfügbarkeitsangriff auslösen. Schwelle, Dauer und Beobachtung sind ein gemeinsames Design. | **Kurzcheck:** Zwei PSOs gelten für dasselbe privilegierte Konto. Welche Regel entscheidet? - [x] Die PSO mit dem kleineren Precedence-Wert ist wirksam. - [ ] Die strengere der beiden Policies wird feldweise zusammengeführt. - [ ] Die Domänen-Default-Policy überschreibt jede PSO. > Richtig. Nicht der Gruppenname oder die zuletzt angelegte Policy entscheidet, sondern der numerisch niedrigste Precedence-Wert. ### Passwortpolitik: Widerstand ohne Ritual Für interaktive Konten ist eine lange, einzigartige Passphrase zusammen mit MFA und einem **Banned-Password-/kompromittierte-Passwörter-Filter** wirksamer als starre, häufige Rotation. Rotation bleibt sinnvoll bei nachgewiesener Kompromittierung oder wenn eine bindende Anforderung sie verlangt. Kein Richtlinienwert ersetzt Incident Response. > **Lockout-Trade-off:** Eine niedrige Lockout-Schwelle kann Passwort-Spraying erschweren, gibt einem Angreifer aber ein billiges DoS-Werkzeug: absichtlich falsche Versuche gegen viele Konten. Bevor du Werte änderst, messe Fehlanmeldungen und kläre Service-Accounts, alte Geräte und Passwort-Caches. ### Silos und Authentication Policies: Credential-Tiering erzwingen Authentication Policies können die TGT-Lebensdauer und Bedingungen der Anmeldung für Benutzer, Geräte und Dienste festlegen. Ein **Authentication Policy Silo** bündelt passende Principals und wird zunächst im Audit-Modus beobachtet, bevor er erzwungen wird. Das ist für Tier-0 besonders wertvoll: Ein hochprivilegiertes Konto darf nur von vorgesehenen administrativen Geräten zu vorgesehenen Diensten authentifizieren. Zulässige Benutzer-, Geräte- und Service-Beziehungen modellieren → Silo und Policy im Audit-Modus zuweisen → Erfolgs-/Fehlereignisse sowie Ausnahmen prüfen → Erst dann Enforcement aktivieren **Kurzcheck:** Warum wird ein Silo vor dem Erzwingen im Audit-Modus getestet? - [x] Weil die Policy legitime, bisher unsichtbare Anmeldepfade blockieren kann und diese zuerst sichtbar werden müssen. - [ ] Weil ein Silo im Audit-Modus die Kennwörter seiner Mitglieder automatisch rotiert. - [ ] Weil Audit-Modus die Policy ohne jede Protokollierung ausführt. > Richtig. Das technische Ziel ist Cred-Containment, aber ein unmodellierter Notfall- oder Dienstpfad darf nicht überraschend ausfallen. ### Dienstidentitäten: gMSA statt Passwort-Datei Ein **group Managed Service Account (gMSA)** hat ein von AD verwaltetes, regelmäßig wechselndes Kennwort. Entscheidend ist nicht nur der Kontotyp, sondern die Zugriffsgrenze: Nur die explizit autorisierten Hosts dürfen das aktuelle Kennwort abrufen. Ein gMSA ist kein magischer Ersatz für minimale Rechte, Patchen oder die Prüfung, ob ein Dienst überhaupt Tier-0 berührt. - Kein menschliches Shared Password in Skripten oder Tresoren verteilen. - Abrufberechtigte Hosts eng definieren und regelmäßig prüfen. - Dienstrechte separat minimal halten; ein gMSA darf nicht aus Bequemlichkeit Domain Admin werden. - Vor Migration Abhängigkeiten und Fallback testen, sonst wird der Passwortwechsel zum Ausfall. ### Zusammenfassung — gleich im Check Du entscheidest zwischen Default-Policy und PSO, behandelst Lockout als Sicherheits-**und** Verfügbarkeitsentscheidung, begrenzt Tier-0-Credentials mit Silos, setzt gMSA mit einer Host-Grenze ein und prüfst Kerberos-Parameter nur im Zusammenhang mit Kompatibilität und Migration. > **Grenze:** Richtlinien nicht blind scharf schalten: Für jede Einschränkung braucht es eine gemessene Ausgangslage, einen Audit-/Pilotpfad und einen dokumentierten Break-Glass-Prozess. ## Quellen - Microsoft Learn — Configure fine-grained password policies for AD DS - Microsoft Learn — Authentication Policies and Authentication Policy Silos - Microsoft Learn — Group Managed Service Accounts overview - NIST SP 800-63B — Memorized Secret Verifiers - Microsoft Learn — Fine-grained password policies (resultant PSO and precedence) - Microsoft Learn — Fine-grained password policies apply to global security groups and users - Microsoft Learn — Account lockout policy - NIST SP 800-63B — throttling and memorized secrets - Microsoft Learn — Microsoft Entra Password Protection - Microsoft Learn — Authentication Policies and Authentication Policy Silos (audit/enforcement) - Microsoft Learn — Authentication policy silos restrict high-privilege credentials - Microsoft security guidance — enterprise access model - Microsoft Learn — Group Managed Service Accounts overview and password retrieval - Microsoft Learn — Group Managed Service Accounts - Microsoft security guidance — least privilege - Microsoft Learn — Kerberos encryption types and RC4 deprecation guidance - Microsoft Learn — Kerberos policy settings - Microsoft Learn — Authentication Policies TGT lifetime - Microsoft security guidance — emergency access accounts - Microsoft Learn — Authentication policy silos - Microsoft Learn — Authentication policy silos audit and enforce - Microsoft guidance — privileged access rollout - Microsoft Learn — Fine-grained password policies