Mehrere Kennwortrichtlinien mit Server 2008 - Password Settings Objects (PSO)
[basiert auf Wissen zu Windows Server 2008 RC0 – Einstellungen und Menüs können sich zum RTM noch ändern!]

Verfasser: Florian Frommherz


Active Directory hat bis einschließlich Windows Server 2003 die Einschränkung, nur eine einzige für die ganze Domäne gültige Passwortrichtlinie definieren zu können. Eine Passwortrichtlinie wirkte somit für alle Benutzer in der Domäne verbindlich – Ausnahmen, um für weitere Benutzer andere Einstellungen definieren zu können gab es nicht. Das war ziemlich einschränkend, zumal man sicherlich für einige Benutzergruppen andere Richtlinien vergeben möchte als für den Rest des Unternehmens. Ausweg waren bisher nur 3rd-Party-Tools die dieses "Feature" nachrüsten können oder die Aufsplittung eines Unternehmenszweiges in eine zusätzliche Domäne.

Mit Windows Server 2008 hat sich Microsoft endlich dazu bewegen lassen, dieses Feature von "Haus aus" mitzuliefern. "Password Setting Objects" heißen die Passwortrichtlinien jetzt, die auf Benutzer, globale Gruppen und iNetOrgPerson-Objekte im Active Directory "gelinkt" werden können. Wer sich den Namen genauer angeschaut hat, wird feststellen, dass es sich jetzt nichtmehr um "Richtlinien" ("Policies"), sondern um Passwort-Objekte ("objects") handelt. Ebenfalls sei hier erwähnt, dass die neuen PSOs nicht, wie schon in Newsgroups zu lesen war, auf Organisationseinheiten (OUs) anwendbar sind. Lediglich Benutzer, globale Gruppen und iNetOrgPerson-Objekte können verwendet werden.

Da ich mich zu diesem Thema auch informieren wollte, habe ich mir eine VM geschnappt, Windows Server 2008 RC0 (Englisch) installiert und das Ganze mal getestet. Zuerst eine Standard-AD-Installation, neuer Forest, neue Domäne: lab.frickelsoft.net soll sie heißen. Ich erstelle mir eine Testbenutzer und die globale Gruppe "salesGuys" in der der Benutzer Mitglied ist.

Danach einfach mal in "Active Directory Users and Computers" suchen. Zusätzlich noch die GPMC, ich möchte mal sehen, wo sich die PSOs nun konfigurieren lassen. Doch: negativ, Fehlanzeige. Weder ADUC noch GPMC zeigen mir keine Möglichkeiten auf, wo man die PSOs konfigurieren kann. Vielleicht schau ich mal unter den "Advanced Features" in ADUC:




Zuerst noch nichts. Nach einer Suche dann endlich der richtige Container: "Password Setting Container" unter "System". Ziemlich versteckt, irgendwie. Okay, da ich noch keine PSOs habe, will ich gleich mal eine erstellen, doch ein Rechtsklick auf den Container, sowie ein Rechtsklick auf die "freie Fläche" auf der rechten Seite des Snapins bieten mir keine "New..."-Auswahlmöglichkeit. Hmm... nach ein wenig Ratlosigkeit versuche ich mein Glück mit ADSIEdit.msc, einem Tool mit dem man Lowlevel Active Directory "editieren" kann. Ich browse zum besagten Container und siehe da:




"New"-"Object" bietet sich mir hier als Möglichkeit. Gut, das nehme ich. Es öffnet sich das "Create Object" wizard, in dem ich gleich eine Objektklasse wählen soll. Die einzige Möglichkeit, "msDS-PasswordSettings" sieht gut aus, ich lasse die Einstellung und klicke auf Next.
Danach werde ich nach mehreren Attributen gefragt, die ich zur Objekterstellung ausfüllen muss:




