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

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

• Bio
• Latest Posts

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)

• MacOS Big Sur and SSLKEYFILELOG - November 23, 2021
• ClearPass, Azure AD, SSO and Object ID - August 12, 2021
• ClearPass – custom MPSK - July 20, 2021