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?


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.

  • Have you confirmed that the PSO is being applied to the user?
    – Sam Erde
    Jan 18, 2017 at 18:51
  • 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.
    – B00TK1D
    Jan 18, 2017 at 19:15
  • 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.
    – IceMage
    Jan 20, 2017 at 20:03

4 Answers 4


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.


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

  • 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 ;) Jan 16, 2017 at 18:36
  • type net accounts on that workstation and see what the real policy is they are receiving.
    – TheCleaner
    Jan 16, 2017 at 19:59
  • @restless1987: Aging and history are not configured. How are you validating this?
    – Greg Askew
    Jan 16, 2017 at 21:53
  • I'll update the question Jan 17, 2017 at 7:01
  • post the results of net user /domain username where username is one of the affected users.
    – TheCleaner
    Jan 17, 2017 at 14:56

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.

  • The query returned no PSO. Jan 25, 2017 at 8:20
  • 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.
    – Sam Erde
    Jan 26, 2017 at 16:18
  • 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. Jan 26, 2017 at 18:20

Stupid suggestion, but does you have verified that the user's password meets the requirements:

  1. Passwords must not contain the user's entire samAccountName (Account Name) value or entire displayName (Full Name) value. Both checks are not case sensitive:
    • The samAccountName is checked in its entirety only to determine whether it is part of the password. If the samAccountName is less than three characters long, this check is skipped.
    • The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed not to be included in the password. Tokens that are less than three characters in length are ignored, and substrings of the tokens are not checked. For example, the name "Erin M. Hagens" is split into three tokens: "Erin," "M," and "Hagens." Because the second token is only one character long, it is ignored. Therefore, this user could not have a password that included either "erin" or "hagens" as a substring anywhere in the password.
  2. Passwords must contain characters from three of the following five categories:
    • Uppercase characters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)
    • Lowercase characters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)
    • Base 10 digits (0 through 9)
    • Nonalphanumeric characters: ~!@#$%^&*_-+=`|\(){}[]:;"',.?/
    • Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages

According to: https://technet.microsoft.com/en-us/library/cc786468%28v=ws.10%29.aspx

  • 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. Jan 18, 2017 at 7:57
  • Complexity also requires a special, non alphanumeric character. Did you verify one of those?
    – Sam Erde
    Jan 19, 2017 at 2:50

Honestly this sounds like you're encountering a secondary product setting policy via local GPO edits. Something like ScriptLogic (aka Desktop Authority).

Some symptoms you'd see on older PCs would be:

  1. Existence of SLStart or wKiX32 on the PC in system32 or the root of C:.
  2. If it was previously on there and removed, you'd see that all previously installed programs on the PCs don't show up in add/remove programs.

It's been....a few years. Any idea what the fix eventually was?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .