At one of my customer's child domains, he has the problem that a number of (looks like) random users can not change their password due to "complexity blah blah". This is however not true, when:
a) An Administrator resets to a new password or
b) the user had the flag "must reset password at logon"
What I tried so far:
GPOs: There is only the default domain policy with password settings in it. The settings are:
- Length of 10
- Complexity enabled
- history is set to 5, but irrelevant in this case (tried different passwords)
- Everything else is undefined or 0
Password provider on PDC: I read that you can use custom password providers via registry. I checked it with a domain where everything works. It seems default. Only thing I saw was the setting
EveryoneIncludesAnonymous = 0
.The user still could not change his PW after I created a PSO for him, with config that should work. Seemed like they were not applied.
PDC is available
Set-ADAccountPassword
on a domain controller didn't work either.The security descriptor of the user account looks quite ok. Everyone has the right to change the password.
In ADUC the user properties are ok. User can not change password = $false, etc.
Output of net user /domain Myuser
User name cardm004
Full Name Cardman, Michael
Comment Test User
User's comment
Country/region code 000 (System Default)
Account active Yes
Account expires Never
Password last set 16.01.2017 13:14:58
Password expires Never
Password changeable 15.02.2017 13:14:58
Password required Yes
User may change password Yes
Workstations allowed All
Logon script login.cmd
User profile
Home directory
Last logon 18.01.2017 08:14:01
Logon hours allowed All
Local Group Memberships
Global Group memberships *Domain Users
The command completed successfully.
Output of net accounts
Force user logoff how long after time expires?: Never
Minimum password age (days): 0
Maximum password age (days): 37201
Minimum password length: 10
Length of password history maintained: 5
Lockout threshold: Never
Lockout duration (minutes): 30
Lockout observation window (minutes): 30
Computer role: Workstation
I'm out of ideas now. What could I try to find out why the users cannot change their passwords?
Update
I found out, that group policy modeling shows different configurations for different users. The part "password settings" and "account lockout policy" are not shown for the users that can't change their passwords. So I assume, that there might be a replication issue on the domain controllers. I checked the replicationstatus with repadmin /showrepl
and the results were ok. I checked the file contents in sysvol on all 3 domain controllers and they where identical. So somehow, DCs are up to date, but the computers do not get the configuration.
GPUpdate /force
and GPResult /r
, or GPResult /h file.html
look good and do not show any errors. Reboot after GPUpdate /force
did not change the error.
GPResult /r
shows the correct site, and displays a fast connection, Default Domain Policy
(where the settings are done) is displayed as applied.
Update 2
I created an additional GPO to set the password settings. For that I created an OU, where I moved the computer and the user account to and linked that GPO with enforced = $true
to that OU. GPResult /h
shows the correct applied configuration, Net user /domain testuser
does not. The local policy settings are identical to the GPO.
The problem still occurs.
Update 3
The customer opened a ticket at microsoft. They do not have a solution yet, but found out, that there seems to be a issue with GP: The user and his device got moved into a separate OU for testing with inheritance disabled. They applied a new GPO to it with several password settings. GPResult
showed the updated settings, but the user was still unable to change his password.
Then, they removed the GP-link and enabled inheritance again, the settings of the test-GPO stayed on the system. The settings of Default Domain Policy were not applied (they were lower than in the test GPO) and the user could still not change his password.
I'll keep you updated, maybe one of you runs into this issue one day, or finds a solution before microsoft does.