Issue Summary

When a user fails multiple login attempts, the AUTH_ATTEMPT_INFO table records the failed count for each USER_NAME, as typed, this is case-sensitive. On successful authentication, the system resets the counter only for the exact USER_NAME stored in CWD_USER. Any failed attempt entries recorded under a different casing (e.g. testuser vs TestUser) are not cleared, causing CAPTCHA to persist even after successful login.

Steps to Reproduce

1. Create a user testuser (in LDAP) or an internal user
2. Attempt multiple failed logins using a different casing (e.g. TestUser, testUSer, Testuser)
3. CAPTCHA is triggered as expected
4. Login successfully using any casing (Crowd/LDAP accepts case-insensitive login)
5. Observe that AUTH_ATTEMPT_INFO still contains entries for the case variant used in step 2
6. CAPTCHA continues to be presented on the next login attempt

Expected Results

On successful login, all AUTH_ATTEMPT_INFO entries for the user should be cleared regardless of casing (e.g. match on LOWER(USER_NAME)).

Actual Results

Only the entry matching the exact canonical CWD_USER.USER_NAME is reset. Entries under other case variants persist, and CAPTCHA remains triggered.

Workaround

Users can work around this by ensuring they type their username in the exact casing as stored in the CWD_USER table, or an administrator can manually clear the stale entries from AUTH_ATTEMPT_INFO:

DELETE FROM AUTH_ATTEMPT_INFO WHERE LOWER(USER_NAME) = 'Testuser';