[Server2012] GPO Kennwortrichtlinie / Komplexität wirkt nicht

[michelo82 12]

Hallo,

mir ist aufgefallen, dass nach dem manuellen zurücksetzen eines Kennwortes via AD-benutzer u. Computer (ohne den Haken gesetzt zu haben: "Benutzer muss Kennwort bei der nächsten Anmeldung ändern") der Nutzer sein Kennwort nicht selbständig ändern kann. Es erscheit immer wieder beim versuch das Kennwort zu ändern folgendes: "Das Kennwort kann nicht aktualisiert werden. Der Wert, der als neues Kennwort angegeben wurde, entspricht nicht den Kennwortrichtlininen..." u.s.w.

 

Die Kennwortkomplexität ist allerdings deaktivert. Es gab vorher fälscherweise eine eigene Password-Policy GPO die auf die oberste OU der Domäne und nicht auf den Domänen-Header verlinkt war.

Diese habe ich entfernt und die Kennwortrichtline wieder in die Defaul Domain Policy eingetragen. Das bringt mir

PS C:\Users\admin> Get-ADDefaultDomainPasswordPolicy


ComplexityEnabled           : False
DistinguishedName           : DC=meine-firma,DC=org
LockoutDuration             : 00:05:00
LockoutObservationWindow    : 00:05:00
LockoutThreshold            : 6
MaxPasswordAge              : 60.00:00:00
MinPasswordAge              : 40.00:00:00
MinPasswordLength           : 6
objectClass                 : {domainDNS}
objectGuid                  : 267a5d25-0e8d-494e-bf58-e444682f11a4
PasswordHistoryCount        : 5
ReversibleEncryptionEnabled : False

auf beiden DC's.

 

Ich habe den Client und beide DC's bereits neugestartet.

 

Setze ich allerdings den Haken beim manuelle zurücksetzten "Benutzer muss Kennwort bei der nächsten Anmeldung ändern", muss und kann der Nutzer wieder ein eigenes Kennwort vergeben.

 

Im Active-Directory Verwaltungscenter habe ich nichts angepasst. Default wird allerdings folgendes vorgegeben. Das wird ja aber sicher nicht wirken?

 

Kann mir bitte jemand einen Tipp geben, wo es da klemmt? Warum wirkt die Kennwortrichtlinie nicht korrekt?

MfG

bearbeitet 11. Oktober 2016 von michelo82

[Blase 15]

Hallo,

 

Ich kann die Werte bezüglich minimales und maximales Kennwortalter nicht "lesen", sind das 40 Tage?Ich vermute hier aber dein Problem. Setzt du das Kennwort ohne Haken bezüglich "Benutzer muss neu vergeben" gilt halt das minimale Kennwortalter. Also so lange muss das gesetzte Kennwort genutzt werden, bevor es geändert werden darf. Setzt du den Haken, greift das mindest-Kennwortalter nicht und muss/kann gleich geändert werden...

 

Gruß

Björn

[michelo82 12]

Hi, das war schonmal ein guter Ansatz! Danke.

Ja, 40 Tage.

Es klappt aber immer noch nicht. Habe es jetzt auf 0 Tage gesetzt. Am Client gpupdate /force und neugestartet.

 

[Blase 15]

Auch der Server braucht eine kleine Weile, bis er die neuen Richtlinien übernommen hat. Sicher, dass das die einzigen Richtlinien sind, die sich mit dieser Thematik beschäftigen? Evtl. weitere "lokale" Sicherheitsrichtlinien diesbezüglich?

[michelo82 12]

Auch der Server braucht eine kleine Weile

Das war es! Hab nochmal auf beiden DC's gpupdate /force und einen reboot gemacht (wg. Computerrichtlinie). Jetzt geht es! Super Danke :)

[NorbertFe 1.799]

/force ist sowas von überflüssig. Wieso ist jeder der Meinung das verwenden zu müssen? 5 Minuten warten hätte wahrscheinlich auch gereicht, weil das das Backgrouprefreshintervall bei DCs ist.

[blub 115]

/force  - einfach die Macht zu besitzen, es tun zu können :D. Schadet ja auch nicht.

[michelo82 12]

Hat das den in dem Bezug keine Bedeutung?

Wendet alle Richtlinieneinstellungen erneut an.
Standardmäßig werden nur geänderte Richtlinien angewendet.

[NorbertFe 1.799]

Hat sich denn was geändert? Ja. Wird sie angewandt? Ja.

 

Schadet ja auch nicht.

Jain. Es führt im Zweifel dazu, dass man Fehler nicht erkennt, weil man mit /force eben die Anwendung der Gruppenrichtlinien erzwingt. Wenn es bei der normalen Übernahme aber Probleme geben sollte, wird man das nicht "sehen". Und ja, ich hab schon solche Kundensysteme gefunden, bei denen dann eben Startupskripte mit /force liefen usw. usf. Ja es ist im Allgemeinen überflüssig. Und wenn es überflüssig ist, sollte man es eben auch nicht verwenden.

[michelo82 12]

Verstanden! :)

[Sunny61 773]

Ergänzend zu Norbert, ein gpupdate /target:computer oder gpupdate /target:user reicht im Normalfall aus. Bei Computereinstellungen kann ein Neustart nicht schaden, beim User einmal ab- und wieder anmelden.

[NorbertFe 1.799]

Ist aber im Allgemeinen mehr zu tippen, und stört bei einem einfachen gpupdate ja auch nicht. Wenn sich im Userteil nichts geändert hat, wird auch nichts erneut angewandt. ;) Mal von psexec gabs bisher wenig Gründe mittels Target den Bereich einzuschränken.

 

Bin schon wech

Norbert

[Sunny61 773]

Adlersuchsystem braucht länger zum tippen, mir schon klar. :)

[blub 115]

das "/force" nach gpupdate ist bei mir so tief  in die Finger Sehnen und Muskeln eingebrannt, das bekomme ich wohl nie mehr raus. Genauso wie z.B. das "/all" bei ipconfig, auch wenn ich es gar nicht brauche.

 

Mal ehrlich, wer von uns ist so flexibel und hat diese cmd-Klassiker schon aus seinem Repertoire gestrichen und durch modernere, zweifellos mächtigere Befehle ersetzt?

- Invoke-Gpupdate

- https://blogs.technet.microsoft.com/josebda/2015/04/18/windows-powershell-equivalents-for-common-networking-commands-ipconfig-ping-nslookup/

[NorbertFe 1.799]

da ich ab und zu einfach arbeiten will, hab ich keine Lust für ein GPUPdate immer erst auf den Start der Scharch-Shell zu warten. ;)