Kennwortrichtlinie

[tomc 0]

Hallo zusammen,

 

sorry, dass ich als neuer User direkt Leichenfledderei betreibe, aber hier passt es einfach am Besten rein...es ist halt exakt das gleiche Thema. Leider scheint es mir allerdings kein Phantomproblem zu sein, sondern ein reales...

 

Wir haben die Domänenfunktionsebene heute endlich mal auf Windows Server 2008 anheben können (die Kollegen haben sich in meinem Urlaub und während meiner Krankheit nicht dran getraut...). Weiter hoch kommen wir leider nicht, da einer unserer DCs als Zertifizierungsstelle fungiert (Windows Server 2008 x32) und wir diesen nicht in nächster Zeit auf Windows Server 2012 hochziehen können (Inplaceupdate scheidet ja leider wegen x32 aus :mad:).

Grund für die Hochstufung war eigentlich nur, dass wir für eine Organisationseinheit eine eigene Kennwortrichtlinie brauchen.

 

Ich habe mich dann heute durch diverse Anleitungen und Infos dazu gelesen und kam letztlich zu dem Schluss, dass wir ein neues msDS-PasswordSettings Object erstellen müssen. Soweit war das auch kein Problem, die neue Kennwortrichtlinie (PSO) für diese Organisationseinheit ist nach Erstellung dann mit dem Attribut msDS-PSOAppliesTo den Gruppen der Benutzer dieser OU zugewiesen worden. Die DDP ist bisher unverändert mit Maxlaufzeit 42 Tage, Historie 24 Kennwörter, Mindestalter 2 Tage, Komplexität, 6 Zeichen Mindestlänge usw.

Die für diese Benutzergruppen geltende PSO wurde auf Maxlaufzeit 90 Tage, Historie (testweise) 1 Kennwort, Mindestalter (testweise) 0 Tage, Komplexität, 8 Zeichen Mindestlänge eingestellt. Danach habe ich am DC das Kennwort für einen Testbenutzer dieser OU und Gruppe zurückgesetzt (weil es mir einfach nicht mehr bekannt war), mich angemeldet und dann natürlich festgestellt, Ablaufzeit 42 Tage. Soweit ok, war ja Adminseitig am DC gewechselt. Ergo vom Client aus (egal ob Windows XP oder Windows 7) das Kennwort ebenfalls geändert und danach die Ablaufzeit überprüft - und damit fing eigentlich dann meine Odyssee auf der Suche nach dem Fehler an.

 

Ein "net user BENUTZERNAME /domain" gibt mir als Ablaufdatum den 05.06.2014 an = 42 Tage.

Eine Abfrage mit einem Kix-Script hatte ebenfalls 42 Tage ergeben ($LAUFZEIT=@MAXPWAGE)

Ein dsget user "CN=blabla,OU=usw.[...]" -effectivepso gibt mir die von mir erstellte PSO als greifende oder angewendete PSO an. Das lässt sich auch dadurch verifizieren, dass ich das Kennwort weiterhin vom Client aus ändern kann (in der DDP wären ja 2 Tage Mindestalter eingestellt). Erstaunlich finde ich, dass er mir bei einem nur 6 Zeichen langen Kennwort ausgibt, dass ich 8 brauche - also auch da scheint sich was geändert zu haben (eventuell ein Patch seitens MS? Patchlevel des Server-OS ist jedenfalls aktuell).

Schaue ich im AD beim Benutzer in den Attributen, zeigt er mir auch dort an, dass das von mir erstellte PSO gültig ist.

 

Die Frage die ich mir jetzt stelle, die ich aber leider erst nächsten Montag dann prüfen könnte wäre, ob auch das Ablaufdatum falsch angezeigt wird oder ob hier tatsächlich etwas nicht stimmt und vor Allem, warum ich das korrekte Ablaufdatum, sollte die PSO gegriffen haben, nicht abfragen kann. Irgendwo muss die doch für den Benutzer im AD gespeichert sein?!

 

Hat dazu vielleicht noch mal wer eine Idee? Ich bin ratlos und könnte grade vor Wut in den Schreibtisch beißen...gibt es doch nicht, dass MS diesen Wunsch vieler Mittelständler und Großunternehmen damals so beschissen umgesetzt hat! 6 Stunden für eine eigentlich 30 Minuten-Geschichte... :thumb2:

 

Grüße

 

Tom

[Sunny61 804]

sorry, dass ich als neuer User direkt Leichenfledderei betreibe, aber hier passt es einfach am Besten rein...es ist halt exakt das gleiche Thema. Leider scheint es mir allerdings kein Phantomproblem zu sein, sondern ein reales...

