Forgotten password flow: log LDAP errors when proxy-based password change fails

[nathanaelries]

When the LDAP proxy account lacks permissions on a user object (common in Active Directory due to AdminSDHolder blocking ACL inheritance), the forgotten password flow fails silently:

1. User passes TOTP + security question verification successfully
2. PWM forwards to the change password page
3. User enters a valid new password, clicks Change Password
4. POST returns 303 redirect zero log output at any level no ERROR, no WARN, no DEBUG, no TRACE
5. Page reloads with 4006 PASSWORD_BADPASSWORD

The ERROR_UNLOCK_FAILURE is logged during the verification step, but the actual password change failure is completely silent. The only way to diagnose this is by correlating nginx access logs with HAR captures and AD ACL audits.

Suggested fix (minimal):

In the ChangePasswordServlet (or wherever the proxy-based LDAP password modification is executed during the forgotten password flow), add a log statement in the catch block that captures the LDAP error code and message. Something like:

} catch (ChaiException e) {
    LOGGER.error(sessionLabel, "proxy password change failed for " 
        + userDN + ": " + e.getMessage());
    // existing error handling...
}

This alone would have saved us hours of debugging. The INSUFF_ACCESS_RIGHTS error from AD would have pointed directly to the ACL inheritance issue.

Nice-to-have (also likely easy):

• When the LDAP error is INSUFF_ACCESS_RIGHTS (error code 50), return a more specific error to the user than 4006 PASSWORD_BADPASSWORD. Something like 5046 ERROR_INSUFFICIENT_PERMISSIONS or even reusing the existing error code with a distinct message. The current error implies the password itself is wrong, which sends administrators down the wrong debugging path (password policy, wordlist, complexity rules).

• The ERROR_UNLOCK_FAILURE logged during the verification step could include a note that this may also affect the subsequent password change if the proxy account's permissions are insufficient for the target user.

Context:

Active Directory's AdminSDHolder mechanism blocks ACL inheritance on any user who is or was a member of a protected group (Domain Admins, Account Operators, etc.). In our environment, ~30 of 80 users had blocked inheritance. The proxy account's delegated permissions (set at the domain/OU level) silently didn't reach these users. Everything appeared to work; verification passed, change password page rendered, password strength meter showed "Very Strong", but the actual LDAP modify operation failed without a trace in the logs.

Environment: PWM v2.0.8, Active Directory (Windows Server 2022), LDAPS