000030063 - Access to historical v7.1 logs and data after migration to v8.1

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

Article Content

Article Number000030063
Applies ToRSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 7.1
Platform: any
Platform (Other): any
O/S Version: any
Product Name: null
Product Description: null
IssueAfter migration from RSA Authentication Manager (AM) v7.1 to v8.x, a customer may need to be able to access historical data for potential future fraud investigations or other reason.
There are three main categories of data to consider:
  • Activity (audit) logs
  • Technical logs
  • Database (e.g. identities and tokens)
TasksThe inability to restore a backup from  v7.1 to v8.x does not mean the data is entirely inaccessible. 
As explained in detail below, activity (audit) logs can be copied from a backup location and accessed from any text editor or spreadsheet tool. Technical logs and database data however must be restored to a server or appliance, as applicable, running a compatible operating system.



Activity Logs

RSA Authentication Manager Activity (audit) logs can be opened and read on any machine (e.g. a Windows PC) and do not require the old RSA AM v7.1 system to be present to do that. 
There are three different activity logs. In RSA AM v7.1, a Recurring Log Archive Job can be used to copy the log data to a simple local text file on the AM primary. 
Security Console archive activity log menu
From there, you can use your own method to regularly backup these to a remote archive location for long term storage, and clean out the backed up logs from RSA AM. The three logs that are handled this way are: 
  • Authentication Activity Log. Stores authentication-specific events, such as authentication requests and restricted agent access checks. 
  • System Activity Log. Stores system events, such as data replication. 
  • Administrator Activity Log. Stores administrator activities, such as creating and updating system administrators, assigning tokens to users, etc. 
Even after migration, the archived copies of these logs can be copied from the remote archive location, opened and read on any machine (e.g. using Notepad or MIcrosoft Excel on a Windows PC) .  This does not require the old RSA AM v7.1 system to be present.
Just before final shutdown of AM v7.1 primary, special steps would be required to save the last set of activity logs: 
  1. Create and run a One-Time Log Archive job, that will save all activity from the database to disk for all three logs. 
  2. Run your own backup job/utility to copy all archived activity logs to your remote archive location. 
Note that the usual jobs that do these two tasks may not act upon the very latest data/files. Consequently, job adjustments would probably be required for this final run to ensure it copies ALL data/files, and not just older data/files. 

Technical Logs 

All other RSA AM logs are internal technical/troubleshooting logs - the sort of logs RSA Support normally ask for when we are working on a technical problem for you. These can be optionally backed up as part of RSA AM's backup of the internal database. 
Operations Console menu for configuration of backups
If technical logs are not backed up, obviously they cannot be restored. If they are backed up by RSA AM with the database, they can only be restored with the data, as described in the Data section below. 


All data (e.g. Identities and Tokens) in RSA AM are stored on the internal database and when backed up, are secured using the master password. If you are required to save and possibly access such data then you will need to maintain a system that a backup can be restored to, and obviously, take a final backup before shutting down your AM 7.1 primary permanently. Below are listed the restore limitations for RSA Authentication Manager Server  (from the RSA Authentication Manager 7.1 Administrator’s Guide Revision 4, p. 224). The data cannot be restored to RSA AM v8.1. 
  • The backup instance and the restore instance must be running the same operating system.  For Windows, the instances can be running different versions of the Windows operating system. For example, you can back up the database on a Windows 2003 system, and restore the backup to a Windows 2008 system. 
  • The backup system and the restore system must run operating systems that use the same architecture (32-bit or 64-bit).  For example, if you are restoring the database to an Authentication Manager instance running on 64-bit Solaris, the back up must come from an Authentication Manager instance running on 64-bit Solaris. 
  • The Authentication Manager deployments must be the same type, either standalone or replicated. A backup made on an Authentication Manager deployment with a standalone primary cannot be restored to a replicated deployment. 
  • When you restore the database, you must use the same master password you used to create the backup. This is true even if the master password is changed after the backup. 
The restore instance for an RSA Authentication Manager Appliance must likewise be equivalent to the backup instance.