RSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 8.x

A user cannot authenticate and fails repeatedly with two different and seemingly contradictory messages:

Aug 17 14:39:45 amserver02, AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE, xxxxxxxx1235,
Aug 17 14:39:45 amserver02, AUTH_FAILED_BAD_TOKENCODE_GOOD_PIN,  xxxxxxxx5321

In the summarized logs below, <UserID> had two tokens an was authenticating with one of them, but both were replaced on August 17.

• xxxxxxxx0001 is the original token that had authenticated in last 60 days.
• xxxxxxxx4600 was also replaced, but had not authenticated in at least the last 60 days, if not longer.

Until August 17, <UserID> was successfully authenticating with Token SN xxxxxxxx0001 and the authentication activity logs report AUTHN_METHOD_SUCCESS

On Aug 17 <UserID> replaced both Token SN xxxxxxxx0001, and xxxxxxxx4600.

• xxxxxxxx1235 is the second replacement token for xxxxxxxx0001
• xxxxxxxx5321 is the first replacement token for xxxxxxxx0001

Only one replacement token was delivered via CT-KIP (that is, xxxxxxxx1235).

The theory is that a customer's custom software application replaced both tokens, but only delivered one new token as a replacement, and the user used the 'wrong' PIN to try to authenticate.

Log details show the following:

Aug 20 15:11:35 amserver01, AUTHN_METHOD_SUCCESS, xxxxxxxx1235,

Aug 20 12:38:31 amserver01, AUTHN_METHOD_SUCCESS, xxxxxxxx1235,

Aug 20 12:35:39 amserver01, AUTHN_METHOD_FAILED, xxxxxxxx1235, 
Aug 20 12:35:39 amserver01, AUTH_FAILED_BAD_TOKENCODE_GOOD_PIN, xxxxxxxx1235,,
Aug 20 12:35:39 amserver01, AUTHMGR_PASSCODE_REUSE, xxxxxxxx1235,

Aug 20 12:35:26 amserver01, AUTHN_LOGIN_EVENT, NEW_PIN_AUTH_SUCCESS, xxxxxxxx1235, 
Aug 20 12:35:26 amserver01, AUTHMGR_PIN_CHANGE, SUCCESS, xxxxxxxx1235,
Aug 20 12:35:16 amserver01, AUTHMGR_NEW_PIN_REQUIRED, xxxxxxxx1235,,

Aug 20 12:30:37 amserver01, AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE, xxxxxxxx1235,,

Aug 20 12:30:22 amserver01 , AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE, xxxxxxxx1235,,
Aug 20 12:30:22 amserver01, AUTH_FAILED_BAD_TOKENCODE_GOOD_PIN, xxxxxxxx5321,
Aug 20 12:30:22 amserver01, AUTHMGR_NEXT_TOKENCODE_ACTIVATED, xxxxxxxx5321,,
Aug 20 12:30:22 amserver01, AUTHMGR_NEXT_TOKENCODE_ACTIVATED, xxxxxxxx1235,,

Aug 17 14:43:29 amserver02, AUTHN_LOCKOUT_EVENT, 

Aug 17 14:43:29 amserver02, AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE, xxxxxxxx1235,,

Aug 17 14:40:54 amserver02, AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE, xxxxxxxx1235,,

Aug 17 14:40:17 amserver02, AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE, xxxxxxxx1235,,
Aug 17 14:40:17 amserver02, AUTH_FAILED_BAD_TOKENCODE_GOOD_PIN, xxxxxxxx5321,,

Aug 17 14:40:06 amserver02, AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE, xxxxxxxx1235,,
Aug 17 14:40:06 amserver02, AUTH_FAILED_BAD_TOKENCODE_GOOD_PIN, xxxxxxxx5321,,

Aug 17 14:39:45 amserver02, AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE, xxxxxxxx1235,
Aug 17 14:39:45 amserver02, AUTH_FAILED_BAD_TOKENCODE_GOOD_PIN,  xxxxxxxx5321
-----------------
Aug 17 14:39:16 amserver01, CTKIP_GENERATE_KEY, xxxxxxxx5239

Aug 17 14:39:15 amserver01, EXPORT_SOFT_TOKEN,  amisbind, xxxxxxxx1235,

Aug 17 14:39:15 amserver02 AM_UNLINK_TOKEN_PRINCIPAL, amisbind,  xxxxxxxx4600, <UserID>
Aug 17 14:39:15 amserver02 AM_UNLINK_TOKEN_PRINCIPAL, amisbind, xxxxxxxx0001,  <UserID>
Aug 17 14:39:15 amserver01, , UPDATE_PRINCIPAL, amisbind, <UserID>,
Aug 17 14:39:15 amserver01, , AM_LINK_TOKEN_PRINCIPAL, xxxxxxxx1235, 
Aug 17 14:39:14 amserver01, , UPDATE_PRINCIPAL, amisbind, <UserID>,
Aug 17 14:39:14 amserver01, , AM_LINK_TOKEN_PRINCIPAL, xxxxxxxx5321

To correct the issue the user had their token PIN cleared and went through New PIN Mode to set their PIN to a known value for them.

The working theory is that a customer's custom software app replaced both tokens assigned to user, xxxxxxxx0001 and xxxxxxxx4600, but could only deliver new token xxxxxxxx1235 as a replacement via CT-KIP and the user used the the PIN from the replaced token that was not delivered to authenticate, causing the failure.