How To: Choose a SecureAuth Password Reset Mode

Version Affected: All versions (behavior described below may differ on versions older than 9.0.1)

 

Overview

This article explains the three modes available in the SecureAuth Password Reset module, so you can choose the one that fits your environment. In a typical Active Directory (AD) environment without SecureAuth, a user calls the help desk, an administrator resets the password in AD, and — if the new password meets Group Policy Object (GPO) complexity requirements — AD records the change by entering the old password once and the new password twice (the same pattern used in Outlook Web App). SecureAuth's Password Reset realm follows the same underlying workflow: a user submits a reset request, and the realm performs the reset according to whichever mode it is set to. There are three methods below — use the one that fits your environment:

• Method 1: strictest complexity enforcement, but weakest protection against a user cycling back to their old password.
• Method 2: simplest to set up, with no protection against reusing a past password.
• Method 3: strongest protection against reuse, but requires LDAPS to set up.

In this article

• Method 1: Enforce Password Change Requirements
• Method 2: Administrative Password Reset
• Method 3: Administrative Reset with History Check

Method 1: Enforce Password Change Requirements

This mode changes the password twice: once to a scrambled, temporary password, then again to the user's desired password — so it counts as two password resets against any password-history policy. Its facts:

• SecureAuth never retains passwords — it only passes the old and new password to Active Directory and returns the pass/fail result code AD sends back.
• SecureAuth checks complexity requirements (capitalization, length, and so on), but does not check whether the password was used before — that check is AD's job, based on its password history policy.
• This mode cannot protect against a user repeatedly entering their desired password until the password history rolls over and allows them to set it again.

For example, with an Active Directory Enforce Password History GPO of 5 remembered passwords, Require Current Password set to False, and Must Change Password at Next Logon set to True: a user attempting to reuse their very first password can succeed as early as their 4th change attempt, instead of after the 6 changes the history depth would suggest. This happens because each of this mode's scrambled intermediate passwords also occupies a slot in the password history, so the real desired password gets pushed out of the tracked history sooner than expected. The same effect means a user can eventually reset their password back to a specific value they have used before (for example, a password they set weeks earlier), simply by attempting that same value repeatedly until enough scrambled intermediate passwords have cycled the history depth.
 

Be aware of this behavior when using Enforce Password Change Requirements with a strict password-reuse policy — it does not enforce reuse protection the way Administrative Reset with History Check (Method 3 below) does.

Method 2: Administrative Password Reset

This mode performs a single password change with no history protection. Its facts:

• SecureAuth never retains passwords — it only passes the old and new password to Active Directory and returns the pass/fail result code AD sends back.
• SecureAuth checks complexity requirements, but does not check whether the password was used before — that check is AD's job.
• Without SecureAuth-side validation, this mode lets a user change their password to any value they want — including one they have used before — even when Active Directory has complexity enforcement turned on in its GPO.

Method 3: Administrative Reset with History Check

This mode is the most involved to set up — it requires LDAPS, and therefore an SSL certificate with authority to manage AD accounts, plus careful, specific configuration steps to get working. Its facts:

• SecureAuth never retains passwords — it only passes the old and new password to Active Directory and returns the pass/fail result code AD sends back.
• SecureAuth checks complexity requirements, but does not check whether the password was used before — that check is AD's job.
• Unlike Enforce Password Change Requirements (Method 1 above), this mode does protect against a user repeatedly entering their desired password until the password history rolls over.

For example, with the same Active Directory Enforce Password History GPO of 5 remembered passwords, Require Current Password set to False, and Must Change Password at Next Logon set to True: a user attempting to reuse their very first password succeeds only on the 7th change attempt — correctly reflecting the configured history depth, unlike the premature 4th-attempt reuse possible under Enforce Password Change Requirements.
 
 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.