Authentifizierungsrichtlinien: Creds begrenzen, statt nur Kennwörter zu verschärfen
Einführung · 6 Abschnitte · ~9 Min Lesezeit · Stand
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?
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?
- 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.
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?
- 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.