Resync tokens that have drifted
We seem to have random tokens in our Auth Manager that are assigned to users but will never successfully authenticate until they are resynced. Is there a command or db query I can use to find other tokens that have drifted and will need to be resynced before they can be used?
- Cloud Auth
- Cloud Authentication
- Cloud Authentication Service
- Community Thread
- Forum Thread
- RSA SecurID
- RSA SecurID Access
JAck, there is an rsautil for this. Here's an example of using the option to clear Next Token Code, NTC in bulk, so you can simply list to a file to look at token offset times.
Login SSH to the operating system as the rsaadmin
./rsautil sync-tokens -I (interactive)
Create an output file, and modify all tokens to clear NTC, (optionally clear lockouts too), but leave Token offset times unmodified (none)
You could vary this to not change anything, simply output to a text file and then cat or edit the file to view Token Offset times
If you can identity drifted tokens, or even if you cannot and are willing to try something, you could simply;
1. take a backup from the Ops console in case you screw this up
2. Use sync-tokens to clear all clock offsets, making them 0
3. restart AM services in order to give all tokens an initial plus or minus 10 minute acceptable Token Code window, this way the AM server can learn the token time, which should be very close to the correct time
Sounds too dangerous for a production environment. I am just looking to identify ones that have drifted too far to function correctly and then reset them if possible
OK , it doesn't have to be dangerous.
run rsautil sync-tokens in LIST mode first, and verify the output file completes to the end with no
errors inside it. this ensures if you run the tool in modify mode it will be able to modify all tokens and
not stop partway through and get stuck on some error.
Next, verify the RSA server themselves are dead-on accurate
on command line, date -u must always match actual UTC time
If they are on perfect time, it is not dangerous to run rsautil sync-tokens -I in modify mode
if you choose absolute clock, and zero offset.
this will correct 99.99% of token sync issues
and the only dropouts would be
-handheld keyfob tokens that have a large natural drift (old token might have a clock a few minutes off)
-software tokens running on devices that themselves have a bad clock (a windows laptop for example
with incorrect time)
If you do sync-tokens and set all offsets to zero, and reboot, after a full reboot the RSA server does a one time 10 minute grace period for each token....where the next authentication from any token can be up to 10 minutes ahead or behind, and the server will put in the offset of those tokens, and then shrink the 'window' back down to +-1 min for software tokens and +-3 for keyfobs.
It's only dangerous if you mess up! That's what the backup does here, CYA.
If you simply List, and not Modify, you can get the data you need. I don't recall if an AM report contains these token offset times, maybe they added it.