Setzt man Password Setting Objects (kurz PSOs) auch bekannt als fein abgestimmte Kennwortrichtlinien ein, kann es zu Verwirrungen bei der Meldung die Windows liefert kommen, wenn ein Benutzer ein Kennwort vergeben möchte das nicht den Vorgaben des ihm zugewiesenen PSO entspricht.


Welche Voraussetzungen existieren müssen damit PSOs eingesetzt werden können oder wie PSOs konfiguriert werden, steht neben weiteren Details im folgenden Artikel:


Password Setting Objects erstellen und verwalten



Damit man nicht aufs Glatteis durch die von Windows erzeugte Meldung geführt wird und um PSOs erfolgreich zu implementieren, hier ein paar wichtige Hinweise:



  • Versucht ein Benutzer auf den ein PSO verlinkt wurde, auf einem Windows XP Client oder Windows Server 2003 sein Kennwort zu ändern, erhält er diese Meldung:




    In diesem Fall hat der Benutzer erfolglos versucht sein Kennwort zu ändern. Das neue Kennwort entsprach nicht den Vorgaben aus dem PSO. Daher ist es folgerichtig, dass eine Meldung erscheint. Allerdings stammen die Kennwort-Anforderungen in dem Dialogfenster aus der Domänenrichtlinie Default Domain Policy, die auf Domänenebene verlinkt ist! Die Meldung hat sich leider mit Einführung von PSOs nicht verändert. Es erscheint kein eigenes Dialogfenster, in dem die Kennwortvorgaben des PSO enthalten sind!


  • Versucht der Benutzer auf einem Windows 7 Client oder Windows Server 2008/R2 sein Kennwort zu ändern, erhält er bei nicht Einhaltung der Kennwortvorgaben aus dem PSO diese Meldung:




    Auch diese Meldung ist irreführend, denn es wird auf die Kennwortrichtlinie der Domäne, also auf die Default Domain Policy verwiesen, in der standardmäßig die Kennwortvorgaben auf Domänenebene definiert sind. Eine andere Meldung mit den Kennwortvorgaben der PSO erscheint weiterhin nicht!


  • Versucht der Administrator, das Kennwort eines Benutzers auf den ein PSO verlinkt wurde zu ändern, erscheint diese Meldung:




    Diese Meldung ist ebenfalls trügerisch, denn angeblich entspricht das neue Kennwort nicht den Anforderungen der Kennwortrichtlinien. Abgesehen davon das es sich bei dem PSO nicht um eine Kennwortrichtlinie sondern um ein AD-Objekt handelt, erscheint einmal mehr kein Hinweis auf das PSO!



  • Führt man auf dem Client unter Start – Ausführen das Resultant Set of Policy (RSoP) aus, werden dort die Kennwortvorgaben wieder aus der Default Domain Policy angezeigt! Daher bringt ein RSOP.msc für die Überprüfung eines PSO nichts! Denn da es sich bei den PSOs nicht um Gruppenrichtlinien (GPOs) handelt, werden diese auch nicht im RSOP angezeigt.

    Und abgesehen davon ist RSOP.msc zum Überprüfen von GPOs nicht mehr State oft the Art und sollte ab Windows 7 und Windows Server 2008 R2 auch nicht mehr verwendet werden. Besser ist es in der Kommandozeile diesen Befehl zu verwenden: GPResult /h GPO-Report.html.


  • PSOs dürfen erst erstellt werden, wenn sich der Domänenfunktionsmodus bereits im Modus Windows Server 2008 oder höher befindet. Wenn PSOs erstellt werden bevor sich der Domänenfunktionsmodus mindestens in der Ebene Windows Server 2008 befindet, werden diese auch nach dem Hochstufen nicht angewendet!


  • Ob und welches PSO auf einen Benutzer verlinkt ist, sollte mit dem Kommandozeilenbefehl dsget user <DN des Benutzers> -effectivepso kontrolliert werden. Beispielsweise: dsget user ” CN=Yusuf Dikmenoglu,OU=IT,DC=ad2008R2,DC=Dikmenoglu,DC=de” -effectivepso

Comments are closed, but trackbacks and pingbacks are open.