Troubleshooting failed offline authentication on an RSA Authentication Agent 7.3 or 7.4 for Windows
4 years ago
Originally Published: 2019-02-26
Article Number
000051571
Applies To
RSA Product Set: SecurID
RSA Product/Service Type: Authentication Agent for Windows
RSA Version/Condition: 7.3.3, 7.4.1, 7.4.x
Issue
Many users report they cannot authenticate offline; either they fail repeatedly but somehow successfully authenticate later, or they authenticate in a different manner, either with an offline emergency passcode or with an unchallenged account and password.  In all cases this was not an issue with failure to download offline days, offline days were present.
 

To troubleshoot failures when downloading offline days, see 000033697 - How to troubleshoot and fix most invalid proof and failed to send day data errors on the RSA Authentication Agent 7.x for Windows.


The first symptom is found in the SIDAuthenticator(LogonUI).log on the Windows agent machine:
 
2018-12-27 14:42:45.674 20464.14248 [E] [CommonAuthenticator::performAutoRegistration] Auto registration cannot be performed because AM is unavailable.
2018-12-27 14:42:45.674 20464.14248 [V] [CommonAuthenticator::performOfflineAuthentication] Enter
2018-12-27 14:42:45.683 20464.14248 [V] [CommonAuthenticator::getSIDUsername (char version)] Enter
2018-12-27 14:43:01.867 20464.14248 [E] [CommonAuthenticator::performOfflineAuthentication] AceDACheck failed: SD_ERROR = 0x7d8
2018-12-27 14:43:01.867 20464.14248 [W] [CommonAuthenticator::performOfflineAuthentication] User attempted offline authentication and RSA_DA_AUTH_FAILED was returned.
Tasks
  • Check time on the Windows agent machine.
  • Check agent logs to determine if you need performance improvements such as the ones included in AAWIN-2510 (AAWIN 7.4.0[40] Slow offline OTP authentication blocks logon).  Improvements have been made to reduce the time needed to perform offline authentication in order to avoid blocking logon or unlock.
This KB is the right one for if the problem is an offline failed authtication even though there are still offline days, and not a problem with downloading offline days.  When the user later successfully connects to the Corp Network, either through VPN or by going to the office, the failed authentication logs will be uploaded onto the AM server and can be seen in authentication activity reports.  Assuming you see the authentication failures, and no specific details jump out, e.g. account locked, failed to resolve UserID, bad PIN but good TokenCode (for FOB style tokens, not PINPad Style), then we has to assume this user just entered a bad or incorrect Passcode. Often the users are entering the exact tokencode they see on their phone of token fob, and they are not making a typing mistake.  The Time on the PC when the PC is not connected to the VPN or Corp Net is the time used to determine which tokencodes are good - therefore if this PC time is wrong, a user entering good/correct Passcodes from a phone could fail offline authentication because the PC 'thinks' its time is correct therefore user Passcode is wrong.

This KB looks at the time on the PC, as well as the offset of the time in the two registry keys, one called LastTimeOffset and the other called ServerTimeOffset, under HKEY_LOCAL_MACHINE\SOFTWARE\RSA\RSA Authentication Agent\CurrentVersion\Local\OASVC:

Larger numbers would indicate time fluctuations.

try to identify or list these some of the users with the problem, have these users check their PC time and registry offset when offline, if problem is repeatable you could set verbose logging on those PCs and get the logs to RSA Support.  Also run an authentication activity report for those users during the offline times, to see what report says.
Resolution
  1. The first thing to check when an offline authentication fails for incorrect passcode is the time on the agent. Many Windows agents are configured to get time from a domain controller, but when the user travels home or to a hotel, obviously, the DC is not available and time can drift on the Windows agent.  There are two registry keys, one called LastTimeOffset and the other called ServerTimeOffset, under HKEY_LOCAL_MACHINE\SOFTWARE\RSA\RSA Authentication Agent\CurrentVersion\Local\OASVC:
