The intent of our Password Reset Portal, is to remove unnecessary interaction by Help Desk staff and Systems Administrators when users need to reset their Active Directory Users Accounts. The portal is aimed at making users self-sufficient at the process, ensuring they can reset the account when they need to, and allow support staff to focus on higher value tasks.
Error: Password Doesn’t Match the Policy
But what happens when the process doesn’t seem to be working? We recently assisted a customer with a scenario where the users couldn’t seem to match the Password Policy no matter how often they tried. They attempted to troubleshoot this by generating a password in Passwordstate however this wasn’t being accepted either. So where do you start to troubleshoot AD Password Resets performed via the Password Reset Portal?
To start off with let’s use an example of a Password Policy and Failed Reset Message. This is configured under Administration->Password Reset Portal Administration->Password Policies,
Note: You can set the Failed Reset Message wording so that it’s consistent with the language used within your organization.
Password Reset Portal Process
At a high level, the process that is used within the Password Reset Portal is;
- When a user resets their AD password, the characteristics of that password must adhere to the Password Policy that has been defined. For the sake of this blog the Password Policy is the Default Policy and is the same for all fields as we’ve set in the previous image. Again, this is set by navigating to Administration->Password Reset Portal Administration->Password Policies,
- As the user types in the new password, the Portal page will report on what characteristics are required to set a password. These must match the policy and feedback is provided live as they type in the new password,
- Once all requirements are satisfied the Password Reset Portal will attempt to reach out to Active Directory to reset the password. At this stage, if your Domain Password Requirements as specified in your Domain Group Policy have further complexities, then the user’s new password will be evaluated against these further complexities.
If the Password Reset is rejected with the Failed Reset Message in the image above, then it is most likely the error you are seeing is coming from your Domain and not the Password Reset Portal.
Settings that Impact on Portal Resets
There are a number of settings that can impact on the Password Reset Portal successfully resetting a user’s password.
The first is located in a group policy setting. Open your Group Policy Editor and navigate to Local Computer Policy->Computer Configuration->Windows Settings->Security Settings->Account Policies->Password Policy and look for a Policy setting stating the Minimum password age.
The Minimum password age of 1 day is the default setting. It is used to prevent repeated resets until a favourite password can be cycled back in again. You’ll need to consider the risks associated in changing this default, and if acceptable you can relax this setting and enable multiple password resets per day by changing the Security Setting to ‘0’,
The next setting that can impact on successfully resetting the password is if your permissions associated with impersonation aren’t correct. To check this, you’ll need to launch the Local Security Policy editor by running secpol.msc. From there you’ll need to navigate to Security Settings->Local Policies->User Rights Assignment and review the permissions that are set for Impersonate a client after authentication. These should be set to the following as per the screenshot below.
- Local Service
- Network Service
- Administrators
- IIS_Iusers
- Service
And lastly, it’s possible that you may have a fine grain policy set in Group Policy, that takes precedence over your Standard Password Group Policy.
This may have been set with a Minimum password age set to something greater than 1, or, may have stricter password complexity requirements. To check if you have a fine grain policy set up you’ll need to logon to one of your Active Directory Domain Controllers, open the Active Directory Administrative Centre and navigate to System->Password Settings Container as per the image below,
If there is a policy show in the area outlined by the green box above then please check the settings. If you’re unsure you may want to refer to the person that is applying the policy.
Privileged Account Credential Permissions
One final thing you can check is to confirm the Privileged Account Credential, that you have specified for the Password Reset Portal, has sufficient permissions to reset the AD Accounts. The Privileged Account Credential is set under Administration->Password Reset Portal Administration-> Privileged Account Credentials.
This should be a member of the Account Operators Security Group. If it isn’t working you can temporarily test with as a member of the Domain Admins Security Group.
Got feedback you want to share? Email it through to support@clickstudios.com.au.