000029685 - Navigating Next Tokencode Mode in RSA Authentication Manager 8.1 and above

Document created by RSA Customer Support Employee on Jun 14, 2016•Last modified by RSA Customer Support on Feb 28, 2018
Version 7Show Document
  • Comment • 0
  • View in full screen mode

Article Content

Article Number000029685
Applies ToRSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 8.1 and above
IssueEnd users are reporting that during authentications with RSA SecurID software and/or hardware tokens they are being prompted to wait for the next tokencode to display on their token and to enter credentials again. Within the authentication activity monitor, users are seen as being in Next Tokencode Mode.
Tasks

Troubleshooting tasks



  • Check the version of the RSA  Authentication Manager software being used by the primary instance and replica instance(s).  All Authentication Manager instances should be using the same software version and the latest available software service packs and patches.
  • Check replication status between the primary instance and each replica instance(s).  Replication failing will eventually cause a problem with end user authentications.
  • Check the time difference between the primary instance and replica instance(s) as there should not be a difference of more than one to two minutes between any Authentication Manager instance.
  • Run an authentication activity report and check to see which end user(s) are constantly being prompted for a next tokencode.
  • In the authentication activity report also check which Authentication Manager server is processing end user authentications and which authentication device (RSA Authentication Agent or third party device, such as Cisco AnyConnect, F5, Palo Alto, etc.) is sending the end user authentications to the server(s). Should it be seen that a majority of the authentications are coming from one agent, a review of the agent configuration may be required, with further authentication testing.
 
 
Resolution

End users entering incorrect passcodes


End users entering incorrect passcodes can invoke next tokencode mode. Updating the Token Policy setting 'Incorrect Passcodes' allows users to enter a limited or unlimited number of incorrect passcodes. When the limit is exceeded and followed by a correct passcode, users are prompted to enter the next tokencode that is displayed on their tokens.



Understanding the token synchronization range


The token seed record XML defines the token range of the tokens in seconds. For example, 


<DefSmallWin>60</DefSmallWin>
<DefMediumWin>120</DefMediumWin>
<DefLargeWin>600</DefLargeWin>

Note that token seed XML files cannot be modified.
 

Token synchronization range table



Token TypeAutomatic RangeAccept with Next TokencodeMaximum Limit
   (3 failures + next code)
Standard Tokens
   Key Fobs		+/- 1 interval
   (3 codes)		+/- 3 interval
   (7 codes)		+/- 10 interval
   (21 codes)
PINPad Tokens+/- 2 interval
   (5 codes)		+/- 4 interval
   (9 codes)		+/- 10 interval
   (21 codes)
RSA SecurID Software Tokens+/- 10 interval
   (21 codes)		+/- 12 interval
   (25 codes)		+/- 70 interval
   (141 codes)
Resynchronization (any token)--------+/- 12 hours
   (1441 codes)


First use of token will use maximum limit for that type
Typical interval = 1 minute

 

Relationship between the token seed XML and the token synchronization range table



<DefSmallWin>Automatic Range
<DefMediumWin>Accept with Next Tokencode
<DefLargeWin>Maximum Limit

The DefSmallWin indicates the time interval when a user can successfully enter a tokencode without triggering next tokencode mode (+/- 1 interval or 3 codes).  For example, shown here is the UTC time for seven minutes, with the tokencode associated to that minute:
 
UTC Time16:2216:2316:2416:2516:2616:2716:28
Expected Tokencode196911231587654493201467947563114696678663
Offset-3-2-10+1+2+3

Let's look at some examples.  Here we are using the hardware token.  The Authentication Manager server host time is 16:25, the server will accept the three tokencodes for 16:24, 16:25 and 16:26, using the DefSmallWindow setting.  The three interval window allows for the tokencode of the server's correct time (+/-0) as well as the correct time one minute ahead of the perfect minute and one minute behind the perfect minute.

Both the DefMediumWin and DefLargeWin indicate longer time intervals when a user will be prompted for the next tokencode (NTC). If the token XML defines the DefMediumWindow synchronization value, the seven tokencodes from 16:22 to 16:28 will authenticate successfully.  Using DefLargeWindow, all 21 tokencodes between 16:15 and 16:25 would be accepted for authentication.  Any tokencode entered outside of the DefLargeWin range will fail an authentication.  This has nothing to do with invalid passcodes being entered by the user.
 
UTC Time16:1516:1616:1716:1816:1916:2016:2116:2216:2316:2416:2516:2616:2716:2816:2916:3016:3116:3216:3316:3416:35
Expected Tokencode102940290767040907140503010766121368110816196911231587654493201467947563114696678663308253314159174325325280303436260218520753
DefSmallWin-10-9-8-7-6-5-4-3-2-10+1+2+3+4+5+6+7+8+9+10
DefMediumWin-10-9-8-7-6-5-4-3-2-10+2+2+3+4+5+6+7+8+9+10
DefLargeWin-10-9-8-7-6-5-4-3-2-10+1+2+3+4+5+6+7+8+9+10


Any tokencode submitted that is outside of the DefLargeWin will fail an authentication.  This has nothing to do with invalid passcodes being entered by the user.
 
Next tokencode and token resynchronization will update the token offset value stored in the token record to ensure the token record remains in the Automatic Range (DefSmallWin) for subsequent authentications. Where the time has a difference of +/- 12 hours then the token offset cannot be updated and authentications will fail.
 
RSA recommends the use of the Network Time Protocol (NTP) with Authentication Manager instances to ensure the time remains stable.  This is because clock changes can impact the token offset, meaning end users are likely to be prompted for next tokencode during an authentication.  If there has been a big clock change (placing the token outside of the maximum limit) then authentications can fail.

Keep in mind that if the Authentication Manager services are restarted, all tokens revert to the DefLargeWindow value for that token type on service restart.  This means a token t hat was using the DefSmallWindow setting is set to DefLargeWindow, until  the user first authenticates.  Once the user authenticates, the setting returns to how it was configured.

Attachments

    Outcomes