← Active Directory

Authentifizierungs- & Passwort-Richtlinien

Die Benutzer liegen sauber in OUs, also hängt man die strengere Kennwortrichtlinie einfach an die OU der Administratoren — und genau das geht nicht: Ein PSO lässt sich laut Dokumentation ausschließlich auf Benutzerobjekte und globale Sicherheitsgruppen anwenden, nie auf eine OU. Dieses Modul behandelt Authentifizierungsrichtlinien als Betriebsentscheidungen mit zwei Seiten — die drei getrennten Hebel Domänenrichtlinie, PSO und Kontosperrung, die Präzedenzregel samt ihrem willkürlichen Tiebreak über die kleinste GUID, Sperrschwellen als Verfügbarkeitsrisiko, die Gruppe Protected Users mit ihren dokumentierten Verboten und der Kehrseite, dass ihre Mitglieder sich offline nicht mehr anmelden können, sowie Silos und verwaltete Dienstkonten als die Grenzen, die den Schaden begrenzen, wenn ein Credential doch abfließt.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-06

Die Frage hinter allen Richtlinien

Eine Passwort-Richtlinie ist kein Sicherheitsziel für sich. Sie soll das Risiko einer geratenen oder gestohlenen Identität senken — und zwar ohne den Betrieb durch Sperren und Umgehungen zu beschädigen. Die nützlichere Frage lautet deshalb nicht „wie streng?“, sondern: Was kann ein Angreifer mit diesem gestohlenen Credential überhaupt anfangen, und wie lange?

Daraus ergeben sich zwei Familien von Werkzeugen, die man nicht verwechseln sollte. Die einen erschweren, dass ein Credential kompromittiert wird — Länge, Sperrlisten für bekannte Kennwörter, MFA. Die anderen begrenzen, was danach damit möglich ist — Anmeldebeschränkungen, Ticket-Lebensdauern, verwaltete Dienstkonten, Silos.

MerksatzDie erste Familie senkt die Wahrscheinlichkeit, die zweite den Schaden. Wer nur an der ersten dreht, hat eine Umgebung, in der ein einziger erfolgreicher Angriff alles kostet — und Nutzer, die Kennwörter auf Zettel schreiben.

Drei Hebel, die oft in einen Topf geworfen werden

Domänen-Passwortrichtlinie
Gilt für alle Konten der Domäne. Wird über die Default Domain Policy gesetzt und ist genau einmal vorhanden — es gibt keine zweite für eine Teilmenge.
Fine-Grained Password Policy (PSO)
Ein eigenes Objekt, mit dem einzelne Konten oder Gruppen abweichende Kennwort- und Sperrvorgaben bekommen. Der Weg für „strenger für Administratoren“.
Kontosperrung (Lockout)
Schwelle, Dauer und Beobachtungsfenster. Steht sowohl in der Domänenrichtlinie als auch in jedem PSO — und ist die einzige der drei, die auch ein Verfügbarkeitsrisiko trägt.
Warum es PSOs überhaupt gibtVor ihrer Einführung galt pro Domäne genau eine Kennwortrichtlinie. Wer für Administratoren strengere Vorgaben wollte, musste eine eigene Domäne aufbauen oder einen Kennwortfilter programmieren — beides teuer. PSOs haben genau dieses Problem gelöst; sie sind kein Feinschliff, sondern der Ersatz für einen früher üblichen Strukturaufwand.

PSOs: worauf sie wirken — und worauf nicht

Hier steckt die häufigste Fehlannahme des ganzen Themas, und sie kostet regelmäßig ein halbes Projekt: Ein PSO lässt sich nicht auf eine OU anwenden. Die Dokumentation ist an dieser Stelle ausdrücklich. Zulässige Ziele sind nur:

  • Benutzerobjekte (und inetOrgPerson, wo es statt user verwendet wird)
  • Globale Sicherheitsgruppen
