h. Review the list of data that is migrated and not migrated. See Appendix A, Migrated Data and Appendix B, Non-Migrated Data.
2. Complete the setup tasks. See Pre-Migration Checklist on page 25.
3. Test the migration process, configure system settings, and more. See Chapter 3, Pre-Production and Testing Version 8.1.
4. When you are ready to put version 8.1 into production, perform the selected scenario.
• For Scenario 1 (Basic Migration with the Replica Instances Online), see Performing a Basic Migration with the Replica Instances Online on page 49.
• For Scenario 2 (Basic Migration with All Instances Offline), see Performing a Basic Migration with All Instances Offline on page 65.
• For Scenario 3 (Advanced Migration), see Performing an Advanced Migration on page 81.
5. Perform the post-migration tasks. See Chapter 7, Post-Migration Tasks.
1: Planning a Migration 13
Determine if You Can Upgrade the Hardware Appliance
Only some versions of the RSA SecurID Appliance 3.0 hardware can support an installation of Authentication Manager 8.1. To determine if you can upgrade and migrate on a particular appliance, use the following procedure.
Before You Begin
Enable SSH on the appliance. For instructions, see the Operations Console Help topic
“Enable SSH on the Appliance NIC.”
Procedure
1. Log on to the appliance operating system with SSH. For instructions, see “Log On to the Appliance Operating System with SSH” in the RSA Authentication
Manager 8.1 Administrator’s Guide.
2. At the command prompt, type the following:
-bash-3.00$ omreport chassis info
3. In the results, look for the value of Chassis Model. If the value is either of the following, you can migrate the appliance to version 8.1:
PowerEdge R210 PowerEdge R710
If the value is not one of these, you cannot migrate this appliance. Contact RSA Sales or your vendor to purchase new RSA Authentication Manager 8.1 appliance hardware.
Expertise Required for Migration
To complete a migration, an administrator must have the necessary knowledge to plan and execute the process. This topic summarizes the expertise that is required for administrators who plan or perform the migration.
Administrator Planning the Migration
The administrator planning the migration must understand the organization’s goals and needs to make decisions and select a migration path. Expertise is required in the following areas.
Authentication Manager 7.1 Deployment. Understand how the migration affects components such as authentication agents, replica instances, trusted realms, and RADIUS servers.
Network. Be familiar with your network and the overall affects of migration. See Factors that Affect Migration on page 14.
Testing Migration and Version 8.1 Features. Understand the deployment and features required in production.
Before testing migration and features in RSA Authentication Manager 8.1, consider what setup tasks are required and whether to transition the test environment into production.
14 1: Planning a Migration Migration Scenarios. Be familiar with the different scenarios and with the organization’s particular needs to lead the decision-making process.
– See Factors that Affect Migration on page 14.
– See Selecting a Migration Scenario on page 22.
– Review and understand the steps that apply to the selected migration scenario.
Setup and Post-Migration Tasks. Review the pre-migration and post-migration procedures. See Chapter 2, Setting Up for Migration, Chapter 3, Pre-Production and Testing Version 8.1, and Chapter 7, Post-Migration Tasks.
Migrated and Non-Migrated Data. Review which data is included or excluded from the migration. See Appendix A, Migrated Data and Appendix B,
Non-Migrated Data.
Administrator Performing the Migration
The administrator performing the migration should understand the following areas.
Authentication Manager 7.1 Deployment. Understand how the migration affects components such as authentication agents, replica instances, trusted realms, and RADIUS servers. See Factors that Affect Migration on page 14.
Testing Migration and Version 8.1. Understand the features being tested.
Network. Be familiar with your network and the overall affects of migration.
Selected Migration Scenario. Understand all required steps and how these steps affect the network and deployment.
Setup and Post-Migration Tasks. Review the setup and post-migration tasks.
Access and Permissions
The administrator performing the migration must have access to the RSA SecurID Appliance 3.0 to install the RSA Authentication Manager 7.1 Migration Export Utility. The administrator must also have permission to execute the installer shell script, and must run the utility as root user.
Factors that Affect Migration
It is important to understand how the following factors affect the migration process.
• Migration on Existing Hardware
• Pre-Production and Migration Import Options
• Authentication Agents
• Authentication Downtime
• Potential Data Loss
• Administrative Downtime
• Migration Time
1: Planning a Migration 15
Migration on Existing Hardware
Migrating data from version 7.1 to version 8.1 on existing RSA SecurID
Appliance 3.0 hardware requires that you overwrite the appliance with an installation of version 8.1. During this process, the original 7.1 installation and any data that is saved on the appliance is overwritten.
To reuse the RSA SecurID Appliance 3.0 hardware, the following steps are included in every migration scenario:
• You must back up the appliance with imaging software such as PING to ensure that you have the ability, if necessary, to roll back the migration process and return to the version 7.1 deployment. The version 8.1 installation overwrites version 7.1.
• You must download the RSA Authentication Manager 8.1 - Hardware Appliance Installer ISO file that is required for 8.1 installation from Download Central. For more information, see Chapter 2, Setting Up for Migration.
• If the version 7.1 deployment has multiple replica instances, you can create a test environment by removing a replica instance from your deployment and installing version 8.1 on the 7.1 replica appliance. You deploy the former replica instance as a primary instance with a unique hostname and IP address. These actions allow you to dedicate an appliance for testing without seriously affecting or creating conflicts with the current production environment.
When you perform a migration, you can preserve the settings that you configured during the testing period and transition this environment into production. For more information, see Pre-Production and Migration Import Options on page 16.
• If you do not want to test the migration process, during an actual migration, you must first create a temporary 8.1 primary instance from a version 7.1 replica instance to gradually migrate and upgrade your deployment. Although you export data from the version 7.1 primary instance, you do not install version 8.1 on the original 7.1 primary instance until the version 7.1 replica instances have been upgraded and attached to the version 8.1 primary instance.
• After you install 8.1 on the 7.1 primary appliance, you configure the instance as a replica and attach the instance to the 8.1 primary that you temporarily configured.
To recreate the exact deployment that you had in version 7.1, you promote this instance to become the 8.1 primary instance.
If you have a standalone primary deployment, you cannot test the migration or follow the steps that are documented in the migration scenario chapters. For instructions on migrating a standalone primary deployment, see Appendix E, Migrating a Standalone Primary Deployment.
16 1: Planning a Migration
Pre-Production and Migration Import Options
You can test the migration process and version 8.1 by creating a pre-production test environment from a version 7.1 replica appliance. To do this, you remove a version 7.1 replica instance from your deployment, install the appliance with version 8.1, and configure the appliance as an 8.1 primary instance. The test environment is given a unique hostname and IP address to avoid conflict with the 7.1 deployment that is in production.
You test version 8.1 with migrated data by exporting the migration package from version 7.1 without stopping services on the deployment. This data is then imported into the 8.1 testing environment.
When you are ready for the version 8.1 primary instance to enter production, you create a new migration package. This package includes data that version 7.1 collected while you were testing version 8.1.
When you import to the production environment, you can do the one of the following:
• Update version 8.1 with the latest data from version 7.1 and retain the system settings and deployment topology of version 8.1. This option preserves the overall setup that you tested, and you import data that was updated on version 7.1 during the testing period, such as user and token data. For a list of data that is retained and imported, see Appendix C, Retained and Imported Pre-Production Data.
• Completely remove existing data from version 8.1 to import the newly exported migration package from the 7.1 primary instance. This option loses the system settings that you migrated and configured during the testing period. All configured components, such as replica instances and web tiers, are lost.
If you retain any settings from the testing period, you obtain these benefits:
• You do not need to reconfigure the deployment and system settings when version 8.1 is in production.
• You can perform many essential setup tasks during the pre-production period that are required after migration. For example, because scheduled backup and restore settings are not migrated, you can apply these settings during pre-production. You can test the settings before production and save configuration time during
production. For a list of pre-production setup tasks that can be preserved during a migration, see Pre-Production Setup Tasks on page 41
1: Planning a Migration 17
Authentication Agents
After migration, each hardware appliance in your 8.1 deployment is configured with the same hostname and IP address that was set originally in version 7.1.
The test environment is initially given a different hostname and IP address. However, this network setting is temporary. During the migration, the hostname and IP address is changed to match its original 7.1 settings.
Because you are ultimately reusing the hostname and IP address of each version 7.1 instance, the migration scenarios as documented do not require that you update authentication agents. The agents that communicated with version 7.1 can automatically communicate with version 8.1. This ensures minimal or no authentication downtime for the 8.1 deployment.
Note: If you decide to use a different hostname and IP address, you must generate a new sdconf.rec file that contains the new IP address for version 8.1, and distribute the file to all agents. For more information, see the Administrator’s Guide.
After testing the migration process, you can retain the system settings and deployment topology of the test environment during the migration scenario. For more information about pre-production, see Pre-Production and Migration Import Options on page 16.
Authentication Downtime
Authentication downtime occurs in the following situations:
• When you export data from the primary instance with the Basic Migration (All Instances Offline) option. The 7.1 replica instances cannot authenticate users while the primary instance is offline.
• In a 7.1 standalone primary deployment, services on the primary instance are stopped during migration.
• The 7.1 RADIUS server uses a different IP address than the 8.1 instance. For example, this situation applies when version 7.1 includes a remote RSA RADIUS server.
RADIUS users cannot authenticate until you update RADIUS clients with the hostname, IP address, or both of version 8.1. For more information about updating RADIUS clients, see your RADIUS client documentation.
• After migration, trusted users cannot authenticate until reestablish trusted realm relationships with version 7.1 and 8.1 realms.
18 1: Planning a Migration To avoid or minimize authentication downtime in a replicated deployment, consider the following migration options:
• Basic Migration (Replica Instances Online): Exports data from the primary instance with stopped services. Services on the primary instance remain stopped after export. The replica instances are available to authenticate users; however, the authentication updates that are recorded by the replica instances are not migrated.
• Advanced Migration: Stops services on the primary instance to export data from the 7.1 deployment and allows you to eventually export authentication updates that occur on the replica instances while the primary instance is unavailable.
When you export data from an instance, services remain stopped on that instance after migration.
Potential Data Loss
Data may be lost when you migrate data from only the primary instance and do not migrate the authentication updates such as PIN and password changes that are recorded on the replica instances while the primary instance is unavailable. To avoid data loss, you can do one of the following:
• Perform a Basic Migration (All Instances Offline), which stops services on the replica instance.
• Perform an Advanced Migration, which exports data that accumulates on the replica instances while the primary instance is unavailable.
Administrative Downtime
Services stop on the 7.1 primary instance for all migration scenarios. Once the 8.1 primary instance is available, you can administer the system.
The following exceptions apply:
• Services do not stop when you are performing a test migration.
• While you can administer the system on the version 8.1 primary instance, users cannot authenticate until authentication agents can communicate with the 8.1 deployment
Migration Time
The time that it takes to migrate data depends on the size of your database, the hardware where version 7.1 is installed, and the operating system of version 7.1. If you have a large database or a slower system, the data migration may take some time.
Important: Migrate data at a time when users do not frequently authenticate, such as on a weekend.
1: Planning a Migration 19
RSA RADIUS Migration
In version 8.1, each Authentication Manager instance runs an RSA RADIUS server.
While data is migrated from a remote or local version 7.1 RADIUS server, the following data is not migrated:
• The configuration of a RADIUS server, including the server certificate or any trusted root certificate for a RADIUS server
• The configuration files (.conf,.ini,.aut)
• Remote RADIUS dictionary files
• Local RADIUS server authentication agent
• Administrative permission to view or edit RADIUS settings for administrators who are not Super Admins
If you want to include any of these non-migrated files or settings in version 8.1, you can perform RADIUS-related tasks after migration.
However, you can perform certain RADIUS-related tasks at pre-production while you test and setup version 8.1 and perform other tasks after migration.
• For a list of tasks that you can complete in pre-production, see RSA RADIUS on page 44. If you complete these tasks and decide to preserve pre-production settings during import, see the post-migration tasks listed in RSA RADIUS on page 105.
• If you decide to completely overwrite pre-production settings during your migration, see the post-migration tasks listed in RSA RADIUS on page 108.
For a complete list of data that is migrated and not migrated, see Appendix A, Migrated Data and Appendix B, Non-Migrated Data.
Migration of Multiple Realms from Version 7.1
In version 8.1, a realm is an organizational unit that includes all of the objects managed within a single deployment, such as users and user groups, tokens, password policies, and agents. In version 7.1, you can create multiple realms in a deployment and distribute your organizational hierarchy throughout these realms. However, version 8.1 does not support multiple realms within a single deployment. Each deployment has one realm that is automatically created when you set up version 8.1.
The version 7.1 hierarchy is migrated to version 8.1 as follows:
• Version 7.1 realms are converted into security domains under the version 8.1 top-level security domain, SystemDomain.
• Version 7.1 security domains are nested under the new security domains that were formerly version 7.1 realms.
20 1: Planning a Migration The following graphic shows how the migration preserves the management
relationships and the version 7.1 hierarchy.
When you migrate multiple realms, the following applies:
• Realm configuration and preference settings are not migrated. The 8.1 realm inherits the system settings and preferences from the 8.1 top-level security domain, the SystemDomain. For example, in version 7.1, settings such as security questions for Self-Service, RADIUS profile priority, default RADIUS profile, and user authentication requirements are configured per realm. However, in
version 8.1, these settings are configured in the system settings for the
deployment. These settings are migrated only from the default 7.1 realm that is created automatically at installation. They are not migrated from any realms that were subsequently added to version 7.1.
• External identity source users who were managed in the 7.1 realms that you added after installation are associated with the same subdomains after migration. These subdomains are nested under the newly converted security domain to preserve the same hierarchical relationships.
1: Planning a Migration 21
• If an external identity source user is in an added 7.1 realm and they were never managed in that realm, they are associated with the 8.1 top-level security domain (SystemDomain) after migration. In version 8.1, you can manually move these users to a lower-level security domain. You can also map external identity sources to security domains. This setting automatically moves users to the mapped domain when they are managed in Authentication Manager. For more information, see the chapter “Preparing for RSA Authentication Manager for Administration” in the RSA Authentication Manager 8.1 Administrator’s Guide and the Security Console Help topic “Add Default Security Domain Mappings.”
If any identity sources contain a duplicate User ID, authentication may not succeed. For more information, see the chapter “Administering Users” in the RSA Authentication Manager 8.1 Administrator’s Guide.
• Policies are only migrated from the 7.1 default realm. They are not migrated from any 7.1 realm that you created. If the policies associated with the 7.1 default realm are not in the top-level security domain (SystemDomain) and you need them in version 8.1, after migration, you must recreate the policies and assign them to the new security domains. If you do not recreate any custom policies, the security domains are automatically set with the 8.1 default policies.
• Administrative roles are only migrated from the 7.1 default realm. They are not migrated from any 7.1 realm that you created. Therefore, users who were administrators in an added version 7.1 realm are no longer administrators in version 8.1. After migration, you must create and assign administrative roles to the affected users.
For a complete list of data that is migrated and not migrated from the 7.1 realms, see Appendix A, Migrated Data and Appendix B, Non-Migrated Data.
22 1: Planning a Migration
Selecting a Migration Scenario
Use the following diagram to determine which migration scenario best fits your deployment and network.
In addition to migrating data from the primary instance , do you
want to migrate migration , can you afford authentication migrated data that can be
configured and transitioned into production ?
YES
See Chapter 3.
Test the migration process and version 8.1 until satisfied with the results. When you are ready to perform a migration that requires you to overwrite 7.1 with 8.1, continue with the workflow . See Appendix E
Are you migrating to 8.1 on existing RSA SecurID Appliance
3.0 hardware that is currently in production ?
See the RSA Authentication Manager 7.1 to 8.1 Migration Guide : Migrating to a New Hardware Appliance or Virtual Appliance
1: Planning a Migration 23 For more detailed information, see the appropriate reference.
For a high-level comparison of the scenarios, see Appendix E, Migrating a Standalone Primary Deployment.
Before you complete a migration scenario, perform any set up tasks. For more information, see Chapter 2, Setting Up for Migration.
Scenario Chapter
Scenario 1 (Basic Migration with the Replica Instances Online)
Chapter 4, Performing a Basic Migration with the Replica Instances Online Scenario 2 (Basic Migration with All
Instances Offline)
Chapter 5, Performing a Basic Migration with All Instances Offline
Scenario 3 (Advanced Migration) Chapter 6, Performing an Advanced Migration
2: Setting Up for Migration 25
2 Setting Up for Migration
Pre-Migration Checklist
Before you upgrade to RSA Authentication Manager 8.1, you need to prepare the RSA Authentication Manager 7.1 deployment for migration.
Determine if You Can Upgrade the Hardware Appliance
Before starting the migration process, you must determine if your existing hardware is eligible for an upgrade. Certain versions of the RSA SecurID
Before starting the migration process, you must determine if your existing hardware is eligible for an upgrade. Certain versions of the RSA SecurID