How to change user passwords in Active Directory
We often get asked how our self-service solution changes passwords on a user account in Active Directory. It’s a more interesting question than it sounds as there are many processes at work here, and many ways to do it. I have written this blog post to explain the process and the ways this can be achieved.
Firstly let’s look at the most common built-in tools/methods:
- Active Directory Users and Computers – A nice GUI that’s been around since the dawn of AD is the most commonly used tool. You simply right-click on a user account, select reset password, and providing you have the correct privileges on that account, you can reset the password.
- Active Directory Administrative Center – A newer GUI, has the reset password interface on the opening screen, often overlooked.
- PowerShell – Every Windows Admins favorite shell! Set-ADAccountPassword is the command you want to use.
- Command Prompt – for the old fashioned among us good old “Net user /domain”, I think this command was available in NT4 days and can still do the job, along with “DSMOD User” which arrived wit Windows 2003.
There are probably a few more such as making the password change/reset using LDAPS or ADSI programming interfaces, but they are a little out of scope for this blog!
So what actually happens when the password reset command hits a domain controller?
Firstly the credentials of the user are checked when the initial connection to the DC is made to make sure that the user who is updating the password is allowed to do so for the target account.
The password is then processed by the Password Filters on the DC to check that it meets the complexity, history, and length requirements. These are usually defined in the Default Domain GPO, but may have been moved to another GPO in some environments. The user account may also be affected by a fine-grained password policy so their membership will also be checked to see if they are affected.
Once the password makes it past the Microsoft Password filter it will then it will be processed by any third-party filters that may be installed, such as Specops Password Policy or Specops Password Sync. If all those filters approve the password it will then be written to the users account, and the pwdlastset attribute will be updated on the users account.
If the password fails any of the filter checks, a basic “failed” message will be returned to the admin/user interface. The details of the failed settings are not provided by the MS filters, however third-party filters (such as Specops Password Policy/Sync) often provide enhanced feedback. These error messages can be passed back to the client computer in the event of an end-user password change. If it’s an admin password reset that fails then the admin will be able to see the failure message in the application event log on the DC that processed the change.
Once the password has been successfully changed the new password will be replicated around to the other DCs using the standard replication schedule. This can sometimes result in a delay for the user when they try to use their new password. If such a delay occurs always try to make the password change against the DC that holds the PDC emulator FSMO role and make sure that the GPO setting to check with the PDC on password failure is enabled. In well-connected environments it is often beneficial to enable AD Change notification, this will allow AD changes to replicate much faster between DC’s located in different sites.
Password resets are often a problem as organizations grow, or become increasingly remote. The sheer number of them can take up huge amounts of time for the service desk, or result in long delays for the end user in being productive again (resetting your password outside of the VPN is a nightmare) which ultimately results in a loss of profit for the company.
Then you also have the security issues, how do you know the user requesting a password reset over the phone is who they say they are? Can all your service desk staff be trusted to tick the “User must change password at next logon” box? If these sorts of questions keep you awake at night then it may well be worth implementing a self service password reset solution, such as Specops uReset.
The solution can fix the issues mentioned above, and remove the reset call from the service desk. With Specops uReset, you can ensure that users can reset or change their passwords from anywhere, or any device, and verify their identities with MFA. When combined with Specops Password Policy, the solution displays real-time password policy feedback, and prevents users from selecting a vulnerable, or breached password. Specops uReset pays for itself by saving time for both the service desk, and users.
(Last updated on March 16, 2021)
For the first 8 years of Active Directory, the only native way of having multiple password policies in your AD forest, was to have multiple domains. When Windows Server 2008 arrived on the scene, Microsoft introduced the concept of fine-grained password policies (FGPP), which allowed different policies within the same domain. Traditionally, the Default Domain…Read More
There are many reasons why you might want to sync a password between two Active Directory (AD) domains. We commonly see requests from customers who are looking at migrating their users from one domain to another. This could be for many reasons including acquisition/divesting, domain upgrades, or even syncing to another AD domain that hosts…Read More