Das Problem
In unserer täglichen Arbeit fällt uns ein weitverbreitetes Missverständnis im Umgang mit Kennwortrichtlinien im Active Directory auf. Hier möchten wir kurz für Klarheit sorgen.
Die Standard-Kennwortrichtlinie wird immer in der Default Domain Policy definiert. Diese ist mit der Domäne verknüpft, gilt somit für alle Benutzerobjekte in der ganzen Domäne.
Es ist grundsätzlich eine gute Idee, abgestufte Kennwortrichtlinien für verschieden privilegierte Benutzertypen durchzusetzen. Nur ist das oft erwartete GPO-Verhalten hier der Ursprung des Missverständnisses. Verknüpfe ich ein Gruppenrichtlinienobjekt (Group Policy Object, GPO) mit einer Organisationseinheit (Organizational Unit, OU), dann wirken dessen Einstellungen nicht mehr domänenweit, sondern nur auf die Objekte in dieser OU. Die Annahme ist nun häufig, dass sich ein Benutzerkreis mit Objekten in einer OU so mit anderen Kennwortrichtlinien versehen lässt. Denn die Einstellungen eines mit einer OU verknüpften GPO überschreiben im Normalfall Einstellungen, die aus der Domäne nach unten vererbt werden.
Konkret wird also häufig folgendes konfiguriert: Administrative Konten werden in einer OU versammelt und mit dieser ein neues GPO, nennen wir es „KWRL-Admins“, verknüpft. Schauen wir uns das Verhalten kurz an. In der Laborumgebung haben wir in der Default Domain Policy eine Mindest-Kennwortlänge von vier Zeichen festgelegt. Das GPO „KWRL-Admins“ an einer OU „Admins“ verlangt fünf Zeichen.
Wir nehmen nun einen Benutzer in der OU und setzen dessen Kennwort auf eines mit vier Zeichen zurück. Wir erfüllen also die Default Domain Policy, nicht aber die „KWRL-Admins“. Was passiert?
Wir sehen also, dass die Kennwortrichtlinie aus dem GPO „KWRL-Admins“ keine Rolle spielt. Es bleibt bei der Grundregel: Kennworteinstellungen gelten immer domänenweit. Das oft gewählte Vorgehen, auch die Kennwörter mittels eines GPO an einer OU zu lösen, funktioniert nicht.
Die Folge des Missverständnisses ist also, dass Richtlinien im fehlgeleiteten Verständnis und guter Absicht erstellt werden, diese aber nie wirken. Weiterer Rat sollte also sein, erstellte GPO immer auf die gewünschte Wirksamkeit zu überprüfen.
Tatsächlich ist das GPO nicht nutzlos – nur bezieht es sich nicht auf Benutzerobjekte innerhalb der OU – es wirkt auf Computerobjekte in der entsprechenden OU und bestimmt dann Kennwortrichtlinien für deren lokale Benutzer. Wir verschieben also ein Computerobjekt in die OU und setzen das Kennwort eines lokalen Benutzers neu – und zwar so, dass es das GPO „KWRL-Admins“ erfüllt:
Es lässt sich zudem beobachten, dass die vom GPO vorgegeben Werte für die lokale GPO des Computers übernommen wurden:
Die Lösung
Wie aber lösen wir jetzt das Dilemma, unterschiedliche Kennwortrichtlinien für verschiedene Benutzergruppen durchzusetzen? HiSolutions empfiehlt (Stand 2025) für eingeschränkte Benutzer eine Mindestlänge von zwölf, für administrative Benutzer eine Mindestlänge von 16 und für Dienstkonten eine Mindestlänge von 24 Zeichen.
Die Lösung heißt: Finegrained Password Policies (FGPP)! Diese basieren auf einem sog. Password Setting Object (PSO) und sind bereits seit Server 2008 verfügbar. FGPP überschreiben die Einstellungen der Default Domain Policy und werden an Gruppen gebunden.
Dementsprechend könnte das Vorgehen sein, die Einstellungen für eingeschränkte Benutzerkonten weiterhin über die Default Domain Policy zu realisieren. Dann legt man Gruppen für administrative Konten und Dienstkonten an und schreibt für diese geeignete FGPP nach folgendem Muster. Entweder erledigt man das im GUI im Active-Directory-Verwaltungscenter oder über die PowerShell.
Fazit:
- Die Kennwortrichtlinien aus der Default Domain Policy gelten immer domänenweit.
- Kennwortrichtlinien aus GPO an OU wirken nicht auf die darin enthaltenen Domänenbenutzer, sondern nur auf darin enthaltene Computer und deren lokale Benutzer.
- Verschiedene Kennwortrichtlinien für verschiedene Benutzergruppen werden über Finegrained Password Policies realisiert.
