Every time someone is trying to authenticate and login to the VPN it says previous tokencode used, I have watched them use the current token and it still shows up as previous tokencode used on the activity monitor. This continues until their token gets put into the next tokencode state where it is impossible to get them out of. Does anyone have any ideas on how to get this working again?
OK,
this can be because of a difference between hardware clock and the running clock
Check clocks/fix clocks
get on command line as rsaadmin
become root user with
sudo su -
and use rsaadmin password
as root
check clocks:
date
should report local time
date -u
should report exactly what actual UTC time is
hwclock
should match what date shows (local time)
----------------
If hwclock is what is inaccurate this can cause the issues you report
if this is vmware or hypervisor, make sure to set the HOST machine date and time to be accurate,
reboot, then check hwclock again
if hwclock is incorrect but date and date -u is correct, SET the hwclock to local time
hwclock -w
-->check primary and all replicas clocks<--
If you need to set the date and time itself,
date mmddhhhhyyyy
and you are setting this to your local time, not UTC time *(unless you are using utc timezone)
where
mm=month
dd=day
hhhh=24 hour clock + minutes
yyyy=year
Hey guys, thanks for the quick reply! Unfortunately I don't think it is going to be that easy, I had the sysadmin check into the server time and it is correct. Any other ideas?
Hello,
did the sysadmin check all three from the command line as root user ?
date
date -u
hwclock
The only time we have seen this problem is
a) high watermark as Jay described, but that is very rare
nowadays, it happened a lot on early version 7.1
and
b) hwclock time is not matching local time
------------------
Also, try re-synchronizing the token, if hwclock is a problem you won't be able to resync it.
FYI for users in NTC mode
You can clear NTC immediately by user, manage existing, go to a user authentication settings
and [clear incorrect passcodes]. This gets rid of NTC mode for that user tokens.
Now that is a handy piece of information! I didn't know you could auto clear NTC mode, that will save me a lot of time.
Yes I verified with her that she did check all 3.
Do you guys have any other ideas for this? I verified with the sysadmin she checked all 3 and that they were correct. Currently I am unable to get any new users setup with RSA.
You need to open a support case so we can take a deeper look. I am still betting on a clock issue. But, you need a case so we can dig into it.
I would try restarting the RSA services first, on the primary then any replicas. You do not need to reboot, just SSH in with PuTTy or CigWin with the Operating System Account, typically called rsaadmin, and password.
cd /opt/rsa/am/server
./rsaserv stop all
<wait until all Shutdown>
./rsaserv start all
The AM server considers a TokenCode as previously used, not by checking every tokencode possible from every minute in the past, but by checking the High Water Mark, HWM, which normally gets set after a successful authentication. Sometimes this HWM can get set in the future, e.g. in AM 8.2 no patches with a hardware clock set in the future. Restarting services clears HWM for all tokens. Might fix this.