Tabelle: AD Attribute und ihre Erklärung:
Attribute: cn, Unicode String. Das ist der Name für mein PSO. Ich gebe mal "SalesPSO" ein, da ich eine dieses PSO später der globalen Gruppe "salesGuys" zuweisen möchte.
Attribute: msDS-PasswortSettingsPrecedence, Integer Das ist der Wert für die Wichtigkeit oder die "Kosten" des PSOs. Zu den Kosten kommt später noch etwas. Ich gebe hier 5 ein.
Attribute: msDS-PasswordReversibleEncryptionEnabled, Boolean Hier stellen wir ein, ob das Passwort zurückentschlüsselt werden können soll. Mögliche Werte sind hier "false" und "true". Ich entscheide mich für "false", Passworte sollen nicht zurückgerechnet werden können.
Attribute: msDS-PasswordHistoryLength, Integer Hier entscheide ich, wie viele Passworte für die Benutzer meiner salesGuys-Gruppe später gespeichert werden sollen. Ich wähle 10.
Attribute: msDS-PasswordComplexityEnabled, Boolean Möchte ich, dass komplexe Passworte notwendig sind? Hier kann ich wieder nur "false" oder "true" angeben.
Attribute: msDS-MinimumPasswortLength, Integer Wie viele Zeichen sollen die Passworte mindestens lang sein? Ich kann eine Zahl von 0-255 eingeben.
Attribute: msDS-MinimumPasswordAge, Duration Hier muss ich angeben, wie viele Tage, Stunden, Minuten und Sekunden das Passwort mindestens gültig ist, bevor es erneut geändert werden kann. Die Eingabe muss gemäß des Schemas aa:bb:cc:dd erfolgen, wobei aa die Tage, bb die Stunden, cc die Minuten und dd die Sekunden sind. Ich wähle 5 Tage, also gebe ich 05:00:00:00 ein. Ich kann das Feld auch leer lassen, dann gibt es kein Minimumalter.
Attribute: msDS-MaximumPasswordAge, Duration Die Dauer, wie lange das Passwort gültig ist, bevor es endgültig geändert werden muss. Auch hier muss ich eine Zeitdauer wählen. Ich nehme diesmal 42 Tage, auch wieder im aa:bb:cc:dd-Format: 42:00:00:00. Möchte ich keine Maximalzeit angeben, kann ich "(none)" (mit Klammern!) angeben – soll das Passwort nie ablaufen, kann ich "(never)" eingeben.sollen. Ich habe die Auswahl zwischen einer Dauer (aa:bb:cc:dd), keiner Sperrung "(none)" oder einer manuellen Entsperrung durch den Administrator "(never)".
Attribute: msDS-LockoutThreshold, Integer Wie viele Fehlversuche soll ich den Benutzern gewähren, bevor der Account gesperrt wird? 0 – 65535 ist möglich, 0 heißt "unendlich viele".
Attribute: msDS-LockoutObservationWindow, Duration Wie lange sollen Fehlversuche zwischengespeichert werden, bevor der "Fehlversuchscounter" auf 0 zurückgesetzt wird? Hier muss ich wieder eine Duration angeben. Ich nehme 15 Minuten, also: 00:00:15:00
Attribute: msDS-LockoutDuration, Duration Hier kann ich wieder eine Zeitspanne angeben, wie lange die Accounts gesperrt werden

Der Assistent sagt mir nun, dass er alle "mandatory"-Attribute nun von mir abgefragt hat und lässt mich nun auf "Finish" klicken. Doch das möchte ich nicht, weil meine PSO noch keiner Gruppe zugewiesen ist. Ich suche will meine PSO also an eine Gruppe binden. Ich klicke den Button "More Attributes". Im öffnenden Fenster kann ich nun Attribute auswählen, die mir das msDS-PasswortSettings-Objekt zur Verfügung stellt. Unter "Both" kann ich mir im zweiten DropDown alle Attribute anzeigen lassen. Das Attribut "msDS-PSOAppliesTo" sieht sehr vielversprechend aus.





Im Fenster "Edit Attribute" trage ich den Pfad zu meiner Gruppe ein, für die das Passwortobjekt gelten soll, das ist:
CN=salesGuys,CN=Users,DC=lab,DC=frickelsoft,DC=net.
Herausfinden kann ich dies unter den "Properties” meiner globalen Gruppe im "Attribute Editor”, dort ist der DN (distinguishedName) der Pfad, der im Feld "Edit Attribute” eingetragen werden muss.




Fertig, mein Passwortobjekt wirkt auf die Benutzer meiner Gruppe "salesGuys".


