It’s time to move to RSA SecurID Authentication Manager 8

Not long time ago, EMC released the brand new version of Authentication Manager (AM). There is a major shift in this release – it is now a virtual appliance based on SLES11. This appliance can be deployed in our vSphere infrastructure.

Beside this, we now have something called a “Web Tier“. It is placed in the DMZ and is used for accessing the AM from the Internet and hence providing additional layer of security for our AM infrastructure. This way an AM provides a new way of authentication called RBA (“Risk-Based Authentication“).

Hardware and software tokens, seed records, authentication agents, realms, … It’s all more or less the same.

To migrate our 7.x AM to 8.0, follow these steps:

1. Download the installation and license files
2. Deploy and set up the primary appliance
3. Deploy and set up the replica appliance
4. Migrate our 7.x or 6.x data

Before we move on, here are some system requirements that need to be met:

• Hypervisor can be ESXi 4.1 or above
• For virtual appliance we need to have: 8GB vRAM, 2vCPU, 100GB thick provisioned vHDD

1. Download the installation and license files

For starters, we need to download our virtual appliance and a license files from RSA/EMC site. We can use an evaluation license or have our present license converted to a new format. For this we need to have a valid SCOL account.

2. Deploying and setting the primary appliance

Same as with previous version, we can have one primary instance and up to fifteen replicas. I believe those are correct numbers. To begin our deployment we start a “Deploy OVF Template” wizard:

And then locate an OVA file:

After reviewing an EULA, we select a location to power a deployed template on. We can specify a cluster and a host within a cluster:

Now we specify a datastore to hold virtual machine. Have in mind that the appliance has two disks. One of 4 GB and one of 100GB in size. Both are thick provisioned, so we need to make sure that we have enough free space on a datastore:

This appliance uses only one virtual network adapter. We choose appropriate port group for our deployment:

Next, we need to specify standard IP parameters: IP address and mask, default gateway and DNS servers:

After making sure all settings are ok, we can finish this wizard and power on a virtual machine.

In the “Recent Tasks” pane we can watch a deployment progress.

Now in the console windows we can watch a setup progress:

Please note a white-squared hash value. This value is a SHA1 hash of the certificate used for SSL connection between our browser and the appliance. This hash value is presented to us in a so called out of band way. First time we connect to our appliance, using our browser, we should compare a certificate hash value sent by the appliance to that presented to us in the console:

Because this is our primary instance, we select “Start Primary Quick Setup“:

Then simply click “Start Step 1“:

Now we select a ZIP file containing our license and click Upload:

Because it is a critical that the time on the appliances is synchronized with the token time, we must synchronize time in some way. Way have an option to sync with the ESXi host, or use the time servers:

The rsaadmin account is used to access the operating system itself. In this case it’s SLES Linux 11 SP1. Please remember this password:

The “Security Console Super Admin” and “Operations Console (OC) Administrator” have the same roles as in previous version of AM. Also, don’t forget these passwords:

Before starting a deployment, we can quickly review our settings and click “Start Configuration“:

This is our progress window:

And this is what we would like to see:

At this point we have our primary replica deployed.

 

3. Deploying and setting the replica appliance

We start deploying our replica instance by generating a replica package. We select “Deployment Configuration->Instances->Generate Replica Package“:

And we save this package some place handy:

Now we deploy the replica appliance using the same steps as for primary appliance. When we log in to the replica appliance for the first time, we click the “Start Replica Quick Setup“:

Click “Start Step 1“:

Make sure the time is correct:

And type in the operating system password:

Review the configuration and start deployment:

And after a while this is what we want to see. Now by clicking “Begin Attach“, we start a process of joining this replica instance to the primary:

We chose a replica package file:

Then provide an “Operations Console Administrator Credentials” password:

And the attachment begins:

And after replication is performed, we have a success window opened:

Finally, from the “Replication Status Report” we can see if the attachment and replication were successful:

 

4. Migrate our 7.x or 6.x data

This a final step that can be broken into three sub-steps:

• Installing the export utility on our existing AM instance
• Exporting our data
• Importing the data into new AM system

First let me say that this blog is about migrating AM version 7.x to AM 8.0. Perhaps the steps for migrating from AM 6.x are the same but I actually did not perform them.

In addition to this, the version of old AM must be the latest, that is 7.4. Further more, we need to have the export utility version aligned to the version of AM we are exporting data from.

Finally, there are many paths of going from 7.x to 8.0 but I will deal only with one here. For example, we could retain AM 7.x along side with the 8.0. In this case we must generate the new “sdconf.rec” file and reconfigure our agents. Or we could take over the AM 7.x identity and remove it from the network. In this case the new AM takes place and we don’t need to reconfigure our agents. Please refer to the documentation on specific migration option.

In the ZIP file we downloaded from the site, we can find and install the migration utility on the primary instance.

In the folder “RSA Authentication Manager 7.1 Migration Export Utility“, we will find three files: migration-installer.cmd, migration-installer.jar and migration-installer.sh. For the Windows version of AM, we only need the first two, so we place them in the folder on our Windows RSA server and start the migration-installer.cmd. Please make sure that the migration-installed.jar file has to be in the same folder.

The installation folder is straight forward. We click Next:

Accept the EULA:

Select the installation folder:

And wait for installation to complete:

Now we start the application and begin the export process:

We must know the master password to access the database:

This is where we decide if we want to export for testing and keep the existing AM or we export for production and remove the old AM. We will keep the old AM for now. We can always come back here and export for production:

We could export the logs if we consider them important. This will make our export file bigger:

This password is used to protect the exported data while the file is stored on a hard drive:

Now we begin the export process:

After a while, the process is completed:

In the following dialog we can see our next steps:

Now it’s time to log on to our new primary replica’s Operations Console and select “Deployment Configuration->Migration->From AM 7.1->Import 7.1 Migration Package“:

Then we select the migration package. We select the generated package and provide a password we used to protect the package:

Finally, we must confirm that we know what we are doing:

After a while we should see that the migration process is completed:

At this point we can start using our new AM 8.0 server the same way we used to with the 7.x version.

One final hint: after importing an AM 7.1 data, user names and passwords previously entered during installation of AM 8.0, such as Operations Administrator Console, are no longer valid and we must use the old credentials.

I hope you will enjoy using this product.

Thanks for reading!