Article Content
Article Number | 000029685 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Applies To | RSA Product Set: SecurID RSA Product/Service Type: Authentication Manager RSA Version/Condition: 8.1 and above | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Issue | This article provides an explanation of how values in the RSA SecurID software token seed files are related to when tokens go into Next Tokencode Mode. It also explains why a token may be going into Next Tokencode Mode. Tokens go into Next Tokencode Mode for one or more of the following reasons:
The server request for the next tokencode can be due to a delay between when the user entered the passcode and when the Authentication Manager server received the passcode. For example,
At any stage in this process, there can be a delay, so in order to explain why a token went into Next Tokencode Mode we need the following times:
These values cannot be modified in the xml file. Attempting to change them will cause the importing of the token file to fail. If you look at the token seed file header, the following text is shown:
For a SID800 token, the windows are typically defined as:
This corresponds to:
Software tokens also have these ranges that are predefined, as in the examples below. The first allows the software token to behave like a hardware token.
In the example here, the predefined ranges are greatly increased. This allows for a device with a software token installed to have somewhat incorrect time.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Tasks | Troubleshooting tasks
The command hwclock is used between replicas to verify the high watermark of tokencodes. In the past, on some earlier version of Authentication Manager 8.2.x, the system could set this incorrectly and you would sometimes see passcode already used errors. This issue was fixed in later Authentication Manager 8.2.x patches.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Resolution | End users entering incorrect passcodesEnd users entering incorrect passcodes can invoke Next Tokencode Mode. Updating the Token Policy setting of Incorrect Passcodes allows users to enter a limited or unlimited number of incorrect passcodes. When the limit is exceeded and then followed by a correct passcode, users are prompted to enter the next tokencode that is displayed on their token. See Chapter 4 of the RSA Authentication Manager Administrator's Guide for your version of the software for steps on how to update the Token Policy setting.
|
Token Type | Automatic Range | Accept with Next Tokencode | Maximum 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 uses the 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 Time | 16:22 | 16:23 | 16:24 | 16:25 | 16:26 | 16:27 | 16:28 |
Expected Tokencode | 196911 | 231587 | 654493 | 201467 | 947563 | 114696 | 678663 |
Offset | -3 | -2 | -1 | 0 | +1 | +2 | +3 |
Let us look at some examples. Here we are using the hardware token. The Authentication Manager server host time is 16:25, the server accepts 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 authenticate successfully. Using DefLargeWindow, all 21 tokencodes between 16:15 and 16:25 would be accepted for authentication. Any tokencode that is outside of the DefLargeWin range fails authentication. This has nothing to do with invalid passcodes entered by the user.
UTC Time | 16:15 | 16:16 | 16:17 | 16:18 | 16:19 | 16:20 | 16:21 | 16:22 | 16:23 | 16:24 | 16:25 | 16:26 | 16:27 | 16:28 | 16:29 | 16:30 | 16:31 | 16:32 | 16:33 | 16:34 | 16:35 |
Expected Tokencode | 102940 | 290767 | 040907 | 140503 | 010766 | 121368 | 110816 | 196911 | 231587 | 654493 | 201467 | 947563 | 114696 | 678663 | 308253 | 314159 | 174325 | 325280 | 303436 | 260218 | 520753 |
DefSmallWin | -10 | -9 | -8 | -7 | -6 | -5 | -4 | -3 | -2 | -1 | 0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +10 |
DefMediumWin | -10 | -9 | -8 | -7 | -6 | -5 | -4 | -3 | -2 | -1 | 0 | +2 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +10 |
DefLargeWin | -10 | -9 | -8 | -7 | -6 | -5 | -4 | -3 | -2 | -1 | 0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +10 |
Any tokencode submitted that is outside of the DefLargeWin fails authentication. This has nothing to do with invalid passcodes entered by the user.
Next tokencode and token resynchronization will update the token offset value that is stored in the token record to ensure that the token record remains in the Automatic Range (DefSmallWin) for subsequent authentications. Where the time has a difference of +/- 12 hours, the token offset cannot be updated and authentications fail.
RSA recommends the use of the Network Time Protocol (NTP) with Authentication Manager instances to ensure that 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 significant 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 that 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.
To modify the window values, for software tokens only, you can add or change values in the ims_config_value table in the database using a command-line utility.
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
Window | Timing |
---|---|
<DefSmallWin>60</DefSmallWin> | 120 seconds or 3 intervals |
<DefMediumWin>120</DefMediumWin> | 120 seconds or 3 intervals |
<DefLargeWin>600</DefLargeWin> | 600 seconds or 10 intervals |
B. Example of a seed record that has very wide timing (good for unreliable networks or very old systems with no NTP)
Window | Timing |
---|---|
<DefSmallWin>660</DefSmallWin> | 11 intervals |
<DefMediumWin>4320</DefMediumWin> | 72 intervals |
<DefLargeWin>4800</DefLargeWin> | 80 intervals |
In particular, the CLU described below was designed to 'tighten up' seed values with large windows such as in example B. On reliable networks with reliable time, you may not need to have 72 or 80 possible tokencodes in order to get one valid code sent.
To edit time intervals for RSA SecurID software token seeds
- First load the tokens into the Authentication Manager server.
- SSH to the primary server and login as the rsaadmin user.
- Go to /opt/rsa/am/utils.
- Run one of the rsautil store command to either add or update the configuration; for example:
./rsautil store -a update_config auth_manager.authmethod.st_small_window INTERVAL Global 501
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 3 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 "3"
add_config
------------
(1 row)
rsaadmin@am81p:/opt/rsa/am/utils>
To change the medium or large window, change the command accordingly, using the examples below.
Use one of the add_config commands below to create these for the first time, or update_config and you are updating the existing value. By default the database does not have windows predefined in the tables, it is based on original seed records imported.
./rsautil store -a update_config auth_manager.authmethod.st_small_window INTERVAL Global 501
./rsautil store -a update_config auth_manager.authmethod.st_medium_window INTERVAL Global 501
./rsautil store -a update_config auth_manager.authmethod.st_large_window INTERVAL Global 501
Regarding the INTERVAL value in the command above, do not use the same exact numbers as seen in the XML file. The number that you use for INTERVAL is relative to the tokencode display interval, not seconds. For example, if the command-line INTERVAL is 10, that means 600 seconds for a 60 seconds token (10 minutes, 10 codes), but 300 for a 30 seconds token (5 minutes, 10 codes). The 30/60 second tokencode display can be changed in some software token profiles before a software token is distributed. Divide the number of seconds from the seed record by 60 for a 1-minute interval token, or 30 for a 30-second interval token to determine how many total intervals exist (and these would be the maximum number interval that you can use on the command-line tool).
This CLU change only affects software tokens. Additionally, this will work only if the number of intervals picked is changed to one smaller than the default XML file intervals (that are contained within the seconds seen in a seed record). See Notes for more information about choosing correct interval numbers for the command-line tool. The tool can tighten up the acceptable codes it cannot increase them.
To undo changes in the database from the command-line utility and restore system defaults
- Access the postgres database command line (see 0000277335 - Connecting to or querying the database using pgSQL in RSA Authentication Manager 8.x for more information).
- You can delete changes using the commands below to restore settings to default:
DELETE FROM ims_config_value WHERE name LIKE'%auth_manager.authmethod.st_medium_window%';
DELETE FROM ims_config_value WHERE name LIKE '%auth_manager.authmethod.st_small_window%';
DELETE FROM ims_config_metadata WHERE name LIKE '%auth_manager.authmethod.st_large_window%';
DELETE FROM ims_config_metadata WHERE name LIKE '%auth_manager.authmethod.st_medium_window%';
DELETE FROM ims_config_metadata WHERE name LIKE '%auth_manager.authmethod.st_small_window%';
- 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
Only a number changed to smaller than what is in the default XML file will work. For example, if the seed for the software token has this in the XML file and the tokencode display interval is 60 seconds:
Window | Timing |
---|---|
<DefSmallWin>1200</DefSmallWin> | 3 intervals |
<DefMediumWin>600</DefMediumWin> | 10 intervals |
<DefLargeWin>1200</DefLargeWin> | 20 intervals |
And you run this command:
./rsautil store -a update_config auth_manager.authmethod.st_medium_window 20 Global 501
./rsautil store -a update_config auth_manager.authmethod.st_large_window 20 Global 501
Since 12 is greater than 3 (that is, 120 divided by 60 or 120/60), it uses 3 (120/60) for the authentication windows, not 12. Similarly, it uses 10 (600/60) for a medium window and 20 (1200/60) for a large window, not those you set in the configuration value.
Remember, this affects all software tokens, so if you have deployed 30-second interval tokens, they will behave differently to these interval numbers you choose, than a 60-second interval token.
When invalid values are set, it is adjusted based on following rules during authentication:
- If smaller than the minimum, use the minimum.
- If greater than the default value, use the default.