AD Password Reset vs. Change in UMRA & SSRPM

A subject of much confusion when it comes to Active Directory (“AD”) password resets are the words “change” and “reset.” First, let’s clarify some terminology. There are two ways you can “modify” a password in AD:

1) AD Password Reset

Also known as administrative password reset – this method bypasses any password history/complexity settings:

2) AD Password Change

This method requires a valid current password (underlying API calls actually require it) and this is the most common user-initiated password “modification” that upholds the password complexity and history requirements:

SSRPM

When it comes to resetting passwords using Tools4ever‘s Self Service Reset Password Management, after successfully answering the Challenge-Response questions and providing a new password, a password change takes place.

How might that be possible, if SSRPM doesn’t collect the old password? (the entire premise of SSRPM is resetting a forgotten password using “what’s your maiden name” questions) Through a simple, but clever approach: SSRPM will first perform a password reset, using a randomly generated secure string; it will then perform a password change, using the password it just set, to satisfy the API requirements.

As clever and production-proven of a method it is, it does have an occasional side effect like this one:

1. User (enrolled in SSRPM) forgets password
2. Uses SSRPM Q&A to change password
3. Q&A answered successfully, but password doesn’t meet complexity requirements – an error is shown
4. User remembers they wrote down their password
5. They now try to login with their written down password, but it no longer works
6. Why? Because of that password reset (to a random sting) that SSRPM had to do prior to attempting the password change

UMRA

Tools4ever‘s User Management Resource Administrator ships with an out-of-the-box password reset action:

There has been a case in a web portal that we built for a US state government where this action would error out with “password doesn’t meet history/complexity” error message. I’m not quite sure how this is possible, but I suspect it has to do something with running UMRA Service under a non-Domain Admins accounts (AD 2008 privileges were used).

While a password change action is not offered in UMRA out-of-the-box, it could easily be developed as a stand-alone .exe utility, or as a PowerShell action integrated into UMRA.