• The first time the token is used for authentication it may require resynchronization.
• The user has entered too many incorrect tokencodes or passcodes.
• The token presented to the RSA Authentication Manager server is outside of the automatic acceptance range. Typically, this would be the expected tokencode, +/- one tokencode from the current time.
• The tokencode that you sent is a correct code, but becomes decrypted incorrectly, and the Authentication Manager server treats it like a failed code. Some reasons for this may be:
  
  • A node secret does not exist between a multihomed or NATed agent,
  • A mismatched RADIUS shared secret,
  • The authentication agent needs an IP address override configured to force the agent to encrypt traffic to the Authentication Manager server with a specific IP address. 

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

1. The specific time that the user entered the passcode into the VPN client, web page, or agent and pressed OK to send the passcode.
2. An Authentication Activity report on the server which shows the timestamp when the server received the passcode.

These values cannot be modified in the xml file. Attempting to change them will cause the importing of the token file to fail.

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

• The small window, in seconds, defines the range of codes that are accepted with automatic acceptance.
• The medium window, in seconds, defines the range of codes that force the token into Next Tokencode Mode.
• The large window is used in the following cases:
  
  • This is the first authentication attempt (after a server start); 
  • The server has been restarted since the last login; 
  • The token is in New PIN Mode (only set for native PIN token); 
  • The token is in Next Tokencode Mode AND the client is a single-transaction client; 
  • The token is in Next Tokencode Mode AND is processing a normal authentication packet; 
  • This is the first authentication attempt with this token (can only be true for null pin token); or
  • The user has entered too many incorrect passcodes. To see the value of this setting, login to the Security Console and browse 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.

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

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

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

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

Troubleshooting tasks

1. Check the version of the RSA Authentication Manager software that is installed on 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.
2. Check replication status between the primary instance and each replica instance(s). Replication failing can cause a problem with end user authentications.
3. Check the time difference between the primary instance and replica instance(s). There should not be a difference of more than one to two minutes between any Authentication Manager instances.
4. When checking time, use command line and note there are three system clocks to check:

• date -u     This checks UTC time and should always be actual UTC time, regardless of time zone. This is the most important clock.
• date         This should report local time based on time zone, if a time zone is selected.
• hwclock   hwclock should report the same as the date command [local time]. If not, it can be set using hwclock -w and checking again.

5. Run an authentication activity report and check to see which end user(s) are constantly being prompted for a next tokencode.
6. 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 servers. Should it be seen that most of the authentications are coming from one agent, a review of the agent configuration may be required, with further authentication testing.

End users entering incorrect passcodes

Understanding the token synchronization range

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

Token synchronization range table

First use of token uses the maximum limit for that type. Typical interval = 1 minute

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

This CLU can never increase the time windows beyond the seed record, they can only decrease or 'tighten up' the acceptable tokencode time windows. This CLU was developed because many years ago software tokens were running on more unreliable system clocks (old PC motherboards, systems without NTP. Smartphones did not exist with accurate clocks or there were other things in the network which could delay the tokencode from arriving at the RSA server, so RSA sometimes shipped out software token seed records with very large small-med-large windows that are no longer relevant if you have a network with accurate time. These large windows allow more successful authentications on unreliable system clocks or ones without NTP. By being able to override the acceptable tokencode windows, the system can be made more secure when you have accurate time on the Authentication Manager server and the user device running the software token, and do not require large default values.
 

A. Example of a seed record that has narrow timing

B. Example of a seed record that has very wide timing (good for unreliable networks or very old systems with no NTP)

To edit time intervals for RSA SecurID software token seeds

1. First load the tokens into the Authentication Manager server.
2. SSH to the primary server and login as the rsaadmin user.
3. Go to /opt/rsa/am/utils.
4. Run one of the rsautil store command to either add or update the configuration; for example:  

• auth_manager.authmethod.st_small_window: between 1 and the default INTERVAL value that is derived from token record seconds value
• auth_manager.authmethod.st_medium_window: between 10 and the default INTERVAL value that is derived from token record seconds value
• auth_manager.authmethod.st_large_window: between 10 and the default value INTERVAL value that is derived from token record seconds value

1. If smaller than the minimum, use the minimum.
2. If greater than the default value, use the default.