Fine Grained Password Policies (FGPP) - Password Settings Objects (PSO)
(Aktualisierung, Textänderungen durch Mark Heitbrink)
Seit Jahren gibt es den Wunsch unterschiedliche Kennwortrichtlinien in einem AD zu verwenden. Der klassische Fall ist ein Produktionsbereich der keine Kennworte erlaubt aber in der Verwaltung sollten Kennworte zum Einsatz kommen.
Jetzt gibt es seit Server 2008 die Password Settings Object und die Fine Grained Password Policies. Das sind KEINE! Richtlinien, sondern nur Objekte, die für ein erstelltes Objekt im AD verwendet werden können. Eine echte KENNWORTRICHTLINIE ist aber schon gültig, wenn das noch Objekt erstellt wird, noch keine SID hat und nicht erst, wenn es eine SID hat. Das ist technisch ein Unterschied.
PSOs können nur auf Benutzer, Sicherheitsgruppen oder iNetOrgPerson-Objekte angewendet werden.
Zur Verwaltung der PSOs kann ich erneut Specops empfehlen
Das Tool regelt alles, was ihr per Hand bauen könnt.
- adsiedit.msc öffnen
- Ansicht auf "Erweitert" stellen
- Default Naming Context
- -> System
- -> Password Settings Container
- -> rechte Maustaste "Neu"
- -> "msDS-PasswordSettings"
Die Attribute müssen per Hand erstellt und eingetragen werden:
| Attribute: cn, Unicode String. | Das ist der Name für das PSO. |
| 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. Wir geben 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". Wir verwenden "false" |
| Attribute: msDS-PasswordHistoryLength, Integer | Wie viele Passworte für die Benutzer meiner Gruppe sollen später gespeichert werden: 10. |
| Attribute: msDS-PasswordComplexityEnabled, Boolean | Sind 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äss des Schemas aa:bb:cc:dd erfolgen, wobei aa die Tage, bb die Stunden, cc die Minuten und dd die Sekunden sind. Für 5 Tage: 05:00:00:00. Bei keiner Angabe 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. Soll das Passwort nie ablaufen, kann ich "(never)" eingeben. |
| Attribute: msDS-LockoutThreshold, Integer | Wie viele Fehlversuche soll ich den Benutzern gewähren, bevor der Account gesperrt wird? 0 ? 65535 ist möglich, 0 heisst 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 meldet, dass er alle "mandatory"-Attribute abgefragt hat und lässt mich nun auf "Finish" klicken.
Wir haben das PSO noch keiner Gruppe zugewiesen.
- -> "More Attributes".
- -> "Both" im zweiten DropDown alle Attribute anzeigen lassen.
- -> Das Attribut "msDS-PSOAppliesTo" wählen
- -> "Edit Attribute" , Distinghuished Name der Gruppe ein, für die das Passwortobjekt gelten soll, das ist: z.B.: CN=salesGuys,CN=Users,DC=meineDom,DC=dom
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:
Ist mindestens eine PSO direkt an den Benutzer gelinkt?
-> Nein: prüfe die Gruppen.
-> Ja: beende die "Suche" und wende die PSO an.
Ist mindestens eine PSO an eine Gruppe gelinkt, in der der Benutzer Mitglied ist?
-> Nein: wende keine PSO an; wende die Default Domain Password Policy an.
-> Ja: beende die "Suche" und wende die PSO an.
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.
Deswegen noch einmal: Specops Password Policy Basic (Free)
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.