Hi, we are using RSA Authentication Manager version 8.2.1 and hardware token SID700. One of our user's token switch to next token code mode like 2 times per month. Every time it happened we manually resynchronize token through Security Console. User normally enter correct token code when this happen. My question is how can we minimize the frequency of switching to next token code mode for that user?. Any setup we need to change in RSA Authentication Manager?
Thank you in advance.
Junxia
I've moved your question to the RSA SecurID Access space where it will be seen by the product's support engineers, other customers and partners. Please bookmark this page and use it when you have product-specific questions.
Alternatively, from the RSA Customer Support page, click on Ask A Question on the blue navigation bar and choose Ask A Product Related Question. From there, scroll to RSA SecurID Access and click Ask A Question. That way your question will appear in the correct space.
Regards,
Erica
Thank you for your information
Hello,
some ideas here... these are some things I'd check if this was occurring
The assumption is the RSA servers are 100% perfect replication and time and date always stable, and the problem is the user or token....
--------------------
First you need to verify the time and replication on the RSA servers is always accurate and remains accurate. If using NTP you need to verify your NTP sources are valid and 100% correct as well.
and collect information....
1) verify the RSA servers all primaries and replicas, that replication status remains normal
2) verify on command line of all RSA servers, that these three clocks always remain consistent
date -u
should be always accurate to UTC. this is the most important clock
date
this just needs to show whatever local timezone you have
hwclock
this needs to report what date command shows
------------
OK assuming the RSA servers are all rock solid on time and replication, focus on that user and token next
3) resynchronize the token in the security console
4) now check that token 'natural time offset'
run rsautil sync-tokens -I command, in list mode, to list all tokens and the time offsets they have, find the serial number of the problem token and note it's offset after you just resynced it.
example:
rsaadmin@edavis-vm150:/opt/rsa/am/utils> ./rsautil sync-tokens -I
Authenticator Bulk Synchronization Utility 8.3.0.5.0 (1404545)
Copyright (C) 1994-2018 Dell Inc. or its subsidiaries. All Rights Reserved.
Enter the absolute path for the output report file : /tmp/sync-check.txt
Enter the base security domain name for recursive search [(none)]:
Enter the type of token selection [ (all) | file ]: all
Choose a token filter [ assigned | unassigned | (both) ]: both
What action do you wish to perform? [ (list) | modify ]: list
Enter administrator user ID : admin
Enter administrative password : *********
Authenticator Bulk Synchronization Utility 8.3.0.5.0 (1404545)
Copyright (C) 1994-2018 Dell Inc. or its subsidiaries. All Rights Reserved.
Started job on Thu Nov 29 10:41:14 EST 2018 with ID = ims.710dd7e19663650a11b1580a5241e4c4
Now I check the output file for my token 000159871817.
This token has a -1 time offset. The token is behind actual time by 1 minute with it's internal sealed clock.
rsaadmin@edavis-vm150:/opt/rsa/am/utils> cat /tmp/sync-check.txt | grep 871817
000159871817 -1 false Wed Nov 28 14:38:42 EST 2018 Unlocked SystemDomain Tue Jun 29 20:00:00 EDT 2021 Tue Jun 29 20:00:00 EDT 2021
----------------------------
Now, normal operations.... until problems occur again for this user.
5) Immediately check rsautil sync-tokens in list mode, and see what the offset for the token is now.
Has it changed much ?
6) resync the token in security console, now list token offsets again. Is it the same as in (5) or (4) ?
if you get unexpected offset jumps, or this token offset drifts more than other tokens, the token itself may have a bad internal clock and it is drifting too far between the times it is used.
RSA server can track tokens with wild clocks, but only if the token is used often enough so the RSA server can track it's offset +3 or -3 from actual time. If it drifts further between uses, that will force next tokencode mode.
7) If the token offsets appear fairly stable, then you need to check what the user is doing and examine the authentication activity report for this user, and determine how often they fail to login successfully, because a bad passcode counter will trigger next tokencode mode eventually even if the token is accurate.
In summary: If you have a bunch of users, and only 1 having issue, chances are the token itself might have a wild clock,and the info above can help reveal if the token or user is the issue. If the RSA servers time is not always accurate or replication issues are happening, that must be remedied first... but also other users would be having problems as well if the RSA servers were having a bad day.
*If this is due to some issue on the user end and triggered by bad passcode counters, you could create a special policy just for this one user and increase the limit of bad passcodes before forcing next tokencode mode.
Thank you for your reply. It's really helpful.
Hello,
some ideas here... these are some things I'd check if this was occurring
The assumption is the RSA servers are 100% perfect replication and time and date always stable, and the problem is the user or token....
--------------------
First you need to verify the time and replication on the RSA servers is always accurate and remains accurate. If using NTP you need to verify your NTP sources are valid and 100% correct as well.
and collect information....
1) verify the RSA servers all primaries and replicas, that replication status remains normal
2) verify on command line of all RSA servers, that these three clocks always remain consistent
date -u
should be always accurate to UTC. this is the most important clock
date
this just needs to show whatever local timezone you have
hwclock
this needs to report what date command shows
------------
OK assuming the RSA servers are all rock solid on time and replication, focus on that user and token next
3) resynchronize the token in the security console
4) now check that token 'natural time offset'
run rsautil sync-tokens -I command, in list mode, to list all tokens and the time offsets they have, find the serial number of the problem token and note it's offset after you just resynced it.
example:
rsaadmin@edavis-vm150:/opt/rsa/am/utils> ./rsautil sync-tokens -I
Authenticator Bulk Synchronization Utility 8.3.0.5.0 (1404545)
Copyright (C) 1994-2018 Dell Inc. or its subsidiaries. All Rights Reserved.
Enter the absolute path for the output report file : /tmp/sync-check.txt
Enter the base security domain name for recursive search [(none)]:
Enter the type of token selection [ (all) | file ]: all
Choose a token filter [ assigned | unassigned | (both) ]: both
What action do you wish to perform? [ (list) | modify ]: list
Enter administrator user ID : admin
Enter administrative password : *********
Authenticator Bulk Synchronization Utility 8.3.0.5.0 (1404545)
Copyright (C) 1994-2018 Dell Inc. or its subsidiaries. All Rights Reserved.
Started job on Thu Nov 29 10:41:14 EST 2018 with ID = ims.710dd7e19663650a11b1580a5241e4c4
Now I check the output file for my token 000159871817.
This token has a -1 time offset. The token is behind actual time by 1 minute with it's internal sealed clock.
rsaadmin@edavis-vm150:/opt/rsa/am/utils> cat /tmp/sync-check.txt | grep 871817
000159871817 -1 false Wed Nov 28 14:38:42 EST 2018 Unlocked SystemDomain Tue Jun 29 20:00:00 EDT 2021 Tue Jun 29 20:00:00 EDT 2021
----------------------------
Now, normal operations.... until problems occur again for this user.
5) Immediately check rsautil sync-tokens in list mode, and see what the offset for the token is now.
Has it changed much ?
6) resync the token in security console, now list token offsets again. Is it the same as in (5) or (4) ?
if you get unexpected offset jumps, or this token offset drifts more than other tokens, the token itself may have a bad internal clock and it is drifting too far between the times it is used.
RSA server can track tokens with wild clocks, but only if the token is used often enough so the RSA server can track it's offset +3 or -3 from actual time. If it drifts further between uses, that will force next tokencode mode.
7) If the token offsets appear fairly stable, then you need to check what the user is doing and examine the authentication activity report for this user, and determine how often they fail to login successfully, because a bad passcode counter will trigger next tokencode mode eventually even if the token is accurate.
In summary: If you have a bunch of users, and only 1 having issue, chances are the token itself might have a wild clock,and the info above can help reveal if the token or user is the issue. If the RSA servers time is not always accurate or replication issues are happening, that must be remedied first... but also other users would be having problems as well if the RSA servers were having a bad day.
*If this is due to some issue on the user end and triggered by bad passcode counters, you could create a special policy just for this one user and increase the limit of bad passcodes before forcing next tokencode mode.