Rolling out new password policies: Changing the pwdlastset attribute

Rolling out new Password Policies can require planning. Captain Obvious? Maybe. But planning, planning and planning will ensure you ask all your questions upfront. It is tortoise and hare right? “Less haste, more speed!”

In discussing some planning with someone recently we began talking about an issue where users are forced to immediately change their password. Not always the intended result. The scenario is simply a user who is affected policy stating their passwords expire in 180 days, or maybe never. A change is made that requires them to change their passwords every 90 days. Well you can imagine some users would have a password older than 90 days when the new policy take effect. So, they simply come to work, no warning, no announcement, no notice and try to login and their computer tells them their password is expired change it now. OK, so it is not a huge issue but for some organizations it is one to avoid.

Password Expiry basics (maybe a bit more)

The password expiration is calculated. It is taking the value in an attribute on the user object called pwdlastset and comparing that to the maxpasswordage applied to that user. That can happen in a few ways but it is most likely coming from Policy. If I use the great AD PowerShell module I can get some good info on user objects.

PS C:\> Get-ADUser –Identity “Kevin” –Properties pwdlastset

This above simply grabs the user object from AD and explicitly asks for the pwdlastset attribute. That would not have come down by default. Here is the output.

Cool right? But look at pwdlastset, what the heck is that?

If you haven’t seen this yet, that number represents the number of 100 ms ticks since January 1^st, 1601. I think this approaches the definition of geeky. You can imagine it is a big number. It is actually not too tough to convert this into something actually helpful.

PS C:\> $user = Get-ADUser –Identiy “Kevin” –Properties pwdlastset

PS C:\> [datetime]::FromFileTime($user.pwdlastset)

Friday, February 27, 2015 10:05:04 AM

Cool right? The same data was retrieved from AD but it was stored in the variable ‘user’ ($user). Then the [datetime]::FromFileTime($user.pwdlastset) funky line simply converted that number into a ‘datetime’ format. There are lots of resources out there that show different ways to manipulate ‘datetime’ data. And there is of course the PowerShell help content that can provide lots of tips and tricks.

Retrieving the data is one thing, changing it is a whole new set of crazy. Easy but a bit strange.

Take a look at this video where I walk through this in a bit more detail and begin porting the learning into a tool.

Alternatively, system administrators can download Specops Password Auditor. Specops Software released the latest version of Specops Password Auditor, introducing a new report that will make the lives of IT admins looking to force a password reset a little easier. The new report, called Password Age, can show IT admins a list of users who have changed their password since a certain date or users who have not changed their password since a certain date as well as vulnerabilities found, including expired or compromised passwords (including whether any user’s password was found on a list of breached passwords).