Using PowerShell to manage password resets in Windows domains

Last month the White House issued a recommendation that everyone change their password as a way of preventing a potential breach. Although such a request sounds simple enough, enforcing password changes throughout an organization is a tall order.

While it is relatively easy for an organization to contact all of its employees and tell them to reset their passwords, odds are that most people will ignore the request. Some users are lazy and simply do not want to be bothered with changing their passwords. Other users might plan to change their password, but get distracted by other things and forget to make the change. Still other users will claim to have changed their passwords, when in reality their password remains unchanged.

Investigating who needs to reset their password

So how can an organization figure out which users have and have not changed their passwords? One way of accomplishing such a task is to use the Active Directory Users and Computers console.

Once the console opens, select the Advanced Features command from the View menu. Next, select the Users container Right click on the user whose password change history you want to examine, and then choose the Properties command from the shortcut menu. When the User Properties sheet opens, select the Attribute Editor tab.

This tab lists dozens of attributes related to the user account. You can find the date of the user’s most recent password change by examining the PwdLastSet attribute, shown in Figure 1. It is worth noting that if the user has never changed their password, then the PwdLastSet attribute will show the date when the account was created (assuming that a password was assigned to the account at the time of creation).

Speed things up with PowerShell

Of course, the main disadvantage to using this approach is that it forces you to check each account individually. You can get around this limitation by using PowerShell.

To do so, you will need to make sure that PowerShell’s Active Directory module is loaded. The command used to retrieve the date when a user’s password was most recently changed is:

Get-ADUser -Properties PasswordLastSet

You can see how this command works here:

In this example, only one user’s password change date is being shown, but there are any number of ways to tell the Get-ADUser cmdlet to display data for multiple user accounts. For example, this command will cause the last password change date to be displayed for all users:

Get-ADUser -Filter * -Properties PasswordLastSet

You can see what this command looks like here:

As helpful as this information might be, you will still need to parse the data that has been produced by PowerShell. This might mean sorting the output by date or exporting the data to an Excel spreadsheet. Although PowerShell will allow you to perform these types of actions, they are more complex than simply retrieving the password change date alone. If for example, you wanted to see a list of all of your user accounts sorted by password change date, you could use this command:

Get-ADUser -Filter * -Properties PasswordLastSet | Sort-Object -Property PasswordLastSet | Select-Object Name, PasswordLastSet

You can see the command’s output here:

All of this is to say that you can use PowerShell to figure out who has changed their password and who has not. The real question however, is whether a password change is really worth the complexities involved in delving into PowerShell? This question seems especially relevant considering that CISA, Microsoft, and other cybersecurity experts now recommend against scheduled password changes.

A sustainable solution to password age questions

While the White House directive is hopefully a one-off event, organizations never really know when an unexpected situation may necessitate an organization wide password change. Should such an event occur, time will most likely be of the essence and so it will be important to give users an easy way of completing the password change. It will be equally important to give IT an easy way of verifying the password changes. After all, you really don’t want to be trying to piece together PowerShell code in the middle of a crisis situation.

A better alternative is to use Specops Password Auditor. The latest version of Specops Password Auditor contains a tool that admins can use to determine who has and who has not changed their password since a certain date. Test it out for free in your Active Directory to double check that your organization complied with the recent password change recommendations.

Sponsored and written by Specops.