|Applies To||Software token going into next token code mode unexpectedly|
|Issue||Explanation of how the 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 3 common reasons
1) the first use of a token requires a resynchronzation
2) The user has entered too many incorrect passcodes
3) The token presented to the AM server is outside of the automatic acceptance range (typically the previous token code, the expected tokencode and the next tokencode)
4) The server cannot determine the tokencode, because of no Node Secret with a Multihomed or NATed agent, or mismatched RADIUS Shared secret
Note this can be caused by a delay between when the passcode was actually entered by the user, to when the passcode was actually received by the Authentication Manager server.
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 token code mode we need the following times:
1) The time of 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 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:
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:
a) This is first login (after server start) OR
b) The server has been restarted since the last login OR
c) Token is in new pin mode (only set for native pin token) OR
d) Token is in next tokencode AND client is single-transaction OR
e) Token is in next tokencode AND processing a normal authentication packet OR
f) First login (can only be true for null pin token)
g) User has entered a large number of incorrect passcodes
For a SID800 token the windows are typically defined as:
This corresponds to an automatic acceptance range of + / - 1 minute
A Next Token Code mode range of [-3,-2 ] and [2,3]
And a large window mode of [-10, +10]
Soft Tokens also have these ranges defined.
Two examples are:
This will cause the soft token to behave like a standard hardware token
Here we can see that the ranges are greatly increased, to allow for the device with a software token having somewhat incorrect time .
Note, these values are based on the token seed records, and cannot be changed
|Legacy Article ID||a62010|