When using a personal access token to authenticate, if the:
- access token is expired, or
- the user is inactive in LDAP
the token authenticator opts out of the authentication processing, rather than rejecting the token. This results in the system attempting subsequent authenticators, including the Crowd authenticator that handles username/password authentication. The token is sent as a password and rejected, which increments the CAPTCHA counter for the user. This eventually leads to the user account being locked.
- Set up a personal access token for a user
- Mark that user inactive in Crowd
- Attempt to authenticate using basic authentication with the token as the password
The token is rejected, because the user is not active in LDAP, and normal username/password authentication is not attempted. The user's CAPTCHA counter is not incremented.
The token authenticator logs that the user is inactive and then opts out rather than rejecting the token. The system attempts username/password authentication with the token, which fails, and the user's CAPTCHA counter is incremented.
The following message is logged:
There is no workaround for this behavior. Generally if an inactive user is CAPTCHA'd it shouldn't matter, since they're not active. If necessary, the CAPTCHA can be cleared by any ADMIN or SYS_ADMIN user using the REST API. (Note that if the inactive user is a SYS_ADMIN, only another SYS_ADMIN user can clear the CAPTCHA.)