tomc

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.

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?!

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