Was das für die Praxis heißtWer seine Benutzer sauber in OUs sortiert hat, kann diese Struktur für Kennwortrichtlinien nicht wiederverwenden. Der dokumentierte Weg ist, globale Sicherheitsgruppen mit den Benutzern der jeweiligen OU zu bilden und das PSO daran zu hängen. Der Preis steht gleich daneben: Verschiebt jemand einen Benutzer in eine andere OU, muss die Gruppenmitgliedschaft von Hand nachgezogen werden — die beiden Strukturen laufen sonst auseinander, ohne dass irgendetwas fehlschlägt.
Zwei weitere GrenzenPSOs gelten nicht für Computerobjekte. Und weil sie nur auf Benutzerobjekte wirken, beeinflussen sie laut Dokumentation auch nicht die Kennwort-Rotationsintervalle verwalteter Dienstkonten — ein gMSA rotiert nach seiner eigenen Logik, unabhängig von jedem PSO. Wer die Rotation eines gMSA über ein PSO steuern will, konfiguriert etwas, das nie greift.

Welches PSO gewinnt

Ein Benutzer kann über mehrere Gruppen von mehreren PSOs erfasst werden. Es gilt aber immer genau eines — das effektive. Die Auflösung folgt einer festen, dokumentierten Reihenfolge:

Ein PSO, das direkt am Benutzerobjekt hängt, schlägt jedes über Gruppen zugewiesene↓Sonst gewinnt das PSO mit dem niedrigsten Präzedenzwert↓Bei Gleichstand entscheidet die kleinste GUID
Direkt schlägt Gruppe, niedrig schlägt hoch
Der Tiebreak, den niemand haben willDass bei gleichem Präzedenzwert die kleinste GUID entscheidet, ist eine deterministische, aber vollkommen willkürliche Regel — die GUID hat mit deiner Absicht nichts zu tun. Zwei PSOs mit demselben Wert sind deshalb kein Unentschieden, sondern ein Konfigurationsfehler mit stabilem, aber unbeabsichtigtem Ergebnis. Vergib Präzedenzwerte in Sprüngen und dokumentiere sie.
Wie du das effektive PSO nachsiehstDas Attribut msDS-ResultantPSO eines Benutzerobjekts nennt das tatsächlich wirksame PSO. Das ist die einzige verlässliche Antwort auf „welche Kennwortregeln gelten für diesen Menschen“ — jede Herleitung über Gruppenmitgliedschaften ist eine Rekonstruktion, und die kann falsch sein.

Passwortpolitik: Widerstand statt Ritual

Für interaktive Konten ist eine lange, einzigartige Passphrase zusammen mit MFA und einer Sperrliste bekannter kompromittierter Kennwörter wirksamer als kurze Kennwörter mit erzwungener monatlicher Rotation. Der Grund ist kein Geschmack, sondern Verhalten: Häufige Pflichtwechsel erzeugen vorhersagbare Muster — dasselbe Wort mit hochgezählter Ziffer —, und diese Muster sind für einen Angreifer billiger zu raten als eine lange Passphrase.

Wo Rotation trotzdem richtig istDie Kritik an Rotation gilt für interaktive Konten von Menschen. Für Geheimnisse, die auf Systemen liegen und von Diensten benutzt werden, bleibt regelmäßiger Wechsel richtig — dort gibt es kein Merkverhalten, das darunter leidet, und ein abgeflossener Wert bleibt sonst unbegrenzt gültig. Genau deshalb ist ein verwaltetes Dienstkonto mit automatischer Rotation die bessere Antwort als ein Mensch, der einmal im Jahr ein Kennwort in einer Konfigurationsdatei tauscht.
Was eine Sperrliste leistet, was Komplexitätsregeln nicht könnenKlassische Komplexitätsregeln prüfen die Form eines Kennworts — Groß- und Kleinbuchstaben, Ziffer, Sonderzeichen. Sie können nicht prüfen, ob genau dieses Kennwort bereits in einer öffentlichen Sammlung steht. Sommer2026! erfüllt jede Formregel und ist trotzdem eines der ersten, die ein Angreifer probiert. Eine Sperrliste bekannter und organisationstypischer Begriffe greift genau dort, wo die Formprüfung blind ist — und sie ist der einzige Mechanismus, der ein formal korrektes, praktisch wertloses Kennwort ablehnt.

