User can't change password due to complexity

Question

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:

1. 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

2. 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.

3. 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.

4. PDC is available

5. Set-ADAccountPassword on a domain controller didn't work either.

6. The security descriptor of the user account looks quite ok. Everyone has the right to change the password.

7. 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.

Solution 1

IIRC the error is the generic error for any password change issue.

Based on your comment of:

This is however not true, when:

a) An Administrator resets to a new password or

b) the user had the flag "must reset passwort at logon"

I'm going to say the issue is that your password policy has a setting for either Minimum Password Age or Enforce Password History or both. Likely the first one is the culprit here.

EDIT:

Based on your latest update you can see:

Password changeable 15.02.2017 13:14:58

It shows that the password isn't changeable for 30 days.

Now, you stated that your Minimum Password Age is set to 0.

That leads me to two possible conclusions:

1. Either the accounts or the OUs are blocking inheritance of the policy...despite it showing the proper policy with "net accounts" the particular user doesn't seem to be getting it applied.

2. There are some DC's that are blocking inheritance and not getting the proper settings. See here: https://community.spiceworks.com/topic/1838052-minimum-password-age-password-changeable

Check and verify that there isn't any GPO blocking done in GPMC. Then check and make sure the DC the user is authenticating against, along with their computer, and their user account...all 3 have "Include inheritable permissions from this object's parent".

Solution 2

Your output of the net user /domain Myuser command is currently reflecting a minimum password age of 31 days. It looks like you need to modify your PSO for this user and set the minimum password age to 0 in that object.

Also, have you confirmed that the PSO was successfully applied to the user or group? If it is, you should see an msDS-ResultantPSO attributed populated on the user's AD account. You can easily check this using ADUC on the attributes tab or by running the following PowerShell commands:

Import-Module ActiveDirectory
Get-ADUser cardm004 -Properties msDS-ResultantPSO | FL

On a side note, running net accounts is going to return the settings for local computer accounts. Local account settings are configured separately from domain account settings.

Comments

[SamErde]

Have you confirmed that the PSO is being applied to the user?

[Kernel Stearns]

Have you verified that the users are actually entering full 'complex' passwords? Just to check, enter something that is like 20 characters long and has a bunch of numbers, uppercase and lowercase, and special characters. Please note, you do have "complexity requirements" enabled in the Group Policy.

[IceMage]

Am I to understand - through the updates - that this could be a delegation issue? Any possible WMI filtering or permissions issues, or local GPO settings? I think running RSoP on the affected users+computers is your next step.

[restless1987]

In the specific domain, there is only complexiy and lenght defined. Aging and history are not configured or appliable in that case. And yes, I checked ;)

[kralyk]

type net accounts on that workstation and see what the real policy is they are receiving.

[Greg Askew]

@restless1987: Aging and history are not configured. How are you validating this?

[restless1987]

I'll update the question

[kralyk]

post the results of net user /domain username where username is one of the affected users.

[restless1987]

See updated question

[restless1987]

I reviewed the password and the full set of user info in AD. Sadly, there is no match in any case. The password contains upper and lower case letters and a set of numbers and is 12 charakters long.

[kralyk]

Updated answer.

[SamErde]

User indicated that they have configured a PSO, which should override the GPO that was previously configured. Inheritance would therefore not be relevant, right?

[kralyk]

@SturdyErde - I figured that was him testing...and that the PSO wasn't the long term fix, but just to check one of the affected users.

[SamErde]

Complexity also requires a special, non alphanumeric character. Did you verify one of those?

[restless1987]

The query returned no PSO.

[SamErde]

The user is not linked to the PSO yet. This obviously doesn't solve your primary issue, but would be worth testing. There are multiple ways to link a user or group to a PSO. One way is to use ADUC, enable Advanced view, and then browse to the domain's \ System \ Password Settings Container. The properties of each PSO has an attribute named "msDS-PSOAppliesTo", which is where you can add users or groups to receive the PSO.

[restless1987]

I verified the PSO / created them by my self. They are not linked to this user or a group that user might be in, sry.