We have deployed our RSA SecurID Authentication Manager (AM) for using two factor authentication for our VPN clients, for securing inherently non secure protocols, making e-commerce safe, … whatever, but what if our AM fails? Well, we can recover from the backup, but this can take same time during which our clients won’t be able to authenticate.
So, we will setup a replica instance. This instance handles client authentication requests while primary instance is down. In order to be able to use a replica instance, our license has to allow this, network and system requirements should be met.
I’m not showing a primary instance installation here, because it is much more easy to do than the replica instance, and it basically boils down to the “next-next-finish” method.
I will assume that we have primary instance set up and running and is named rsa71.popravak.local, with the IP address of 22.214.171.124/24. We are doing this in virtual environment, of course.
We should follow these basic steps for installing and setting up a replica instance:
- Install and setup a primary instance
- From within Operations Console we generate a Replica Package
- We transfer the replica package to our replication instance server
- We install the replica instance
- Finally, we attach a replica instance to the primary
Note: we can create a Primary Instance Data file which contains all data from the primary instance, then ship this file to the replica instance to be used in the installation process. This we will do if we have large database and slow links, for example, and we want to transfer our data out of band. Of course, we can replicate this data from the primary instance during the installation of replica instance. Because we are in virtual environment and our “network connection” is very fast, we will use on line replication.
Once we have everything ready on our primary instance, we log in to Operations Console by browsing to https://rsa71.popravak.local:7072/operations-console.
We then generate a replica package:
For this operation we need to provide a Super User credentials. In our lab, these are the same as Administrator credentials we setup during installation of the primary instance:
Now we need to fill in some informations: the replica host name, the IP address, master password and the way of transferring the data from the primary instance. Then we click Generate File(s):
We then download the replica package rsa72-replica.pkg and transfer it to the replica instance virtual machine:
Now we log in to the replica instance (which is, by the way, a Windows 2008R2 server, same as the primary instance) and start the installation from the installation media.
We select Install Now >, then Next.
I’m from Europe, so I select the “You are a customer ordering this RSA product from RSA Security Ireland Limited, from Europe, Africa or Asia Pacific” option:
We accept the EULA and move on;
This is where the installation of the replica instance differs from the installation of the primary instance. We select the Replica Instance option and click Next:
The installation directory specification comes next:
Now just a quick verification of IP parameters:
We then specify a directory containing our license file:
Now we specify previously generated and downloaded replica package, and a master password:
We now click the Install button and wait for the installation to complete:
After installation has completed, we log to Operations Console on the replica instance, and attach the replica instance to the primary instance. We chose “Yes, use the replica package file stored on this server”, type in the master password and click Next:
Now the initial replication is performed. Depending on the database size, network connection and server characteristics, this can take some time. So, it’s time for a coffee 🙂
In my virtual lab with all default settings on the primary instance and 50 tokens, it took about 13 minutes. After clicking Done, we have the following screen on our replica instance:
Finally, if we go to the Operations Console on the primary instance, we can verify our topology as well:
Now we have a fully operational replica instance that can serve authentication requests in the case of a failure of the primary instance. Most of changes are still done on the primary instance and get replicated to the replica.
We can monitor a replication status through the Operations Console:
One final note: I would recommend disabling IPv6 on both primary and replica instances, because it can cause the connectivity issues. At least with the version 7.1 SP4, which I’m using.
We are now ready to make backups and test our recovery scenarios such as data loss, deletion or corruption, primary instance failure or replica instance failure. I hope it never comes to that, but we must be ready.
Thanks for reading!