000033697 - How to troubleshoot and fix most invalid proof and failed to send day data errors on the RSA Authentication Agent for Windows

Document created by RSA Customer Support Employee on Aug 15, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 4Show Document
  • View in full screen mode

Article Content

Article Number000033697
Applies ToRSA Product Set: SecurID
RSA Product/Service Type: Authentication Agent for Windows
RSA Version/Condition: 7.2.1
  • Invalid Proof and Failed to send day data error messages display in the Real Time Activity Log, sometimes repeating every two seconds from the same Windows agent.  For example, 
Offline authentication data download requested by user 'user' from agent 'agent' using token '000099999999' failed with error message 'Invalid proof'


Offline Authentication Data Download Failed.  Invalid proof of authentication data provided by the agent

  • The DAService (da_svc).log will show the following errors.
DaSvcProofDownloader::process() exiting: DPS_DA_REQUEST_DATABASE_ERROR (212)



  • The /opt/rsa/am/server/logs/imsTrace.log would have evidence of delays for offline authentication; for example, OA day download ‘waited’ some number of seconds.
  • The server.cer has already been verified or replaced on all agents.
  • Agent installs have been updated to Windows Agent 7.2.1 build 101 (7.2.1 [101]).
CauseThere are several bugs affecting Offline authentication (OA) or Disconnected Authentication (DA) dayfile downloads that have been fixed in the latest Authentication Agent for Windows version 7.3.1 [40], released 3 August 2016.
 * * * 

To troubleshoot invalid proofs, we need the /opt/rsa/am/server/logs/imsTrace.log files from the primary and from all replicas.  Additionally, we will need verbose logging from the agent capturing activity from that side of the authentication request.  Steps to gather this information is below.

There are quite a few reasons to see invalid proof when offline download data fails.  These include:
  1. A server.cer from the agent installation that is wrong/corrupt or bad.
  2. Using an alias during authentication instead of the real user ID.
  3. The Agent Offline Authentication Local service is not running.
  4. Overlapping identity sources so that the same user appears in more than one identity source, whether it be two external sources or an external source and the internal database.
  5. Bugs in agent builds from versions below 7.2.1 [98], but seen once with a customer who appeared to have 7.2.1 [101].  A reinstall with an Engineering build of 7.2.1 [101] fixed this; so there could have been some old .dll files left on agent.
  6. OA Policy restrictions.  For example, a user has a PINless token and PINless tokens are not enabled under your OA policy.
  7. There are legitimate reasons for invalid proof errors.  For example, you authenticate to the network and download offline days then stay logged in to the same session.  At midnight UTC the agent will automatically send a request to the server for a set of offline day files to augment the ones on the agent.  If you have remained connected to the network for more than 24 hours, the original proof will have expired.  This typically happens at the agent's second attempt to download OA days.
Some invalid proof messages are legitimate.  As a background, when you successfully authenticate, a proof is created and presented to the OA service requesting to download OA days.  So, invalid proof means something is not quite right with the proof from the successful authentication.
The proof is generated and stored on the Windows agent when you successfully authenticate; that is, where you can reach the primary or replica.   Invalid proof is when the Authentication Manager server won't download offline days to the agent because something is wrong with the proof, Reasons for an invalid proof include, but are not limited to, the following:
  • The proof is expired, which will happen if you authenticated more than 24 hours ago;
  • The request may not have been sent from the agent to the Authentication Manager server; for example if TCP 5580 port is blocked by a firewall; or
  • The RSA Local Offline service not running.
Logging out of the session and re-authenticating would generate a new proof.  So would a test authentication from the same token.
After the invalid proof message is seen, complete the following steps:

  1. Note the date and time.
  2. Download the  imsTrace.log files from the primary and replica(s).  Note that if the imsTrace.log files are large, there can be more than one.  Some will have numbers in the file name.  There can be up to 30 of them.
  3. Logon to the Authentication Mnaager primary via local console or SSH session using the rsaadmin account.
  4. Navigate to /opt/rsa/am/server/logs.
  5. List the directory contents.
  6. Copy all imsTrace*.log files to /tmp.
    login as: rsaadmin
    Using keyboard-interactive authentication.
    Password: <enter operating system password>
    Last login: Tue Aug  9 12:29:10 2016 from jumphost.vcloud.local
    RSA Authentication Manager Installation Directory: /opt/rsa/am
    rsaadmin@am81p:~> cd /opt/rsa/am/server/logs
    rsaadmin@am81p:/opt/rsa/am/server/logs> ls -al imsTrace.*
    -rw------- 1 rsaadmin rsaadmin 32497 Aug  2 15:56 imsTrace.log
    rsaadmin@am81p:/opt/rsa/am/server/logs> cp imsTrace*.log /tmp

  7. Use a secure copy client such as WinSCP or FileZilla to connect with same operating system account, and copy the imsTrace.log from /tmp to your PC.
ResolutionThe quickest and best fix for this issue is to download and install the latest Authentication Agent for Windows version 7.3.1 [40], released 3 August 2016.
WorkaroundAs workarounds for this issue, try to:
  1. Restart the Offline Local service on the agent;
  2. Authenticate again with a passcode.  For example, lock the screen then unlock using a passcode.  Do not use the quick unlock option of a password or PIN only; 
  3. From a command prompt on the Windows agent, run RSA Authentication Agent Auto-registration (sdadmreg.exe -r).

Enabling verbose logging on an RSA Authentication Agent for Windows

  1. On the Windows agent access the RSA Control Center interface.  You probably need administrator rights for this.  
  2. From Home, select Advanced Tools.
  3. Select Tracing.
  4. Set Trace Level to Verbose.
  5. Trace logs are written to C:\ProgramData\RSA\LogFiles folder by default.  Click Browse to change the location.
  6. For Components, check the Select All box.. 
LAC verbose logging


Enabling verbose logging on an RSA Authentication Manager server

  1. From the Security Console, select Setup > System Settings.
  2. Under Basic Settings, click Logging.
  3. Set the Trace Log value to Verbose.
  4. Click Save.

 * * * 

There are also some Authentication Manager server-side performance fixes for sites with tens of thousands of Windows agents, call Customer Support for more information or update to Authentication Manager 8.2 patch 1 or later.