Lockout ist auch eine Verfügbarkeitsentscheidung

Eine Kontosperrung nach zu vielen Fehlversuchen erschwert das systematische Durchprobieren von Kennwörtern. Sie hat aber eine zweite Seite, die in der Sicherheitsdiskussion oft untergeht: Sie ist ein billiges Werkzeug für einen Angreifer, um Menschen auszusperren.

Schwelle
Wie viele Fehlversuche bis zur Sperre. Niedrig erschwert Raten — und macht das absichtliche Sperren fremder Konten trivial.
Sperrdauer
Wie lange gesperrt bleibt. Automatisches Entsperren nach einer Wartezeit entlastet den Helpdesk, verkürzt aber auch die Wirkung.
Beobachtungsfenster
In welchem Zeitraum die Fehlversuche gezählt werden. Ein kurzes Fenster lässt langsames, verteiltes Durchprobieren durchrutschen.
Die Frage vor der ZahlBevor du eine Schwelle senkst: Wie viele Sperren gibt es heute, und wodurch entstehen sie? In den meisten Umgebungen stammt die Mehrheit nicht von Angriffen, sondern von zwischengespeicherten alten Kennwörtern in Mailprogrammen, Telefonen und geplanten Aufgaben. Eine niedrigere Schwelle vervielfacht dann die Helpdesk-Last, ohne einen einzigen Angriff zu verhindern — und die häufigste Reaktion darauf ist eine pauschale Ausnahme, die den Schutz ganz aufhebt.
Der Unterschied zwischen Sperre und UrsacheEine Sperre zu beheben ist trivial; herauszufinden, wer sie ausgelöst hat, ist die eigentliche Arbeit. Die Fehlversuche werden am PDC-Emulator zusammengeführt — dort liegt die vollständige Sicht. Ohne diese Quelle rät man, und die verbreitetste Reaktion auf wiederholte Sperren ist dann, das Konto von der Richtlinie auszunehmen. Damit ist das Symptom weg, die Ursache — ein Gerät mit einem alten Kennwort — läuft weiter und erzeugt sie beim nächsten Konto erneut.

Protected Users: was die Gruppe tatsächlich abschaltet

Protected Users ist eine eingebaute Gruppe, deren Wirkung nicht in Berechtigungen besteht, sondern in Verboten. Wer Mitglied ist, verliert eine Reihe von Verfahren, über die Anmeldedaten üblicherweise abfließen. Auf Seiten des Domain Controllers gilt für Mitglieder:

  • Keine Authentifizierung über NTLM
  • Kein DES und kein RC4 in der Kerberos-Vorauthentifizierung
  • Keine Delegation — weder unbeschränkt noch eingeschränkt
  • Ein TGT mit vier Stunden Lebensdauer, das darüber hinaus nicht erneuert wird

Auf dem Gerät kommt hinzu, dass für Mitglieder keine Klartext-Anmeldedaten für CredSSP und Windows Digest zwischengespeichert werden, der NTLM-Hash nicht vorgehalten wird — und kein Prüfwert für die Offline-Anmeldung angelegt wird.

Voraussetzung, die man vorher prüftDie Beschränkungen auf Seiten des Domain Controllers greifen erst ab der Domänen-Funktionsebene Windows Server 2012 R2. Darunter ist die Gruppenmitgliedschaft eine gefühlte Sicherheit: Sie ist gesetzt, wirkt aber nur teilweise.

