Resync tokens that have drifted

[JackAlexander]

Hi

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?

Thanks

[JayGuillette]

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

                cd /opt/rsa/am/utils

                ./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

[JackAlexander]

Thanks, are the rsautils documented anywhere?

[JayGuillette]

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

[JackAlexander]

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

[EdwardDavis]

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.

[JayGuillette]

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.

[JayGuillette]

PS, what Ed said...

[JackAlexander]

Thanks for the info, are the rsautils documented anywhere that you can link me to please?

[EdwardDavis]

Some functions of rsautil are in the Help menu on the Security Console. Other functions are not documented.