Configuration Example, Security

Restore RSA 7.1 primary database and RADIUS config

René Jorissen on June 30, 2010 2 Comments • Tags: #configutil #database #instance #ondemand #primary #radius #replica #restore #rsa #rsautil

A few days ago I was troubleshooting a problem with an ISA array after upgrading the VMware environment as you can read in this article. I had a same kind of problem with a RSA environment. After upgrading the VMware Tools and the Virtual Hardware, the RSA database didn’t start anymore. RSA noticed to much changes on the guest host, so we had to revert back to the “old” virtual machine.

To upgrade the VMware Tools and the Virtual Hardware I had to install a new server and restore the RSA primary database on the new server. The process for restoring the primary database can also be found in the RSA Administrator’s Guide.

There are two methods to restore the primary database:

  1. 1. Restore the database directly to the primary instance;
  2. 2. Promote a replica instance to be the new primary instance and restore the database to this primary instance;

I decided to use the first method, since we didn’t use a replica instance, and started installing a new server. I installed the new server under VMware. After the pre-installation I moved the server to another VLAN (port-group). I changed the hostname and the IP address of the new server to exactly the same hostname and IP address of the “live” RSA server. Next I installed a RSA AM7.1 SP2 primary instance with its default settings.

On the “live” RSA server I opened the RSA Operation Console to create a backup of the primary database (Maintenance – Backups – Create Backup).

rsa_backupThe backup process creates 3 separate files. This files need to be copied to the newly installed server. The *.dmp file is the file which contains the actual database configuration and is the most important. To restore the database on the new server, I had to take the following steps:

  1. 1. Remove all replica instances: Operations Console – Deployment Configuration – Instances – Manage Existing;
  2. 2. Stop all Authentication Manager Services on the server;
  3. 3. Restart the internal database: RSA Authentication Manager Database Server and RSA Authentication Manager Database Listener;
  4. 4. Open a new command prompt and change directories to %RSA_install_root%\utils;
  5. 5. Remove the primary database: rsautil setup-replication –a remove-primary;
  6. 6. Import the files into the database: rsautil manage-backups –a import –D –f absolute path, where absolute path is the absolute path and filename of the backup file, like C:\RSA_Backup\DB_Backup.dmp;
  7. 7. Reset the primary metadata: rsautil setup-replication –a set-primary;
  8. 8. Start the Authentication Manager primary instance;

The above steps help you restore the RSA database, but you still need to restore the RADIUS configuration separately. To restore the RADIUS configuration you first need to backup the RADIUS configuration from the “live” server. Creating a backup of the RADIUS configuration is very straightforward. You just need to copy the directory %RSA_install_root%\radius. To restore the RADIUS configuration on the new server, I had to take the following steps;

  1. 1. Stop the RADIUS server and make sure the RSA Authentication Manager is running: RSA Radius Server 7.1;
  2. 2. Overwrite the existing RADIUS installation directory with the backup data;
  3. 3. On the new RADIUS server, open a new command prompt and change directories to %RSA_install_root%\config;
  4. 4. Restore the RADIUS configuration: configUtil.cmd configure radius finalize-radius-restore;

The RADIUS server service is restarted automatically after executing the command above. After restoring the primary database and the RADIUS configuration you can shutdown the “live” server and change the network configuration (port-group assignment within VMware). The new server should be working directly. At least, it did for me.

If your configuration consists for one or more replica instances, you should perform the following steps for each replica instance:

  1. 1. On the primary instance, in the Operations Console, generate a replica package for all replica instances: Deployment Configuration – Instances – Generate Replica Package;
  2. 2. On the replica instance, in the Operations Console, provide the location of the replica package generated in the previous step;
  3. 3. On the replica instance, in the Operation Console, attach the replica instance: when the replica instance is successfully attached, all services on the replica are restarted;