Das Verbot von RC4 verdient dabei eigene Aufmerksamkeit, weil es dieselbe Fehlerklasse erzeugt wie eine allgemeine Härtung: Ein Dienst, dessen Konto kein Attribut für unterstützte Verschlüsselungstypen führt, bekommt vom Domain Controller RC4 zugewiesen — und scheitert, sobald RC4 nicht mehr erlaubt ist. Eine RC4-Abschaltung ist deshalb kein Schalter, sondern dieselbe Reihenfolge wie bei NTLM: erst erfassen, welche Konten und Vertrauensstellungen heute noch RC4 aushandeln, diese einzeln auf AES bringen, dann einschränken. Wer zuerst abschaltet, inventarisiert über Störungsmeldungen.

Die Kehrseite: wen du damit aussperrst

Kein Offline-Anmelden mehrWeil kein Prüfwert für die Offline-Anmeldung mehr angelegt wird, kann sich ein Mitglied an einem Notebook ohne Verbindung zum Domain Controller nicht mehr anmelden. Für ein Konto, das ausschließlich am Arbeitsplatz oder per Sprungserver benutzt wird, ist das folgenlos. Für jemanden, der unterwegs arbeitet, ist es ein Totalausfall — und er tritt genau dann ein, wenn keine Hilfe erreichbar ist.
Warum Dienst- und Computerkonten nicht hineingehörenDie Dokumentation sagt es direkt: Konten für Dienste und Computer sollen keine Mitglieder sein. Der Grund ist entwaffnend — die Mitgliedschaft brächte lokal keinerlei Schutz, weil Kennwort oder Zertifikat auf dem Host ohnehin verfügbar sein müssen, damit der Dienst läuft. Man erkauft sich also nichts und riskiert, dass der Dienst an den DC-seitigen Verboten scheitert.
Ein Hinweis für die FehlersucheScheitert etwas an Delegation, prüft man üblicherweise die Kontoeinstellung „Konto ist vertraulich und kann nicht delegiert werden“. Bei einem Mitglied von Protected Users kann diese Einstellung ungesetzt sein und die Delegation trotzdem scheitern — das Verbot kommt aus der Gruppenmitgliedschaft. Beides gehört geprüft, sonst sucht man an einem Schalter, der gar nicht der zuständige ist.

Authentication Policies und Silos

Wo Protected Users eine feste Liste von Verboten mitbringt, sind Authentication Policies der einstellbare Weg: Sie legen unter anderem die TGT-Lebensdauer fest und können Bedingungen an die Anmeldung knüpfen — etwa, von welchen Geräten aus ein Konto sich überhaupt authentifizieren darf.

Authentication Policy Silo — Ein Container, der zusammengehörige Konten, Computer und Dienste bündelt und mit Richtlinien verknüpft. Ein Silo kann erzwingen, dass sich seine Konten nur an Systemen desselben Silos anmelden — und umgekehrt, dass diese Systeme nur Konten des Silos akzeptieren.

Damit wird aus einer organisatorischen Regel — „Tier-0-Konten melden sich nur an Tier-0-Systemen an“ — eine technisch durchgesetzte Grenze. Der Wert liegt genau darin: Ein gestohlenes Tier-0-Credential nützt an einem gewöhnlichen Arbeitsplatz nichts mehr, weil die Anmeldung dort abgelehnt wird.

Die Ticket-Lebensdauer und ihr PreisStandardmäßig setzt der Domain Controller die TGT-Lebensdauer aus der Domänenrichtlinie — üblich sind 240 Minuten maximale Lebensdauer und 240 Minuten maximale Erneuerungsdauer. Eine Authentication Policy kann das für einzelne Konten verkürzen; Protected Users erzwingt vier Stunden ohne Verlängerung. Der Gewinn ist ein kürzeres Zeitfenster, in dem ein gestohlenes Ticket brauchbar ist. Der Preis: Je kürzer die Lebensdauer, desto häufiger muss ein Konto neu zum KDC — bei einem Konto, das langlaufende Aufgaben startet, kann eine Aufgabe mitten im Lauf ihre Berechtigung verlieren. Kurze Lebensdauern gehören deshalb an Menschen, nicht an Automatisierung.
Wie man so etwas einführt, ohne sich auszusperrenSilos haben einen Modus, in dem Verstöße nur protokolliert statt abgelehnt werden. Diese Stufe ist nicht optional: Sie beantwortet, welche Anmeldungen die Regel heute schon verletzen würden — und in der Regel ist mindestens eine dabei, an die niemand gedacht hat. Erst danach wird scharf geschaltet, und zuvor steht ein dokumentierter Notfallzugang, der die Regel bewusst umgeht und dessen Benutzung auffällt.

