27
Windows 2008 Domain Password Policy funktioniert nicht
Windows 2008 Domain Password Policy funktioniert nicht
Ich habe folgende Einstellungen gemacht in einer W2008 Domain.
Standard Richtiline:
-> Computerkonfiguration -> Richtlinien -> Windows Einstellungen -> Sicherheits einstellungen -> Kontorichtlinien
Eingestellt ist:
Komplexitätsanforderungen: Deaktiviert
Kennwortchronik: 6 gesp. Kennwörter
Umkehbare Verschlüsselung. Deaktiviert
Maximales Kennwort Alter: 32 Tage
Kennwort Länge: 8 Zeichen
Minimales Kennwort Alter: 31 Tage
Allerdings wirken die änderungen nicht. Der User muss nie ein Passwort ändern. Es kommt ein paar Tage davor auch nicht die Meldung das sein Passwort abläuft.
2. Frage wie könnte ich nachschauen wieviele Tage noch ein Passwort gültig ist?
Oder mache ich einfach einen überlegungsfehler ist schon eine Zeit her wo ich eine Password Policy definiert habe.
Ich habe folgende Einstellungen gemacht in einer W2008 Domain.
Standard Richtiline:
-> Computerkonfiguration -> Richtlinien -> Windows Einstellungen -> Sicherheits einstellungen -> Kontorichtlinien
Eingestellt ist:
Komplexitätsanforderungen: Deaktiviert
Kennwortchronik: 6 gesp. Kennwörter
Umkehbare Verschlüsselung. Deaktiviert
Maximales Kennwort Alter: 32 Tage
Kennwort Länge: 8 Zeichen
Minimales Kennwort Alter: 31 Tage
Allerdings wirken die änderungen nicht. Der User muss nie ein Passwort ändern. Es kommt ein paar Tage davor auch nicht die Meldung das sein Passwort abläuft.
2. Frage wie könnte ich nachschauen wieviele Tage noch ein Passwort gültig ist?
Oder mache ich einfach einen überlegungsfehler ist schon eine Zeit her wo ich eine Password Policy definiert habe.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 132483
Url: https://administrator.de/forum/windows-2008-domain-password-policy-funktioniert-nicht-132483.html
Ausgedruckt am: 23.12.2024 um 09:12 Uhr
27 Kommentare
Neuester Kommentar
Ich welcher Policy hast du es einstellt? Default Domain Policy? In einer anderen? Ist diese mit einer OU verknüpft? Ob eine Policy übernommen wird oder nicht, kannst du auf dem Client mittels rsop.msc ermitteln. gpupdate /force könnte auch helfen.
Die rsop.msc zeigt genau die einstellung die von der Domäne kommt. Gpupdate habe ich gemacht und es ist die Standard richtiline also Default Domain Policy.
Ich habe allerdings beim Client folgende fehlermeldung nach eingabe von rsop.msc:
Administrative Vorlagen
Folgender Fehler in C:\Windows\inf\aer1028.adm in Zeile 30 aufgetreten: Fehler 64 Die Hilfzeichenfolge wurde mehr als einmal angegeben. Die Datei kann nicht geladen werden.
Ich habe allerdings beim Client folgende fehlermeldung nach eingabe von rsop.msc:
Administrative Vorlagen
Folgender Fehler in C:\Windows\inf\aer1028.adm in Zeile 30 aufgetreten: Fehler 64 Die Hilfzeichenfolge wurde mehr als einmal angegeben. Die Datei kann nicht geladen werden.
2. Frage wie könnte ich nachschauen wieviele Tage noch ein Passwort gültig ist?
Such mal nach 'lockoutstatus.exe'. Gibt es bei Microsoft. Zeigt dir u.a. auch an, wie es um das Passwort eines Users bestellt ist.
Schwarze Grüße,
Tom
Ich habe das nachgeschaut mit dem Tool -> Obwohl lokal wie oben genannt die Einstellungen lokal übernommen worden sind.
Das habe ich mit gpedit.msc Lokal angeschaut -> Die Einstellungen kommen von der Domäne das heisst ich kann diese nicht mehr lokal modifizieren.
Mit dem Tool lockstatus zeigt es an: Max password age for xxdxxxx is 49710 days.
Current password age is 61 days 20 hours 15 min
Password remains valid for 49648 day 10hours 10 min
Das habe ich mit gpedit.msc Lokal angeschaut -> Die Einstellungen kommen von der Domäne das heisst ich kann diese nicht mehr lokal modifizieren.
Mit dem Tool lockstatus zeigt es an: Max password age for xxdxxxx is 49710 days.
Current password age is 61 days 20 hours 15 min
Password remains valid for 49648 day 10hours 10 min
Moin.
Dein Denkfehler könnte sein: die Policy muss auf die Kontendatenbank angewendet werden, welche die Domänenkonten enthält. Diese liegt auf dem DC. Was auf den Clients zieht (rsop.msc) gilt für lokale Konten! Für Domänenkonten ist die Clienteinstellung wurst, allein auf dem DC muss die Kennwortpolicy angewendet werden. Schau also nach, was auf dem DC greift.
Dein Denkfehler könnte sein: die Policy muss auf die Kontendatenbank angewendet werden, welche die Domänenkonten enthält. Diese liegt auf dem DC. Was auf den Clients zieht (rsop.msc) gilt für lokale Konten! Für Domänenkonten ist die Clienteinstellung wurst, allein auf dem DC muss die Kennwortpolicy angewendet werden. Schau also nach, was auf dem DC greift.
Zitat von pworld
Die rsop.msc zeigt genau die einstellung die von der Domäne kommt. Gpupdate habe ich gemacht und es ist die Standard richtiline also Default Domain Policy.
Die rsop.msc zeigt genau die einstellung die von der Domäne kommt. Gpupdate habe ich gemacht und es ist die Standard richtiline also Default Domain Policy.
Kennwortrichtlinien sind Computereinstellungen. Ist der Computer Mitglied der Domäne und gelten die Richtilinien für diesen, so gelten sie für alle User auf diesem Computer, egal ob lokal oder Domäne. Ein lokales Anpassen der Richtlinien (gpedit.msc) ist dann nicht mehr möglich.
gelten sie für alle User auf diesem Computer, egal ob lokal oder Domäne
Falsch, denn Domänenkennwörter liegen nicht auf dem PC sondern auf dem DC.
Es geht hier um Richtlinien für Kennwörter und nicht um die Kennwörter selbst...
Probiers bitte aus, wenn Du's nicht glaubst. Die KW-Richtl. gehört nichtmal in die Def.-Policy, sondern in die DefDom-Policy (wenn es um Domänenkonten geht).
Oben steht doch Default Domain Policy. Außerdem müssen die Richtlinien nicht zwangweise in dieser definiert sein. Denn so würden diese auch für Server gelten, und wer will das schon? Ich habe z.B. eigene OUs/GPOs für Arbeitsplatz-Rechner sowie Laptops, die jeweils eigene Richtlinien besitzen.
Hallo und frohes Neues!
@spytnik
Aus diesem Grund galt (bis 2008 Server das änderte): Für Domänenkonten kann es nur eine Kennwortrichtline pro Domäne geben (nämlich die, die auf dem DC greift - egal ob DDC-Pol, DD-Pol oder Policy xy).
@spytnik
Ich habe z.B. eigene OUs/GPOs für Arbeitsplatz-Rechner sowie Laptops, die jeweils eigene Richtlinien besitzen.
Dem widerspreche ich nicht - man kann für lokale Kennwörter für verschiedene OUs verschiedene Kennwortpolicies definieren - nicht aber für Domänenkonten. Für die gilt die Policy, welche für die DCs greift. Es bringt nichts, am Client rsop.msc zu starten - das sagt Dir nur, wie die lokalen Kennwörter gehandhabt werden. Überlegt bitte: man kann ein Dom.-Kennwort nur ändern, wenn eine Verbindung zum DC besteht - denn DORT wird es abgelegt und DORT wird es gegen die Kennwortrichtlinie geprüft.Aus diesem Grund galt (bis 2008 Server das änderte): Für Domänenkonten kann es nur eine Kennwortrichtline pro Domäne geben (nämlich die, die auf dem DC greift - egal ob DDC-Pol, DD-Pol oder Policy xy).
Jetzt habe ich es kapiert, danke für deine Geduld. Was ich jedoch nicht kapiere: Ich habe in der Default Domain Policy (=Sicherheitseinstellungen für Domänen) lediglich "Kennwort muss Komplexitätsvorraussetzungen entsprechen" deaktiviert. In der Default Domain Controller Policy (=Sicherheitseinstellungen für Domain Controller) ist nichts definiert. Alles andere wird in den entsrpechenden OUs definiert. Warum funktioniert es trotzdem? (Win 2003 R1 - Domäne, nur Domänenkonten).
Sag nochmal genauer - was funktioniert trotzdem? Die Komplexitätsanforderungen werden berücksichtigt, obwohl rsop.msc auf dem DC ansagt, dass sie deaktiviert sind? Kann nicht sein, prüf nochmal.
rsop.msc auf dem DC gibt genau das aus, was in der DDP eingestellt ist: "Kennwort muss Komplexitätsvorraussetzungen entsprechen": deaktiviert. Alles andere ist dort auch nicht definiert.
Die anderen Sachen, wie "Maximales Kennwortalter", sind in den ensprechenden OUs definiert. So ist das max. Kennwortalter auf 0 eingestellt. Laut der obigen Aussage muss jedoch genau diese Einstellung doch in der DDP vorgenommen werden? Es musste bei uns jedoch noch kein Benutzer sein Passwort aufgrund des Alters ändern...
Die anderen Sachen, wie "Maximales Kennwortalter", sind in den ensprechenden OUs definiert. So ist das max. Kennwortalter auf 0 eingestellt. Laut der obigen Aussage muss jedoch genau diese Einstellung doch in der DDP vorgenommen werden? Es musste bei uns jedoch noch kein Benutzer sein Passwort aufgrund des Alters ändern...
Wenn bei den Benutzerobjekten direkt der Haken gesetzt ist "Kennwort läuft nie ab", dann überstimmt dies selbst die Policy der Domäne. Gegeben?
Den Haken setzen wir nicht (Stattdessen wird beim Anlegen eines Benutzers "Kennwort muss bei der nächsten Anmeldung geändert werden" gesetzt.) Ich habe mir die Policies genauer angeschaut und es ist definitiv wie oben beschrieben. Das wundert mich doch, denn hier steht auch, dass es eigentlich nicht funktionieren sollte: http://www.gruppenrichtlinien.de/HowTo/Kennwortrichtlinien.htm
Von Mark Heitbrink, dem deutschen GPO-Guru schlechthin...
Von Mark Heitbrink, dem deutschen GPO-Guru schlechthin...
@ Der WoWusste
Also muss ich die Einstellungen auf der DomainControllerPolicy machen und nicht in der Default Domain Policy ? Richtig?
Also muss ich die Einstellungen auf der DomainControllerPolicy machen und nicht in der Default Domain Policy ? Richtig?
Du kannst (nicht musst) die Einstellungen in der Def.DC-Pol. machen - oder in der Def.Dom.-Pol. - Hauptsache in einer Policy, die auf den DCs angewendet wird.
Also auf den Default Domain Policy funktioniert das leider nicht. Ich werde es mal auf Default Domain Controller Policy anwenden.
Auf Default DC Policy funktioniert das ebenfalls nicht. Leider !
Aber sicher funktioniert das. Mach am DC ein
gpupdate /force /target:computer
und sieh danach mit rsop.msc nach, ob es angewendet wird.
gpupdate /force /target:computer
und sieh danach mit rsop.msc nach, ob es angewendet wird.
Entschuldigung meine Antwort war eher das die Einstellungen nicht wirken.
Das ist ja genau mein Problem.
IM RSOP nach gupate /force oder neustart am Client mit User sind genau die Einstellungen die von der Domäne kommen.
Auch im RSOP auf dem DC bezogen auf Client und User den ich verwende genau die Einstellungen die er haben muss bzw. bekommen hat.
Das ist ja genau mein Problem.
IM RSOP nach gupate /force oder neustart am Client mit User sind genau die Einstellungen die von der Domäne kommen.
Auch im RSOP auf dem DC bezogen auf Client und User den ich verwende genau die Einstellungen die er haben muss bzw. bekommen hat.
Was mir auch aufällt ist wenn ich nach einem Neustart mit Ctr + Alt + Delete drücke dann kann ich ein Passwort einstellen mit mindestens 7 Zeichen die Policy ist ja aber eingestellt auf 8 Zeichen.
Nochmal ganz langsam 
Führe rsop auf dem DC aus. Nicht für den Client oder User, sondern für den DC selbst. Auf den muss es wirken als Computerpolicy.
Wenn mehrere DCs: bei allen DCs.
Führe rsop auf dem DC aus. Nicht für den Client oder User, sondern für den DC selbst. Auf den muss es wirken als Computerpolicy.
Wenn mehrere DCs: bei allen DCs.
Kein Problem 
Interessant !
Obwohl die Policy gesetzt ist kommt auf dem DC nach einem rsop bei den Kenwwort Richtlinien nichts das heisst es sind keine Einstellungen drin. Einstellungen"nicht definiert"
Gpupate /force habe ich davor bereits gemacht.
Interessant !
Obwohl die Policy gesetzt ist kommt auf dem DC nach einem rsop bei den Kenwwort Richtlinien nichts das heisst es sind keine Einstellungen drin. Einstellungen"nicht definiert"
Gpupate /force habe ich davor bereits gemacht.
Seltsam. Erstell bitte eine Policy direkt auf der OU Domain Controllers und verwende die Option "enforce", stell alles dort ein, mach gpupdate /force /target:computer auf dem dc und dann gpresult, um zu sehen, ob die Policy angewendet wurde und dann auch rsop.msc - wreden nun die Einstellungen als übernommen angezeigt?
Hi DerWoWusste
Ich habe das mal gemacht. (obwohl ich das schonmal vorher gemacht hatte) .Das enforce hatte im endeffekt nachdem ich gewisse vorbereitende sachen im AD korgiert und geflickt habe zum schluss gebracht.
Danke !
Ich habe das mal gemacht. (obwohl ich das schonmal vorher gemacht hatte) .Das enforce hatte im endeffekt nachdem ich gewisse vorbereitende sachen im AD korgiert und geflickt habe zum schluss gebracht.
Danke !
