000027095 - Explanation of Next Tokencode Mode and small  medium and large authentication windows in RSA SecurID authentication

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support on Aug 14, 2019
Version 5Show Document
  • View in full screen mode

Article Content

Article Number000027095
Applies ToRSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 8.x
O/S Version: SUSE
IssueThis article provides an explanation of how token seed files relate to when tokens go into next tokencode mode
Customer does not know why his token is going into next tokencode mode.

Next token mode occurs for the following reasons:


  1. The first time the token is used for authentication may require a resynchronzation
  2. The user has entered too many incorrect passcodes.
  3. The token presented to the Authentication Manager server is outside of the automatic acceptance range (typically this would be the currently expected tokencode, one previous tokencode and the next tokencode).
  4. The server cannot determine the tokencode, because a node secret does not exist between a multihomed or NATed agent, or there is a mismatched RADIUS shared secret.

Note that this can be caused by a delay between when the passcode was actually entered by the user and when the passcode was actually received by the Authentication Manager server.  For example,


  1. A user may be entering the passcode on a VPN client installed on their PC.
  2. The VPN client then communicates with a firewall.
  3. The firewall actually makes the authentication request on behalf of the user to the Authentication Manager server.

At any of these stages, there can be a delay, so in order to explain why a token went into next tokencode mode we need the following times:


  1. The time when the user actually entered the passcode into the VPN client, web page or agent and then pressed OK to send the passcode.
  2. An Authentication Activity report on the server which shows the timestamp of when the passcode was received by the server.
The small, medium and large windows are defined in the token seed XML file. These values can not be modified by the user and attempting to change them will cause the importing of the token file to fail.

If you look at the token seed file header then you will see:

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


  • The small window in seconds defines the range of codes that will be accepted with automatic acceptance
  • The medium window in seconds defines the range of codes that will force the token into next tokencode mode
  • The large window is used in the following cases:
    1. This is the first authentication attempt (after a server start); 
    2. The server has been restarted since the last login; 
    3. The token is in New PIN Mode (only set for native PIN token); 
    4. The token is in Next Tokencode Mode AND the client is a single-transaction client; 
    5. The token is in Next Tokencode ModeAND is processing a normal authentication packet; 
    6. This is the first authentication attempt with this token (can only be true for null pin token); or
    7. The user has entered a large number of incorrect passcodes.  To see the value of this setting, login to the  Security Console and navigate to Authentication > Policies > Token Policies > Manage Existing.  Select the correct policy and choose Edit.  Under Incorrect Passcodes, the value will be set to allow an unlimited number of incorrect passcodes or to require next tokencode after a defined number of incorrect passcodes.

For a SID800 token, the windows are typically defined as:

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



This corresponds to:


  • An automatic acceptance range of +/- 1 minute,
  • A Next Tokencode mode range of [-3,-2 ] and [2,3]
  • A large window of [-10, +10]

Software tokens also have these ranges defined, as in the examples below.  The first will allow the software token to behave like a hardware token.


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




In the example, the ranges are greatly increased, to allow for the device with a software token having somewhat incorrect time.






<DefSmallWin>630</DefSmallWin>
<DefMediumWin>4320</DefMediumWin>
<DefLargeWin>4320</DefLargeWin>



ResolutionTo modify the window values,
  1. First load the tokens into the Authentication Manager server.
  2. SSH to the primary server and login as the rsaadmin user.
  3. Navigate to /opt/rsa/am/utils.
  4. Run the rsa util store command, for example:  

./rsautil store -a add_config auth_manager.authmethod.st_small_window <number in seconds> Global 501
./rsautil store -a config auth_manager.authmethod.st_small_window <number in seconds> Global 501

 


In the sample below, the small window value was changed from the default of 60 seconds to 120 seconds:
 


login as: rsaadmin
Using keyboard-interactive authentication.
Password:
Last login: Wed Jan 4 11:09:50 2017 from jumphost.vcloud.local
RSA Authentication Manager Installation Directory: /opt/rsa/am
rsaadmin@am82p:~> cd /opt/rsa/am/utils
rsaadmin@am82p:/opt/rsa/am/utils> ./rsautil store -a add_config auth_manager.authmethod.st_small_window 120 Global 501
Please enter OC Administrator username: <enter name of Operations Console administrator>
Please enter OC Administrator password: <enter password for the Operations Console administrator> psql.bin:/tmp/51e5e785-2ec3-4ed0-bd1f-20442fc0be901743519977922809669.sql:108: NOTICE: Added the new configuration parameter "auth_manager.authmethod.st_small_window" with the value "120"
add_config
 ------------
(1 row)
rsaadmin@am81p:/opt/rsa/am/utils>



To change the medium or large window, change the command accordingly.
Legacy Article IDa62010

Attachments

    Outcomes