Password change fails claiming violation of password policy rules but the password actually meets them
Good day all,
I have faced this issue several times before in several different environments. Almost everyone of them was resolved by setting the "Minimum Password Age" to "0". However, I am currently experiencing this in one of our Domains and have already spent around 8-10 hours troubleshooting with no resolution in sight. So, I am humbly reaching out to the community for any ideas at all.
Environment as follows: Windows 2012R2 Forest & Domain functional level, x3 Windows 2012R2 DCs with one of them at a remote site. x2 DCs in the main data center. there are 3 sites in all. Clients are Windows 7 Professional with all current patches.
The Default Domain Policy contains the settings for password policy. They are as follows:
As can be seen, Minimum Password age is set to 0. However no matter how many times we have tried, both with test and live user accounts, the users cannot change their passwords and the reason given is that the password does not meet the requirements. Except that they very much do. I have tested replication, ran comprehensive DC Diag with no abnormal results. I have tried this from different workstations and even different types of workstation hardware. I can successfully reset user passwords from ADUC and if I select "User Must Change Password", they are able to. The only thing I have been able to spot that looks out of sorts is that RSoP on the workstation completes while complaining about there being no RSoP for the user. Also, oddly enough, if I 'echo %LOGONSERVER% or issue 'set' ' from the command line, I get nothing in response where of course I should get the logon DC. I can resolve the domains FQDN from the client, I can reach SYSVOL from the client. It is all very curious. So, I would appreciate any and all ideas and suggestions. I have tried to describe all that I have done but I am sure I have left some out. Please feel free to ask whether or not I have done some step of troubleshooting or not.
I have faced this issue several times before in several different environments. Almost everyone of them was resolved by setting the "Minimum Password Age" to "0". However, I am currently experiencing this in one of our Domains and have already spent around 8-10 hours troubleshooting with no resolution in sight. So, I am humbly reaching out to the community for any ideas at all.
Environment as follows: Windows 2012R2 Forest & Domain functional level, x3 Windows 2012R2 DCs with one of them at a remote site. x2 DCs in the main data center. there are 3 sites in all. Clients are Windows 7 Professional with all current patches.
The Default Domain Policy contains the settings for password policy. They are as follows:
As can be seen, Minimum Password age is set to 0. However no matter how many times we have tried, both with test and live user accounts, the users cannot change their passwords and the reason given is that the password does not meet the requirements. Except that they very much do. I have tested replication, ran comprehensive DC Diag with no abnormal results. I have tried this from different workstations and even different types of workstation hardware. I can successfully reset user passwords from ADUC and if I select "User Must Change Password", they are able to. The only thing I have been able to spot that looks out of sorts is that RSoP on the workstation completes while complaining about there being no RSoP for the user. Also, oddly enough, if I 'echo %LOGONSERVER% or issue 'set' ' from the command line, I get nothing in response where of course I should get the logon DC. I can resolve the domains FQDN from the client, I can reach SYSVOL from the client. It is all very curious. So, I would appreciate any and all ideas and suggestions. I have tried to describe all that I have done but I am sure I have left some out. Please feel free to ask whether or not I have done some step of troubleshooting or not.
Adam Brown
The computer may not have fully connected to the network before logon, and so it would be using cached credentials. Make sure the Dynamic RPC port range for the Windows server version you use is allowed through any software firewalls on the workstation or disable the firewall and reboot to see if that changes things.
You misunderstand something elementary: since you execute rsop.msc at the client, you seem to believe that the policy for passwords is evaluated at the client. It is not in this case, since domain passwords are saved at the domain controllers. Please run rsop.msc at the domain controllers to see if the resultant policies are the way you think - I guess they are not.
Perhaps you are using a previous password or including sAMAccountName ore word from displayName in password?
ASKER
Good point except I haven't. I have run RSoP on the DCs and the PDC emulator has the correct RSoP. Again,the policy is as it should be. We have also made sure that the passwords we have attempted to use are completely random. I am however, going to check the firewall situation again.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
How funny, while I was writing the same, you come up with the PSO :-)
ASKER
I know, right? Exactly. I ran that yesterday and was trying to deduce where the 7 day minimum was coming from. It never occurred to me that FGPP was being used. We asked the people who built that domain and they told us. After that, I went back and looked at the DN in the output and sure enough ...
Thank you for all of your comments.
Thank you for all of your comments.
ASKER
I resolved the issue myself