Dienstidentitäten: die Grenze liegt nicht im Konto

Ein verwaltetes Dienstkonto löst das Problem des von Menschen verwalteten Kennworts: AD erzeugt und wechselt es, niemand kennt es, es steht in keiner Konfigurationsdatei. Die eigentliche Sicherheitsgrenze ist aber eine andere — nämlich die Gruppe, die das Kennwort abrufen darf.

  • Der Kreis der abrufberechtigten Hosts gehört eng gefasst und regelmäßig geprüft — er beantwortet die Frage, wer dieser Dienst sein kann.
  • Die Rechte des Dienstkontos selbst bleiben davon unberührt und gehören getrennt minimiert: Ein verwaltetes Kennwort an einem überberechtigten Konto ist ein gut gesichertes Problem.
  • Kennwort-Rotationsintervalle verwalteter Dienstkonten folgen ihrer eigenen Logik und lassen sich nicht über ein PSO steuern.
Die Prüfung, die selten jemand machtNimm ein beliebiges Dienstkonto aus eurer Umgebung und beantworte zwei Fragen: Wer darf sein Kennwort abrufen, und wo ist das dokumentiert? Wenn die Antwort auf die erste Frage „das müsste ich nachsehen“ lautet, ist die Sicherheitsgrenze faktisch unbekannt. Genau diese Gruppe ist der Ort, an dem sich eine schleichende Ausweitung unbemerkt ansammelt — jemand nimmt für einen Test einen Host auf, der Test endet, der Host bleibt drin.

Durchgerechnet: strengere Regeln für Administratoren

Von der Anforderung zur wirksamen Konfiguration

Szenario

Die Vorgabe lautet: Administrative Konten brauchen längere Kennwörter und eine niedrigere Sperrschwelle als der Rest. Die administrativen Konten liegen sauber in der OU Admin-Konten.

Anforderungen

  • Die strengeren Regeln dürfen ausschließlich die administrativen Konten treffen
  • Das Ergebnis muss je Konto nachprüfbar sein
  • Ein bestehendes Ausnahmekonto soll abweichend behandelt werden

Schritte

  1. Nicht an die OU hängen. Ein PSO lässt sich nicht auf eine OU anwenden. Stattdessen eine globale Sicherheitsgruppe bilden, die genau die Konten dieser OU enthält.
  2. PSO anlegen mit den strengeren Kennwort- und Sperrwerten und es an diese Gruppe binden. Präzedenzwert bewusst und in Sprüngen vergeben, damit später Platz dazwischen bleibt.
  3. Ausnahme sauber lösen: Das abweichende PSO direkt am Benutzerobjekt verknüpfen — direkt zugewiesen schlägt jede Gruppenzuweisung, ohne dass an den Präzedenzwerten gedreht werden muss.
  4. Ergebnis prüfen: msDS-ResultantPSO an je einem Konto aus beiden Fällen abfragen. Erst diese Ausgabe belegt, welche Regeln tatsächlich gelten.
  5. Den Drift einplanen: Wer künftig ein Konto in die OU verschiebt, ist damit nicht automatisch in der Gruppe. Diese Kopplung braucht einen Prozess oder eine wiederkehrende Prüfung — sonst entstehen Administratorkonten mit den Regeln für alle.