If you use the On-Demand feature and you publish the RSA Self-Service portal via the reverse proxy solution, like a Microsoft ISA server, you should pay extra attention to the certificate chain configuration. The new server uses a different self-signed root certificate to sign the SSL certificate of the RSA Self-Service webpage. You need to import the new root certificate on the reverse proxy server and you should be ready to go.

Once I tried to restore the primary database with the second method (promoting replica to primary). This method wasn’t easy in my opinion and resulted in multiple error messages and an unsuccessful migration. I like the first method, because it is very straightforward and there isn’t a lot of downtime.

The following two tabs change content below.

René Jorissen

Co-owner and Solution Specialist at 4IP Solutions
René Jorissen works as Solution Specialist for 4IP in the Netherlands. Network Infrastructures are the primary focus. René works with equipment of multiple vendors, like Cisco, Aruba Networks, FortiNet, HP Networking, Juniper Networks, RSA SecurID, AeroHive, Microsoft and many more. René is Aruba Certified Edge Expert (ACEX #26), Aruba Certified Mobility Expert (ACMX #438), Aruba Certified ClearPass Expert (ACCX #725), Aruba Certified Design Expert (ACDX #760), CCNP R&S, FCNSP and Certified Ethical Hacker (CEF) certified. You can follow René on Twitter and LinkedIn.

Latest posts by René Jorissen (see all)

  1. Amer says:

    Another easy way to fix it this is from RSA site

    RSA Authentication Manager 7.1
    Microsoft Windows 2003
    Redhat Linux Advanced Server 4.0
    rsautil manage-secrets -a recover


    VMWare ESX 3.5
    Authentication Manager startup fails
    Error: Failed to load encrypted data.
    Caused by: System was modified beyond the allowed threshold, cannot decrypt.

    Error: System was modified beyond the allowed threshold, cannot decrypt.

    changed motherboard authentication manager won’t start
    changed hardware authentication manager won’t start
    Changed or upgraded virtual hardware on a virtual machine
    rsautil manage-secrets -a recover
    The underlying operating system (RHEL4) was updated from update 6 to update 7.

    A single CPU was changed to an SMP kernel.

    During the installation of Authentication Manager 7.1 a series of keys and passwords are created, these are secured in a file which itself is encrypted.  The system is able to decrypt the contents of this file because the encrypt/decrypt key is derived from certain “fingerprint” elements from the hardware.  If a number of hardware components are modified then this fingerprint changes and the file cannot be decrypted and most of the Authentication Manager processes will fail to start.

    The fingerprint is made from obtaining values from 7 system components, this error will occur when more than 2 were changed at the same time.

    RSA Authentication Manager is designed to allow for hardware alterations; if only two changes occur then the system will accept the remaining five as valid and re-encrypt using the new seven values, if more than two alterations are going to occur then the administrator must intervene to manually restore the encrypted file store after the hardware changes


    Restore the system by stopping all of the RSA Authentication Manager Server (on Linux or UNIX you can run the /server/rsaam stop all script) then running rsautil manage-secrets -a recover command from the utils directory.  For example:



            # ./rsautil manage-secrets -a recover

            Enter Master Password:********

            Machine fingerprint restored successfully.




            C:\Program Files\RSA Security\RSA Authentication Manager\utils> rsautil manage-secrets -a recover

            Enter Master Password:********

            Machine fingerprint restored successfully.

            C:\Program Files\RSA Security\RSA Authentication Manager\utils> rsautil manage-secrets -a recover


    The encrypted file store is decrypted using the master password instead of the system key as it had not been encrypted with this new value and then re-encrypted with the new system key value.


    The server will then start correctly although RSA Customer Support recommends a complete server restart is most appropriate to ensure a smooth startup of all services. 

    After the system has restarted you should test

     access to the RSA Operations Console (connect to https://:7072/operations-console ).  If this fails remove the file from utils/etc and run rsautil manage-oc-administrators -a reload.

  2. Another interesting article about repairing RSA if it doesn’t start anymore:

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.