In der Einführung habe ich erklärt, dass Passwortobjekte an Benutzer, globale Gruppen und Objekte des Typs "inetOrgPerson" gelinkt werden können.
Was passiert, wenn ein Benutzer mehrere Passwortobjekte verlinkt hat, weil ein Administrator ihm ein PSO direkt verpasst hat, ein zweiter einer globalen Gruppe, in der er Mitglied ist und ein dritter ein zweites PSO direkt an seinen Useraccount verlinkt hat? Das würde ja bedeuten, dass jetzt drei PSOs (zwei direkt an den Benutzer gelinkt und eines an eine globale Gruppe) wirken würde? Werden die PSOs vielleicht verschmolzen und die restriktivsten Einstellungen gewinnen? Nein, dem ist nicht so. In Wahrheit wird immer nur eine PSO für ein Objekt angewendet.

Die Anwendung für einen Benutzer läuft wie folgt ab: Jetzt gibt es mehrere Sachen zu beobachten:
Wenn es mehrere in Frage kommende PSOs gibt, beispielsweise zwei oder mehr direkt an den User oder eine Gruppe gelinkte PSOs, werden sie verglichen. Da nur eine angewendet werden kann, wird geprüft, welche von ihnen den geringeren Preference-Attributwert aufweist. Wir erinnern uns, den Preference-Wert mussten wir bei der PSO-Erstellung angeben. Je kleiner der Wert, desto wahrscheinlicher wird die PSO angewendet. Haben die in Frage kommenden PSOs den gleichen Preference-Wert, wird die PSO mit der kleineren Objekt-GUID angewendet (die GUID ist einmalig!).

Weiterhin haben wir gesehen, dass die Password Policy, die wir in Prä-Windows Server 2008-Zeiten benutzt haben, immer noch vorhanden und äußerst wichtig ist. Wird keine PSO für einen Benutzer gefunden, wird die Password Policy der Domäne angewendet. Es ist also darauf zu achten, dass hier auch eine gewisse Grundsicherheit und Grundeinstellungen gemacht werden.

Zugegeben, das ganze Verfahren mit der Passworterstellung wahnsinnig umständlich. Es ist schon erstaunlich, dass Microsoft für das Erstellen von PSOs kein eigenes Tool zur Verfügung stellen will oder ein GUI-Addon zu ADUC veröffentlichen möchte. Ein Glück, dass es in der Community helle und fleißige Köpfe gibt, die sich diesem Problem annehmen.

Joe Richards [MVP] hat ein Kommandozeilentool auf die Beine gestellt, das Passwordobjekte anlegen kann:
PSOMgr: http://www.joeware.net/freetools/tools/psomgr/index.htm

Auch Christoffer Andersson [MVP] hat ein Tool, allerdings mit grafischer Oberfläche frei zur Verfügung gestellt:
http://blogs.chrisse.se/blogs/chrisse/archive/2007/07/14/fine-grain-password-policy-tool-beta-1-is-ready.aspx

Beide Tools lassen auf einfache Art und Weise, ohne händisches Anlegen von Objekten und eigenem Editieren der Attribute, PSOs erstellen.

Fazit und eigene Gedanken:
Das Feature ist wirklich cool und wird in vielen Unternehmen sicher mit Handkuss begrüsst werden. Endlich hat man als Administrator die Möglichkeit, Benutzergruppen oder einzelnen Benutzern spezielle Passwortanforderungen aufzuzwingen, ohne ein 3rd-Party-Tool bemühen zu müssen. Ein großer Haken ist allerdings, dass PSOs nur in Domänen im Funktionslevel "Windows Server 2008" verwendet werden können, somit Domänencontroller vor Windows Server 2008 ersetzt werden müssen.
Weiterhin muss man bedenken, dass die Password Policy auf Domänenebene immer noch eine wichtige Rolle spielt, da sie für alle Benutzer angewendet wird, die keine PSO zugewiesen bekamen. Dies bietet die Möglichkeit, eine "Mindestpasswortrichtlinie" zu definieren, die für alle Benutzer gilt, für besondere Benutzer die abweichende Konfigurationen benötigen, können/müssen PSOs definiert werden.
Abschließend sollte noch erwähnt werden, dass die Password Setting Objects so, wie sie jetzt in Windows Server 2008 implementiert sind, nicht mehr per Gruppenrichtlinien funktionieren sondern nativ in Active Directory hinterlegt werden.


(c) 2003 - heute, Mark Heitbrink, weitere Informationen unter WebSite-Info\Copyright