How can I detect users that have requested AD Administrators to reuse an expired password?

Question

There is a trend among companies I've worked at where administrators (or helpdesk folks) give a user a courtesy extension of the old expired password... rather than forcing the user to change it.

This is usually done by re-entering the expired password directly via AD Users and Computers... rather than changing it though Ctrl-Alt-Delete.

Given that the "last password change" field is not a valid way of detecting this situation; how can I detect expired password reuse?

An example would be to compare the password hashes once every so often to ensure compliance; but I'm looking for the most logical and secure approach.

Answer 1

There is more than one way to configure auditing in Group Policy, but I think the primary old way (on Windows Server 2003) is to open GPMC, edit the Default Domain Policy (or whatever domain policies are active in the OU and objects you're working with), and drill down from the Policies node through Windows Settings to Security Settings, in order to open the Local Policies Audit Policy branch. There's an "Audit account management" section that you can define.

The above only lets you audit the account changes, but you have to make it actionable by relating it back to success criteria, such as a user's password had recently expired. By leveraging OSSIM (or another strong correlation engine), you could combine ADSI scripts which check every audit account management message to see if it was a password change, and to see if the password recently expired. Then, the hashes could be matched, etc. Even OpenVAS could be kicked off to try and bruteforce the password -- although it would probably be better to perform this task with more data.

This becomes an exercise in customization for client, server, and other infrastructure hardening/monitoring. You would want to move the maturity of your entire infrastructure to a higher level -- so I assume you've already done much of the work prescribed by The Center for Internet Security (CIS) and/or NIST.

If you are more greenfield and haven't implemented customized solutions like this in the past, it would certainly be better to jump to a future-proof solution such as OpenIDM from ForgeRock. This would be a multi-million dollar, six year project or so.

If you're in a large-installation brownfield operation, such as Fortune 500 -- it would be best to identify your existing IAM, IDM, Directory, ESB, and other backoffice components in order to properly analyze where to fit identity lifecycle management issues such as user-password resets. It may be that an existing solution provider, such as SAP, Oracle, TIBCO, or Microsoft has an easy answer.

If you're solely a Microsoft shop (100 percent), then you probably want to discuss their ILM 2007 product, FIM 2010, and related solutions. Microsoft has a nasty way of canceling these product lines, or changing them drastically -- so it's good to be hip to the "inside track" and discuss directly with the ILM/FIM and other product managers (PMs) instead of just an account manager (AM) or their websites and trade information.

There are other, more point solutions such as Quest software's ChangeAuditor for AD, but I would be wary of this only solving a short-term problem, when clearly a business process and huge set of business/infrastructure maturity problems may exist.

Answer 2

maybe the answer here is not just technology but as well process. This courtesy, shouldn't be done, the administrators actions should be audited and admins doing that should be punished. Unless it is compliance with security policy (if you have one)

Answer 3

On the technical level, the fundamental problem here is that the help desk can reset the password and leave the "user must change password" checkbox unchecked.

I don't know of a way to force leaving this checkbox checked. There might be one, but I don't know how.

One way around this might be to not give help desk personnel delegate access to AD Users and Computers, but instead create a script that uses LDAP to reset the password and sets the "user must change the password at next login" flag at the same time. You can make this script even more convient (for the help desk): auto-generate a short, simple password as the temporary password, and then email it (or hand it) to the user.

That said: ultimately, this is not a technical issue. With the sheer number of passwords even non-technical users are dealing with today, I completely feel their pain. Some security people have been making the case that longer, but easy-to-memorize passwords that are rarely or never changed may actually be better.

Often, even without the "courtesy extension" users defeat the password change mechanism by always using the same short simple password with a counter appended, and sharing the same password across vulnerable systems and sensitive systems. Or by complaining to top management and getting the policy changed to "never change passwords".

So your best strategy is to address this issue at the top management level. If top management isn't supportive of solving this issue, your attempts to deal with it at the technical level can backfire. And if top management is supportive of solving this issue, you may not need a technical solution; help desk personnel will simply get a new policy specifically prohibiting such courtesy actions.