passcode reuse or previous tokencode
We migrated some users to a different appliance recently, and they are facing authentication issues. The logs show a successful authentication, immediately followed by "passcode reuse or previous tokencode" and " Bad Tokencode but good PIN detected".
They are using the correct pin and the correct token from the mobile app, so not sure what is happening here.
Would this be be an RSA or a VPN issue? As we could not determine any issues with either so far.
Thank you for your time.
It sounds like the agent is retransmitting the auth request, where the first auth works and the second one causes the errors you see. Without knowing more info about your system (RADIUS or a built-in UDP agent?) it's hard to tell exactly what is wrong -- I recommend opening a case with RSA support to go over your logs and configs in a less-public forum. If you need help opening a case, start here: https://community.rsa.com/docs/DOC-1294
Look at the number of seconds between the first successful authentication, and the second failed reuse authentication. Steve is right about the re-transmission of the original authentication request, but if it is less than a second later, that could indicate a bug, or a problem with a High Availability pair of Agents 'accidentally' both sending the authentication the authentication. It could even be a loop in your network, though that is rare nowadays.
If the reuse authentication is from 2-5 seconds after the first authentication, that could be a simple configuration error, that did not allow enough time for the first request to be answered before it re-transmitted the same request. Most authentications need at least 5 seconds to fully complete, busy or oversubscribed AM servers might need 6 seconds.
There is a tcpdump utility in Linux on all AM servers, so you could capture all authentication traffic and compare the initial authentication with the reuse authentication, to compare details like source MAC or IP address, or IP layer ID and checksum to determine if the second request were caused by a layer 2 (Spanning Tree) loop or by a layer 3 routing or configuration issue.
Migrating between servers also triggers this if the clock on one system or the other is not exactly set the same. So, the user is entering the correct code, but the system has an inaccurate clock and thinks the codes are already stale.
UTC time must always be actual UTC. On command line check it with date -u.