Erstell doch bitte einen eigenen neuen Thread. Hier ist es gar nicht gerne gesehen einen so alten Thread auszugraben und fremde Threads kapert man einfach nicht. Danke.

[tomc 0]

Nun, dieser Thread belegt bei einer Google-Suche zu dem Thema einen der ersten Plätze, das Problem ist ein sehr ähnliches (wenn nicht sogar identisch) und mir persönlich haben die Hinweise in diesem Thread schon mal sehr weitergeholfen, den Fehler einzugrenzen bzw. die Tatsachen zu überprüfen. Warum sollte ich also einen neuen Thread erstellen und was hat das mit kapern zu tun? Ich übernehme diesen Thread hier ja nicht, sondern will ihn nur ergänzen.

 

So wie ich das im AD momentan sehe, wird tatsächlich 42 Tage als Kennwortlaufzeit gesetzt (Restlaufzeit des Kennworts dümpelt bei 41D 7h usw. rum). Da kann ich mir einfach nicht vorstellen, dass es sich hier nur um einen Anzeigenfehler handelt, weil tatsächlich alle anderen Einstellungen der PSO greifen und NUR für die maximale Kennwortlaufzeit wohl der Wert aus der DDP herangezogen wird. Und vor Allem - wo sollte dann der echte Ablaufwert im AD gespeichert werden? Dann müsste es dafür ja zwei Datenfelder geben - für den gleichen Zweck?!

[Dr.Melzer 191]

Werter tomc, ich verstehe deine Überlegung dazu warum es durchaus Sinn machen kann einen alten Beitrag mit einem neuen Problem zu kapern.

 

Aus unserer Sicht macht das kapern von Beiträgen die ganze Sache aber sehr unübersichtlich weshalb wir für unser Form entschieden haben es nicht zuzulassen.

 

Deswegen habe ich deine frage auch von dem gekaperten thread abgetrennt.

 

Damit den helfenden klar ist was du schon gemacht hast und auf welchen thread du dich beziehst ist hier der Link dazu: http://www.mcseboard.de/topic/169878-kennwortrichtlinie

 

Ich hoffe so dir dir und uns geholfen. :)

[RobertWi 81]

Moin,

 

in diesem Fall wäre es mal sinnvoller gewesen, den Thread nicht zu teilen, weil im letzten Post des anderen Threads auch die Antwort zu diesem "Problem" hier besteht. Es ist  nämlich nur ein Anzeigeproblem:

 

Unglaublich, genauso ist es.... Die PSO greift nur die Anzeigen unter XP/2003 etc. sind die aus der DDP. *wuahhhaaa*

 

 

Erklärung: Das Ablaufdatum wird nicht gespeichert, es wird beim Login berechnet. Überleg Dir mal, wie umständlich das bei Änderungen an der DDP wäre, dann müssten alle Konten angefasst und berechnet werden und bei Replikationsverzögerungen würde es eventuell lange dauern, bis die Änderung bei den Konten ankommt. Viel sinnvoller ist es, einfach nur beim Login zu überprüfen und dann zu reagieren.

 

(lastLogonTimestap - pwdLastSet) > MaxPasswordAge = Password expired

 

Dabei wird dann noch userAccountControl beachtet, ob das Kennwort überhaupt abläuft, usw.

 

Die von Dir oben genannten Tools berechnen daher vermutlich einfach nur die Anzeige falsch.

[tomc 0]

Naja, komisch ist, dass als Ablaufdatum eben der 05.06.2014 angezeigt wird - das entsprach bei der Änderung am 24.04.2014 eben exakt den 42 Tagen, die in der DDP eingestellt sind.

Das wird mir auch immer noch angezeigt, wenn ich den net user BENUTZERNAME /Domain eintipper:

Letztes Setzen des Kennworts: 24.04.2014 16:44:19 Uhr

Kennwort läuft ab 05.06.2014 16:44:19

Kennwort änderbar 26.04.2014 16:44:19

 

Mir fällt jedoch grade auf, dass der letzte Punkt nicht korrekt ist. Das Kennwort konnte direkt nach der Änderung wieder geändert werden. Somit hast du offenbar Recht und die Anzeige ist einfach nicht korrekt. Die Theorie bestätigt auch mein Kix-Script, welches mir weiterhin bei Ausführung heute eine Restlaufzeit von 42 Tagen anzeigt.

 

Mir bleibt hier wohl nichts anderes übrig als zu beobachten, wie sich das Kennwort vom Testbenutzer am 06.06.2014 verhält. Ist es dann noch gültig, klappt alles - wenn nicht, dann weiß ich sicher, dass es nicht funktioniert hat.