[2000] Password policy wordt niet gewijzigd voor gebruikers*

[Verwijderd]

Het netwerk bestaat uit een PDC en BDC, beiden Win2000 SP4. De clients bestaan uit Windows XP SP2.

Nu is er een security policy gewijzigd waarbij de password lengte en password age zijn aangepast.
Alles lijkt goed te gaan, behalve dat de clients er niet op reageren.

- Als ik op een client gpresult uitvoer, staat Default Domain Policy (hier is de security policy van aangepast) bij de toegepaste groepsbeleidsobjecten
- rsop.msc op de client geeft de nieuwe waarde aan
- net accounts op de client geeft de nieuwe waarde aan

Als ik op de client mijn wachtwoord wijzig, wordt nog steeds de oude policy gehanteerd.

Ik heb ondertussen zo goed als alle policy topics doorgelezen, meestal ging er iets niet goed. Echter lijkt hier alles goed te gaan, en komen de policies op de clients terecht, maar op een of andere manier worden ze niet gebruikt als er een wachtwoord wordt gewijzigd.

Heeft iemand een idee waaraan dit kan liggen?

Alvast bedankt.

[mutsje]

allereerst PDC/BDC komt uit het NT4 tijdperk en is niet meer van toepassing.

Wat heb je precies gewijzigd op in de default domain policy. De password complexity??

Heb je gpupdate /force gedaan op de client?

als je rsop in logging mode doet wat zie je dan?

[Verwijderd]

mutsje schreef op dinsdag 29 januari 2008 @ 12:08:
allereerst PDC/BDC komt uit het NT4 tijdperk en is niet meer van toepassing.

Wat heb je precies gewijzigd op in de default domain policy. De password complexity??

Heb je gpupdate /force gedaan op de client?

als je rsop in logging mode doet wat zie je dan?

Excuses voor de PDC/BDC benaming.

De volgende wijzigingen zijn doorgevoerd in de default domain policy:

Minimum password length
Maximum password age
Minimal password age
Enforce password history
account lockout threshold
reset account lockout after
account lockout duration

gpupdate /force heb ik inderdaad getest, het lijkt ook dat de policy goed doorgevoerd wordt. Rsop in logging mode geeft de nieuwe wijzigingen aan, die kloppen zoals in de default domain policy is gewijzigd.
Echter als je dan op de client met ctrl+alt+delete je wachtwoord wijzigt, wordt de oude policy gehanteerd om een of andere reden.

[sanfranjake]

Ik zou gaan lunchen, en eens kijken of het daarna werkt Deze change kan soms uren duren...

[ Voor 22% gewijzigd door sanfranjake op 29-01-2008 12:55 ]

[Verwijderd]

Deze change is gisterochtend al uitgevoerd.

Wat ik in de userenv.log tegenkom is het volgende:

USERENV(1b4.568) 13:02:43:687 ReadGPExtensions: Rsop entry point not found for gptext.dll.
USERENV(1b4.568) 13:02:43:687 ReadGPExtensions: Rsop entry point not found for dskquota.dll.
USERENV(1b4.568) 13:02:43:687 ReadGPExtensions: Rsop entry point not found for gptext.dll.
USERENV(1b4.568) 13:02:43:687 ReadGPExtensions: Rsop entry point not found for iedkcs32.dll.
USERENV(1b4.568) 13:02:43:687 ReadGPExtensions: Rsop entry point not found for scecli.dll.
USERENV(1b4.568) 13:02:43:687 ReadGPExtensions: Rsop entry point not found for gptext.dll.USERENV(1b4.568) 13:02:43:687 ReadExtStatus: Reading Previous Status for extension
USERENV(1b4.568) 13:02:43:703 ReadStatus: Read Extension's Previous status successfully.

Daarna lijkt alles goed te gaan. Zou het probleem in bovenstaande kunnen liggen? Zoeken op deze fout, krijg ik vooral topics waar men rechten verkeerde heeft ingesteld, door bv authenticated users geen lees/execute policy rechten te geven. Dat lijkt bij mij niet het geval te zijn.

[sanfranjake]

Zijn beide dc's ook goed in sync met elkaar? Servers al eens een reboot gegeven? Password-policy is iets wat ik na het inrichten van een netwerk liever niet meer verander....

[Verwijderd]

sanfranjake schreef op dinsdag 29 januari 2008 @ 13:32:
Zijn beide dc's ook goed in sync met elkaar? Servers al eens een reboot gegeven? Password-policy is iets wat ik na het inrichten van een netwerk liever niet meer verander....

DC's zijn goed gesynced. Servers hebben geen herstart gekregen. Helaas hebben we geen keus wat betreft het wijzigen van de password policy (beleid van het moederbedrijf)
Als ik op een client de password policy bekijk, dan lijkt het wel doorgevoerd te zijn. Maar de clients maken er geen gebruik van oid.

Wijzigen van andere policies die rechtstreeks aan een OU gekoppeld zijn, hebben wel direct het gewenste effect.

[sanfranjake]

En bij nieuwe users? En als je het vinkje "must change password at next logon" zet in de AD? Ik zou toch eens een reboot van minimaal 1 dc overwegen Override van settings ook niet toevallig geblokkeerd voor de dc's? Of op de pc's lokaal ook een password-policy geconfigureerd met gpedit.msc welke nu overruled?