Merksatz: Die Struktur, die für Delegation und Richtlinien trägt — die OU —, trägt für Kennwortrichtlinien nicht. Wo zwei Strukturen dieselbe Menge beschreiben sollen, entsteht Pflegeaufwand; ihn zu benennen ist Teil des Entwurfs, nicht ein Versäumnis.

Prüf dich selbst, bevor es zählt

Kurzcheck

Ein Kollege will die administrativen Konten in Protected Users aufnehmen. Darunter sind auch zwei Dienstkonten und die Konten von zwei Außendienst-Administratoren mit Notebooks. Was hältst du dagegen?

  • Nichts — die Gruppe ist genau für privilegierte Konten gedacht, je mehr darin sind, desto besser.
  • Dienstkonten gehören laut Dokumentation nicht hinein, und die Notebook-Konten könnten sich offline nicht mehr anmelden.
  • Die Gruppe wirkt nur, wenn zusätzlich für jedes Konto ein PSO mit passender Ticket-Lebensdauer angelegt wird.

Treffer. Richtig. Für Dienst- und Computerkonten bringt die Mitgliedschaft keinen lokalen Schutz, weil das Geheimnis auf dem Host verfügbar sein muss. Und ohne Prüfwert für die Offline-Anmeldung scheitert die Anmeldung ohne Verbindung zum Domain Controller.

Damit stehen die Achsen: Domänenrichtlinie, PSO und Lockout als drei getrennte Hebel, die Zielbeschränkung von PSOs auf Benutzer und globale Gruppen, die Präzedenzregel samt ihrem willkürlichen Tiebreak, Lockout als Verfügbarkeitsentscheidung, `Protected Users` mit seinen Verboten und seiner Kehrseite, Authentication Policies und Silos als einstellbare Grenze und die Abrufgrenze verwalteter Dienstkonten.

Gleich im CheckIn den folgenden Entscheidungen wählst du für konkrete Situationen selbst — mehrfach geht es dabei darum, eine Einschränkung einzuführen, ohne den Betrieb oder dich selbst auszusperren.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →
Quellen & Aktualität25 Primärquellen · zuletzt geprüft:
  1. 01learn.microsoft.com/en-us/previous-versions/wi…008/cc770842(v=ws.10
  2. 02learn.microsoft.com/en-us/windows-server/ident…e-protected-accounts
  3. 03learn.microsoft.com/en-us/windows-server/secur…ce-accounts-overview
  4. 04learn.microsoft.com/en-us/windows-server/ident…tand-security-groups
  5. 05learn.microsoft.com/en-us/windows-server/secur…hentication-overview
  6. 06Microsoft Learn — Fine-grained password policies (resultant PSO and precedence)
  7. 07Microsoft Learn — Fine-grained password policies apply to global security groups and users
  8. 08NIST SP 800-63B — Memorized Secret Verifiers
  9. 09Microsoft Learn — Microsoft Entra Password Protection
  10. 10Microsoft Learn — Account lockout policy
  11. 11NIST SP 800-63B — throttling and memorized secrets
  12. 12Microsoft Learn — Group Managed Service Accounts overview and password retrieval
  13. 13Microsoft Learn — Group Managed Service Accounts
  14. 14Microsoft security guidance — least privilege
  15. 15Microsoft Learn — Authentication Policies and Authentication Policy Silos (audit/enforcement)
  16. 16Microsoft Learn — Kerberos encryption types and RC4 deprecation guidance
  17. 17Microsoft Learn — Kerberos policy settings
  18. 18Microsoft Learn — Authentication Policies TGT lifetime
  19. 19Microsoft Learn — Fine-grained password policies
  20. 20Microsoft Learn — Authentication policy silos restrict high-privilege credentials
  21. 21Microsoft security guidance — enterprise access model
  22. 22Microsoft Learn — Authentication policy silos audit and enforce
  23. 23Microsoft guidance — privileged access rollout
  24. 24Microsoft security guidance — emergency access accounts
  25. 25Microsoft Learn — Authentication policy silos