Troubleshooting failed offline authentication on an RSA Authentication Agent 7.3 or 7.4 for Windows

[#1]

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.

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:

Image description
 

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.

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

Image description

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.