[Verwijderd]

Probeer eens een andere policy aan te passen, dan gpupdate /force op de server en de client. Bijvoorbeeld lockout policy op 10 zetten. En dan 10 keer je wachtwoord verkeerd intikken met een domain user account om te kijken of deze policy wordt doorgevoerd.

Welke policy werkt er precies niet naar jou idee? Als je met rsop.msc en gpresult de juiste waardes terugkrijgt (test je dit terwijl je ingelogd bent met het betreffende account op de client?), dan moet het goed zijn.

[Verwijderd]

sanfranjake schreef op dinsdag 29 januari 2008 @ 13:46:
En bij nieuwe users? En als je het vinkje "must change password at next logon" zet in de AD? Ik zou toch eens een reboot van minimaal 1 dc overwegen Override van settings ook niet toevallig geblokkeerd voor de dc's? Of op de pc's lokaal ook een password-policy geconfigureerd met gpedit.msc welke nu overruled?

Ik heb net een nieuwe gebruiker aangemaakt. Wijzigen van het password mag nog steeds aan de oude policy voldoen. Reboot van de DC zal dit weekend gebeuren, echter vind ik het vreemd dat ik de nieuwe policy wel terugvind in de clients. Dus ik vraag me af of de reboot zal helpen.

Als ik gpedit.msc uitvoer op een client, kom ik daar bij de wachtwoordinstellingen, dezelfde instellingen tegen als de nieuwe default domain policy instellingen (ze lijken dus wel doorgevoerd te zijn)

Probeer eens een andere policy aan te passen, dan gpupdate /force op de server en de client. Bijvoorbeeld lockout policy op 10 zetten. En dan 10 keer je wachtwoord verkeerd intikken met een domain user account om te kijken of deze policy wordt doorgevoerd.

Welke policy werkt er precies niet naar jou idee? Als je met rsop.msc en gpresult de juiste waardes terugkrijgt (test je dit terwijl je ingelogd bent met het betreffende account op de client?), dan moet het goed zijn.

gpupdate /force zal ik niet op de server doen, aangezien dit een herstart vereist. De default domain policy is degene die niet werkt op de client. Deze zit gekoppeld aan het domein, waar alle OU's onder hangen.
Het uitvoeren van gpresult en rsop.msc voer ik uit op een client die ingelogd is in het domein.
Het rare is dan ook, dat ik overal de nieuwe instellingen van de policy terugvind. Maar als ik dan mijn wachtwoord op de client ga wijzigen, hij de oude policy hanteerd.

Als ik het wachtwoord dan wijzig in een wachtwoord dat niet aan de oude eisen voldoet, komt de popup dan ook met de volgende melding

"Het opgegeven wachtwoord voldoet niet aan de minimum complexiteits eisen etc. etc. etc.
het wachtwoord is tenminste 6 tekens lang etc etc etc"

minimumpassword lengte oude policy = 6
minimumpassword lengte nieuwe policy = 8

In rsop.msc en gpedit.msc op de client staat de minimum password lengte op 8.

Dus waar de clients nog steeds de oude policy vandaan halen is mij een raadsel. Misschien ergens uit het register oid?

[_H_G_]

Stomme vraag wellicht, maar de clients al herstart?

[Verwijderd]

_H_G_ schreef op dinsdag 29 januari 2008 @ 14:51:
Stomme vraag wellicht, maar de clients al herstart?

Clients uiteraard meerdere malen herstart, met andere gebruikers ingelogd. profiles weggegooit. Enige wat ik nog niet heb geprobeerd is een computer account weggooien in AD, en opnieuw aanmaken (wat ik nu ga proberen)

[sanfranjake]

De password policy voor clients wordt ook bijgehouden op de dc. Users en computers zijn immers objecten in de AD. Omdat een niet-dc ook lokale accounts kent werkt de password-policy hier ook op door, dat gaat wel goed, waarschijnlijk omdat die XP of hoger zijn, of al gereboot.

Windows 2000 was heel inflexibel met dit soort policies. Op 2003 kan het ook uren duren, talloze gpupdate /force's voordat wijzigingen in password policies actief zijn. Ik zou toch echt de servers (1 voor 1) rebooten voordat je verder gaat troubleshooten.

[Verwijderd]

Ok, bedankt voor de informatie. De servers hebben een scheduled reboot aankomende zaterdag, deze zal ik dan afwachten voordat ik verder op zoek ga.

PS. opnieuw aanmaken van een computeraccount voor de client heeft niets opgeleverd.

Ik hou jullie op de hoogte wat voor resultaat de reboot heeft.

[Verwijderd]

Verwijderd schreef op dinsdag 29 januari 2008 @ 14:42:


gpupdate /force zal ik niet op de server doen, aangezien dit een herstart vereist.

Vereist geen herstart hoor. Als je maar 2 domain controllers hebt, heb je waarschijnlijk een kleinere omgeving (tot 300 users), en hoeft het normaliter geen uren te duren voordat een wachtwoord policy gewijzigd wordt, tenzij de synchronisatie tussen deze 2 niet lekker loopt. Moet je wel even een gpupdate /force doen op de servers inderdaad. Of secedit /refreshpolicy machine_policy /enforce.

[ Voor 48% gewijzigd door Verwijderd op 29-01-2008 20:56 ]