Monday, June 3, 2013

Active Directory Tip: Hitting Snooze on the Password Expiration Policy

The Active Directory Password Expiration Snooze Button

IT Administrators have certainly been in the tough scenario where a security policy mandates that passwords expire in X days, but there are constraints that make it really hard for the user account passwords to actually change.  For example:
  • Dealing with service, application, or generic accounts and a strict constraint to not mark them as non-expiring (forever) passwords
  • Dealing with rarely active human users who suddenly need to (on-demand) authenticate against an application, such as HR benefits open enrollment for employees who are not "information workers" (don't access computers).

There are a couple tricks for dealing with this without causing interruption.  Take note that these "tricks" may completely circumvent the letter and perhaps even the intent of the "policy".  But even with astute auditors, the intent of using these tricks will likely never get noticed. 

Or perhaps you are an auditor, and reading the details of these tricks will open up your mind to look for new events that signify lack of compliance.

Administrative Password Resets
If you know the password for the account in question, then simply perform a password reset with that password.  If you have never thought to do this before, this may at first seem counter-intuitive: after all, resetting a password with a password history rule turned on by policy will cause the password to change, right?

Wrong.  There are two ways an Active Directory password can change: 
  1. The user initiates a password change event, in which they are required to supply the current password in addition to a new password.
  2. The administrator with permissions on the UserAccountControl attribute of the AD user object can perform an administrative reset.
A reset by an administrator must support changing the password when the user is locked out and does not know the password, therefore, the administrator is not required to know the current password.

Also, a reset by an administrator does not enforce password history.  If it did, a rogue administrator could inadvertently learn the current password if the new password supplied by the administrator failed to reset due to password history requirements.  Sure, they just reset the password and could impersonate the user anyway, but that may not be the point: that user's password might be the same on a different (non-Active Directory integrated) application.

So, if you know the current password, perform a RESET and the password last set date attribute on the user account in the directory will update, effectively hitting the snooze button.

A More Clever Trick
But what if you don't know the current password for the account?  

In the scenario of a mostly-inactive end user community that suddenly need to hit an application (e.g. your company's HR system for annual benefits enrollment):
  • there may be too many users to learn their passwords
  • asking the user for their password is likely faux pas
  • the user may not even know the password anyway (since it's been a year), and 
  • resetting a large collection of users passwords to a standard/default that everyone shares is insecure
  • and resetting individually unique passwords for an infrequent, on-demand access presents communication problems all of its own
So, what to do? 

You could disable or extend password expiration.  In Windows 2003 AD and earlier, this meant changing the policy for everybody, which may not be the intent at all.  This is especially true if there are both active and inactive users in the directory, since active users will not get the normal "your password is about to expire" warning X days before it's too late.  Reverting your password expiration policy setting back to the original value could result in a portion of your active users suddenly being locked out and calling for help.  In Windows 2008 and later, you can have multiple expiration policies within a domain, but your user objects may not be grouped to distinguish the inactive users of concern.  You could identify them and move them (and even script that step), but then you may have to move them back to many different OUs (Organizational Units) which could be just as much of a pain as the original problem.

Or you could follow this set of steps (which are scriptable!):
  1. In Active Directory Users and Computers, locate the user with the expiring or expired password
  2. Check the "force password change at next logon" box.
  3. Click Apply.
  4. Uncheck the "force password change at next logon" box.
  5. Click Apply.
And VOILA!  That user's password expiration has just been snoozed-- effectively reset for another iteration, and with zero knowledge of the current password.  The password last set date will appear to be the moment you hit step 5.

How does this work?

Under the hood, the user attribute which stores the date/time when the password was last set is also dual purposed for the password must change flag.  The value is a really large integer which contains the number of ticks of seconds as a representation of time.  But when the force password change button is checked, the value of seconds of time is wiped out.  "Empty" is how the flag is stored.  The last date/time is wiped out.  So, when the administrator unchecks the force password change checkbox, AD Users & Computers has to put SOMETHING in that attribute, because NOTHING appears like it is flagged for change.  But the original value is gone forever!  So what does it store there?  The current date/time.  Hence, the user appears to have had its password reset without any actual (visible) changes to the user.

This can all be scripted out using the dsquery and dsmod commands the Microsoft ships with Active Directory.  PowerShell could also be used.  Or, an astute C# (or VB) .Net developer could simply take a look at the Securology GitHub repository, to see the example Password Snooze Button console app, to incorporate it into your organization's existing user management applications and services.

For the Auditor
To detect if an organization that you are auditing has been using the first option (administrative password resets to snooze the expiration), look for:
  • Event log data for password resets of multiple accounts at roughly the same time, since this would likely be done "in mass" by the IT administrator
  • Service accounts that all have roughly the same password last set date and time.  Manually resetting multiple passwords would have a period of time between each reset event, but a script would cause them all to be within a few seconds of each other
  • User accounts that have been in existence for longer than the password expiration policy's time out, but that have one or few historical passwords stored in the directory (requires a very low level AD editing tool to discover), while still being active (lots of log on events)
To detect if an organization has been using the second option (password must change flag), look for:
  • Lots of user accounts with nearly the same date/time value for the password last set attribute.
  • Lots of user accounts that have not logged in since their password was last set.
  • If event log data is available, look for lots events denoting the must change password flag was set or unset.
Even if long term historical event log data is available, the determined IT administrator could spread out these events to appear sporadic, random, or intentionally related to a user's call to a help desk.  A determined administrator could both keep the lights on and keep auditors at arms' length without detection of a policy violation.


Colin McD said...

My only comment is WHY!

Why do some places mandate a monthly password reset?

This leads to people writing their password down, storing in phones, or worse (singing the mime to their colleagues as they type it in My Password Is Easy Too Remember 56 myietr56).

I know too many organisations that mandate monthly password changes. While this stops the work password from being the gmail password, really does this behaviour decrease the risk of attack?

securology said...

Oh, "they" mandate monthly/quarterly resets because someone someplace once said it might be a good idea.

When it comes to policies, most places think that having one-- even if it's not correct-- is better than not having one.

We agree; changing passwords often by force of policy isn't necessarily going to improve security.

But this is an example of the technology, how one can appear to be compliant, and still maintain order. It's for the "little guys" stuck working under the stupidity.

FentonRedDevil said...

Very interesting, and timely.
I wonder what happens if we change our password expiration policy from say, 92 days, to 90 days? Does it just reduce the current expiration by 2 days, or does it start over and give the full 90 days till the next expiration. I would think the first, but I am worried we might inadvertently set all accounts to expire on the same day.

securology said...

FentonRedDevil: The date of the password last set is stored on the user account object in the directory. If the global password expiration policy changed from 92 to 90 days, then the user accounts would not be affected unless the password last set date was > 90 days ago but < 92 days ago. In a typical deployment, that will be a very small percentage of affected user objects.

FentonRedDevil said...

Thanks for your time. I appreciate it.

securology said...

No problem ...

Ben Yau said...

Holy cow ... this is awesome. Thanks so much!!