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:
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:
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;
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:
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.
Using two-factor authentication is common when publishing remote services to the internet with components like Citrix NetScaler or Juniper SA appliances. RSA is a well-known provider of two-factor authentication mechanism.
Beginning with RSA Authentication Manager 7.1 people have the ability to use the On-Demand feature. This feature enables the delivery of token codes via SMS or e-mail. When using this feature you had to publish the RSA Self-Service website to the internet, so users can request a token code. The RSA Self-Service website is displayed below.
The procedure for opening a extra website to request an On-Demand token is difficult to understand for many people and increases the risk of problems and errors during the authentication process.
This behavior is changed in RSA AM 7.1SP3. With SP3 the Authentication Agent has possibility to generate the On-Demand token request on behalf of the user. The procedure to login to the Authenticaton Agent is:
This way the delivery of token codes is less prone to problems and errors during the authentication process. I personally like this new feature.