SecurID Tokens: Can they resync on their own?

[KeithGiles]

We recently had two users prompted to enter the "next tokencode" after they'd already logged in successfully. According to RSA support, this is typically because their tokens are out of sync. 

However, they were able to log in again after we cleared their incorrect login attempts. We did not do anything to resynchronize their tokens.

With that said, does this mean the tokens can sometimes get back into sync without intervention? 

Or was my problem perhaps something else? The users were highly confident they entered the correct token code each time. 

[JayGuillette]

The answer is 'a little bit' or 'kind of'

If you restart AM services on the Primary, either after a reboot or in Linux   /opt/rsa/am/server/rsaserv restart all

the first time every token is used to logon after that, the AM server will accept any tokencode within a plus or minus 10 minute window.  The AM server can then note any difference in the time on the token from the time on the AM server (which is always assumed to be correct)

Re-synching a token does the same thing, but with a plus or minus 12 hour window 

[TedBarbour]

You can be entered into NTC mode because of incorrect attempts per token policy.

[JayGuillette]

To your original question, Next token Code, NTC can happen for two reasons, one of which is kind of what Support indicated to you, that this token is a little bit out of synch, the tokencode entered was within 2-3 minutes of the expected tokencode AFTER an initial authentication after restarting AM services.  In other words, first time token used to authenticate after services have been started is the plus or minus 10 minute window, which allows AM to get its bearing on this individual token, to learn this token's exact time offset difference, and every time authenticating after that initial auth the Window is tighter, plus or minus 1 minute.  Close as in plus or minus 2-3 minutes triggers NTC.  Any tokencode more than 3 minutes off from expected offset time is considered incorrect and look even looked up.

The 2nd way to trigger NTC is to fail authentication some minimum amount of times, which is set in the Token Policy, and defaults to 3 failures in a row without a success - over any amount of time that the AM services have been running.  You might consider a Token Policy change to 5 if this is a problem for your users, arguing that 5 is still tight enough to thwart hackers trying to steal OTPs (which in itself is an Everest-type task for the hacker).

You also can clear all NTPs from all Tokens with the /opt/rsa/am/utils/rsautil sync-tokens utility in Linux

[KeithGiles]

Thanks for the replies. If I understand, then restarting the AM service will essentially resync the tokens? It's been a few months since it was restarted (the latest patch). 

I do see that our policy requires next tokencode after 3 incorrect passcodes. Does this mean three consecutive incorrect entries? Or is this just three random incorrect entries? 

The users were extremely confident they entered the correct passcode, but perhaps they entered their computer password incorrectly. 

[_EricaChalfin]

Keith Giles‌,

000029685 - Navigating Next Tokencode Mode in RSA Authentication Manager 8.1 and above gives a good explanation of the Next Tokencode process and the window of valid tokencodes when authenticating.

Regards,

Erica

[JayGuillette]

Yeah, I'd restart services, maybe implement a plan to restart or reboot once per quarter or something, and change Token Policy to 5 and then the problem should really drop off your radar.

The 3 strike (or 5 strike change) bad TokenCode in the Token Policy is in a row, meaning it goes back to 0 strikes when you successfully authenticate with that Token.

You could also run an authentication report on the user, and look for 3 failures in a row. If you cannot find that, then it is most likely due to time being slightly off.  

[KeithGiles]

WPVABf2A7AHE7HYzA8lNwkryi3vLGLSU‌, thanks! I will definitely read over that. 

[KeithGiles]

Thanks so much Jay, I will check that!

To confirm, when it says incorrect passcodes, it is referring to the AD password + the tokencode, so it could be an incorrect password too?