Registry_offsets2
 
These entries show the time difference offset seen on the agent from the Authentication Manager server time. The .log file should show approximately the same offset number.

A larger number, above 180 seconds, could indicate a big enough drift from the time on the server (known as good time) and the Windows agent time, which could push the tokencode on a hardware token or software token that has accurate and good time to be considered wrong or out-of-date when compared against the offline tokencodes stored on a Windows agent with incorrect time.  Consider changing the time source on the Windows agent to internet NTP as a fix.
  1. If the time offsets appear small and the Windows agent time appears good, note the Windows agent version in the RSA Control Center  under Help > Help About.
HelpAbout-Version

Engineering has found that Microsoft has changed the encryption on newer Windows platforms, so that it takes an RSA longer (up to 90 seconds or more) to decrypt the locally stored offline day token files before it can even verify a tokencode.  This could be enough of a delay to cause a tokencode that was good when it was entered to expire by the time the agent can verify it.  Engineering incorporated new performance improvements to prevent this type of failure in the RSA Authentication Agent 7.4.2[22] for Windows and later.  The snippets of logs in the Notes section below shows this delay of two minutes from the time the agent determined to challenge this user and determined passcode was therefore not valid:
 
2018-12-27 14:40:56  getChallengeType has determined that the user is challenged.
(which is after UserID and Passcode were entered) until it was determined this tokencode was before the High Water Mark,  
2018-12-27 14:42:58  DaSvcAceDaCheckProc::processDayfiles() - Tokencode reuse attack
2018-12-27 14:43:01  User attempted offline authentication and RSA_DA_AUTH_FAILED was returned.

The resolution is to update the existing agent to RSA Authentication Agent 7.4.2[22] for Windows or later.  This is listed in the release notes as fixed in defect AAWIN-2510.
Notes
===SIDAuthenticator(LogonUI).log===
2018-12-27 14:40:54.230 20464.14248 [I] [LACPolicies::getChallengeGroupSAMNamePolicy] The Challenge Group sAMAccountName policy is .\RsaLocalAdmin
2018-12-27 14:40:56.890 20464.14248 [I] [LACAuthenticator::isChallenged] getChallengeType has determined that the user is challenged.
2018-12-27 14:42:04.200  Auto registration cannot be performed because AM is unavailable
2018-12-27 14:42:18.799  AceDACheck succeeded.
=======DAService(da_svc).log========
2018-12-27 14:42:14.523 ::findToken: starts. looking for "0004099xxxxx" (DO NOT add) 
2018-12-27 14:42:16.216  HashedPasscode::match: trying time=1041000120 (offset 0) 
2018-12-27 14:42:16.946  HashedPasscode::match: ends.  matched=YES 

2018-12-27 14:42:55.985 ::findToken: starts. looking for "0004099xxxxx" (DO NOT add) 
2018-12-27 14:42:57.723 5212.5232 [I] HashedPasscode::match: ends.  matched=NO 
2018-12-27 14:42:57.723 5212.5232 [I] HashedPasscode::match: trying time=1041000120 (offset 0) 
2018-12-27 14:42:58.474 5212.5232 [I] HashedPasscode::match: ends.  matched=YES 
2018-12-27 14:42:58.474 5212.5232 [I] DaSvcAceDaCheckProc::processDayfiles() - match found at window Offset = -1 
2018-12-27 14:42:58.474 5212.5232 [I] DaSvcAceDaCheckProc::processDayfiles() - Tokencode reuse attack 
===SIDAuthenticator(LogonUI).log===
2018-12-27 14:43:01.867  AceDACheck failed: SD_ERROR = 0x7d8
2018-12-27 14:43:01.867  User attempted offline authentication and RSA_DA_AUTH_FAILED was returned.
2018-12-27 14:43:27.923  Auto registration cannot be performed because AM is unavailable.
2018-12-27 14:43:42.495  AceDACheck succeeded.
 
Don't see what you're looking for?