h12280 Am8 Migration Guide 7.1 PDF

RSA
Authenti cati on Manager 7.1 to 8.1

Mi grati on Gui de:
Upgrading RSA SecurID Appliance 3.0
On Existing Hardware
Copyright 19942013 EMC Corporation. All Rights Reserved. Published in the U.S.A.
December 2013
Contact Information
Go to the RSA corporate website for regional Customer Support telephone and fax numbers:
www.emc.com/domains/rsa/index.htm
Trademarks
RSA, the RSA Logo and EMC are either registered trademarks or trademarks of EMC Corporation in the United States and/or
other countries. All other trademarks used herein are the property of their respective owners. For a list of RSA trademarks, go
to www.emc.com/legal/emc-corporation-trademarks.htm#rsa.
License Agreement
This software and the associated documentation are proprietary and confidential to EMC, are furnished under license, and
may be used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice
below. This software and the documentation, and any copies thereof, may not be provided or otherwise made available to any
other person.
No title to or ownership of the software or documentation or any intellectual property rights thereto is hereby transferred. Any
unauthorized use or reproduction of this software and the documentation may be subject to civil and/or criminal liability.
This software is subject to change without notice and should not be construed as a commitment by EMC.
Third-Party Licenses
This product may include software developed by parties other than RSA. The text of the license agreements applicable to
third-party software in this product may be viewed on the product documentation page on RSA SecurCare Online. By using
this product, a user of this product agrees to be fully bound by terms of the license agreements.
Note on Encryption Technologies
This product may contain encryption technology. Many countries prohibit or restrict the use, import, or export of encryption
technologies, and current use, import, and export regulations should be followed when using, importing or exporting this
product.
Distribution
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO
REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS
PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Contents 3
RSA Authentication Manager 7.1 to 8.1 Migration Guide
Contents
Preface................................................................................................................................... 7
About This Guide................................................................................................................ 7
RSA
Authentication Manager 8.1 Documentation........................................................... 7

Related Documentation....................................................................................................... 8
Support and Service............................................................................................................ 9
Before You Call Customer Support............................................................................. 9
Chapter 1: Planning a Migration...........................................................................11
Introduction........................................................................................................................11
Reviewing the Migration Process......................................................................................11
Determine if You Can Upgrade the Hardware Appliance................................................ 13
Expertise Required for Migration..................................................................................... 13
Administrator Planning the Migration....................................................................... 13
Administrator Performing the Migration................................................................... 14
Access and Permissions............................................................................................. 14
Factors that Affect Migration............................................................................................ 14
Migration on Existing Hardware............................................................................... 15
Pre-Production and Migration Import Options.......................................................... 16
Authentication Agents............................................................................................... 17
Authentication Downtime.......................................................................................... 17
Potential Data Loss.................................................................................................... 18
Administrative Downtime.......................................................................................... 18
Migration Time.......................................................................................................... 18
RSA RADIUS Migration.................................................................................................. 19
Migration of Multiple Realms from Version 7.1.............................................................. 19
Selecting a Migration Scenario......................................................................................... 22
Chapter 2: Setting Up for Migration .................................................................. 25
Pre-Migration Checklist.................................................................................................... 25
Migration Export Utility Installation................................................................................ 28
Install the Migration Export Utility........................................................................... 29
Chapter 3: Pre-Production and Testing Version 8.1............................... 31
Pre-Production.................................................................................................................. 31
Migration Package............................................................................................................ 33
Testing the Migration........................................................................................................ 33
Create a Backup Image of the Hardware Appliance......................................................... 34
Install RSA Authentication Manager 8.1 on the RSA SecurID Appliance 3.0................ 35
Export Data from the Primary Instance............................................................................ 36
Import Data to RSA Authentication Manager 8.1..................................................... 38
4 Contents
Pre-Production Setup Tasks.............................................................................................. 41
Deployment Configuration........................................................................................ 41
System Configuration................................................................................................ 42
RSA RADIUS............................................................................................................ 44
Authentication............................................................................................................ 45
Self-Service................................................................................................................ 46
Authentication Agents............................................................................................... 47
Reporting................................................................................................................... 47
Application Programming Interface Update..................................................................... 47
Selected Migration Scenario............................................................................................. 48
Chapter 4: Performing a Basic Migration with the
Replica Instances Online......................................................................................... 49
Scenario 1: Basic Migration with the Replica Instances Online....................................... 49
Migration After Pre-Production Testing.................................................................... 51
Performing a Basic Migration with the Replica Instances Online.................................... 52
Export Data....................................................................................................................... 56
Import Data to RSA Authentication Manager 8.1............................................................ 58
Change the Hostname and IP Address of the Primary Instance....................................... 61
Additional Tasks for a Changed Hostname and IP Address on the
Version8.1 Primary Instance.................................................................................. 64
Chapter 5: Performing a Basic Migration with
All Instances Offline.................................................................................................... 65
Scenario 2: Basic Migration with All Instances Offline................................................... 65
Performing a Basic Migration with All Instances Offline................................................ 68
Export Data....................................................................................................................... 72
Import Data to RSA Authentication Manager 8.1............................................................ 75
Contents 5
Chapter 6: Performing an Advanced Migration......................................... 81
Scenario 3: Advanced Migration...................................................................................... 81
Performing an Advanced Migration................................................................................. 84
Export Data....................................................................................................................... 88
Import a Migration Package from the Version 7.1 Primary Instance............................... 91
Export Authentication Updates from a Replica Instance.................................................. 98
Import a Migration Package from a Version7.1 Replica Instance................................. 100
Chapter 7: Post-Migration Tasks ...................................................................... 103
Post-Migration Tasks When Version 8.1 Settings Are Retained During Import............ 103
Deployment Configuration...................................................................................... 104
Administration......................................................................................................... 104
RSA RADIUS.......................................................................................................... 105
Authentication Agents............................................................................................. 105
Reporting................................................................................................................. 106
Self-Service.............................................................................................................. 106
Post-Migration Tasks When the Version 8.1 Database is Completely Overwritten
During Import............................................................................................................... 107
Deployment Configuration...................................................................................... 107
RSA RADIUS.......................................................................................................... 108
Authentication...........................................................................................................110
Authentication Agents..............................................................................................111
System Configuration...............................................................................................112
Self-Service...............................................................................................................114
Administration..........................................................................................................115
Reporting..................................................................................................................116
Reestablishing Trusted Realm Relationships...................................................................116
Reestablish a Trust with a Version 7.1 Realm..........................................................117
Repair a Trust with a Version 8.1 Trusted Realm....................................................119
Reconfigure Converted Version 7.1 Realms After Migration........................................ 120
Administrative Role Permissions in Version 8.1............................................................ 121
Copy the RADIUS Dictionary Files............................................................................... 122
Update the E-mail Notification Template After Migrating from Version 7.1................ 122
Configure the Approved Software Token Notification Template After Migration........ 123
6 Contents
Appendix A: Migrated Data................................................................................... 125
Migrated Data................................................................................................................. 125
Authentication Updates Migrated from a Version 7.1 Replica Instance................. 131
Appendix B: Non-Migrated Data........................................................................ 133
Data That is Not Migrated.............................................................................................. 133
Appendix C: Retained and Imported Pre-Production Data............... 139
Retained Version 8.1 Data.............................................................................................. 139
Imported Data from Version 7.1..................................................................................... 141
Appendix D: Restoring a Hardware Appliance ........................................ 143
Consequences of Restoring a Hardware Appliance........................................................ 143
Rolling Back to an RSA Authentication Manager 7.1 Deployment............................... 144
Restore an Image on the Hardware Appliance................................................................ 144
Rolling Back Trusted Realm Relationships.................................................................... 145
Reestablish a Trust with a Version 7.1 Realm......................................................... 145
Reestablish a Trust with a Version 8.1 Realm......................................................... 146
Roll Back an Advanced Migration Using a Command Line.......................................... 147
Uninstall the Migration Export Utility............................................................................ 148
Appendix E: Migrating a Standalone Primary Deployment .............. 151
Performing a Basic Migration on a Standalone Primary Deployment............................ 151
Export Data..................................................................................................................... 152
Create a Backup Image of an Existing Hardware Appliance.......................................... 154
Install RSA Authentication Manager 8.1 on the RSA SecurID Appliance 3.0.............. 155
Import Data to RSA Authentication Manager 8.1.......................................................... 156
Appendix F: Troubleshooting Migration...................................................... 161
Migration Export Utility Logs........................................................................................ 161
Resolve Import Errors..................................................................................................... 161
Migration Results............................................................................................................ 162
Migration Report............................................................................................................. 163
Download Troubleshooting Files.................................................................................... 164
Access the Migration Report When the RSA Runtime Server is Stopped..................... 166
Appendix G: Summary of Migration Scenarios ....................................... 167
Migration Scenarios........................................................................................................ 167
Glossary ........................................................................................................................... 169
Index ................................................................................................................................... 179
Preface 7
Preface
About This Guide
This guide describes how to migrate RSA
Authentication Manager 7.1 and upgrade

to RSA Authentication Manager 8.1 on existing RSA SecurID Appliance 3.0
hardware. It is intended for administrators and other trusted personnel. Do not make
this guide available to the general user population.
If you want to migrate to RSA Authentication Manager 8.1 on a new hardware or
virtual appliance, see the RSA Authentication Manager 7.1 to 8.1 Migration Guide:
Migrating to a New Hardware Appliance or Virtual Appliance.
RSA
Authentication Manager 8.1 Documentation

For information about RSA Authentication Manager 8.1, see the following
documentation. RSA recommends that you store the product documentation in a
location on your network that is accessible to administrators.
Release Notes. Describes what is new and changed in this release, as well as
workarounds for known issues.
Hardware Appliance Getting Started. Describes how to deploy a hardware appliance
and perform the Authentication Manager Quick Setup process.
Virtual Appliance Getting Started. Describes how to deploy a virtual appliance and
perform the Authentication Manager Quick Setup process.
Planning Guide. Describes the high-level architecture of Authentication Manager and
how it integrates with your network.
Setup and Configuration Guide. Describes how to set up and configure
Authentication Manager.
Administrators Guide. Provides an overview of Authentication Manager and its
features. Describes how to configure the system and perform a wide range of
administration tasks, including manage users and security policies.
Help Desk Administrators Guide. Provides instructions for the most common tasks
that a Help Desk Administrator performs on a day-to-day basis.
Hardware Appliance SNMP Reference Guide. Describes how to configure Simple
Network Management Protocol (SNMP) to monitor an instance of Authentication
Manager on a hardware appliance.
Virtual Appliance SNMP Reference Guide. Describes how to configure Simple
Network Management Protocol (SNMP) to monitor an instance of Authentication
Manager on a virtual appliance.
Troubleshooting Guide. Describes the most common error messages in RSA
Authentication Manager and provides the appropriate actions to troubleshoot each
event.
8 Preface
Developers Guide. Provides information about developing custom programs using
the RSA Authentication Manager application programming interfaces (APIs).
Includes an overview of the APIs and J avadoc for J ava APIs.
Performance and Scalability Guide. Describes what to consider when tuning your
deployment for optimal performance.
6.1 to 8.1 Migration Guide. Describes how to migrate from an RSA Authentication
Manager 6.1 deployment to an RSA Authentication Manager 8.1 deployment.
7.1 to 8.1 Migration Guide: Migrating to a New Hardware Appliance or Virtual
Appliance. Describes how to migrate from an RSA Authentication Manager 7.1
deployment to an RSA Authentication Manager 8.1 deployment on a new hardware
appliance or virtual appliance.
7.1 to 8.1 Migration Guide: Upgrading RSA SecurID Appliance 3.0 on Existing
Hardware. Describes how to migrate from an RSA Authentication Manager 7.1
deployment to an RSA Authentication Manager 8.1 deployment on existing,
supported RSA SecurID Appliance 3.0 hardware.
Security Console Help. Describes day-to-day administration tasks performed in the
Security Console.
Operations Console Help. Describes configuration and setup tasks performed in the
Operations Console.
Self-Service Console Help. Describes how to use the Self-Service Console. To view
the Help, on the Help tab in the Self-Service Console, click Self-Service Console
Help.
RSA Token Management Snap-In Help. Describes how to use software that works
with the Microsoft Management Console (MMC) for deployments that have an Active
Directory identity source. Using this snap-in, you can enable or disable a token, assign
a token, or perform other token-related tasks without logging on to the Security
Console.
Related Documentation
RADIUS Reference Guide. Describes the usage and settings for the initialization
files, dictionary files, and configuration files used by RSA RADIUS.
Security Configuration Guide. Describes the security configuration settings available
in RSA Authentication Manager. It also describes secure deployment and usage
settings, secure maintenance, and physical security controls.
Preface 9
Support and Service
RSA SecurCare Online offers a knowledgebase that contains answers to common
questions and solutions to known problems. It also offers information on new releases,
important technical news, and software downloads.
The RSA Solution Gallery provides information about third-party hardware and
software products that have been certified to work with RSA products. The gallery
includes Secured by RSA Implementation Guides with step-by-step instructions and
other information about interoperation of RSA products with these third-party
products.
Before You Call Customer Support
Please have the following information available when you call:
Access to the RSA Authentication Manager 8.1 appliance.
Your license serial number. To locate the license serial number, do one of the
following:
Look at the order confirmation e-mail that you received when your ordered
the product. This e-mail contains the license serial number.
Log on to the Security Console, and click License Status. Click View
Installed License.
The Authentication Manager appliance software version information. You can
find this information in the top, right corner of the Quick Setup, or in the
SecurityConsole. Log on to the Security Console, and click Software Version
Information.
RSA SecurCare Online https://knowledge.rsasecurity.com
Customer Support Information www.emc.com/support/rsa/index.htm
RSA Solution Gallery https://gallery.emc.com/community/ma
rketplace/rsa?view=overview
1: Planning a Migration 11
1 Planning a Migration
Introduction
Before upgrading your installation of RSA Authentication Manager from version7.1
to version8.1 on existing RSA SecurIDAppliance 3.0 hardware, you must understand
the factors that affect data migration, the setup tasks, the possible pre-production
options, as well as the migration steps.
Review this chapter carefully so that you can plan for the process and make the best
choices for your organization.
Important: If you plan to migrate to hardware appliance that is not in production or if
you want to migrate to a virtual appliance, see the RSA Authentication Manager 7.1 to
8.1 Migration Guide: Migrating to a New Hardware Appliance or Virtual Appliance.
Reviewing the Migration Process
Use the following high-level steps to guide you through the migration process.
1. Plan the migration. Do the following:
a. Determine if your hardware is eligible for upgrading to version 8.1. For
instructions, see Determine if You Can Upgrade the Hardware Appliance on
page13.
b. Make sure the administrators planning or performing the migration have the
necessary expertise. See Expertise Required for Migration on page13.
c. Consider the factors that affect migration. For more information, see Factors
that Affect Migration on page14.
d. Select the migration scenario that best meets the needs of your deployment.
See Selecting a Migration Scenario on page22.
e. Determine if you will set up a test environment to test and configure
version8.1. You can save the system settings and deployment topology of the
8.1 pre-production testing environment, or completely overwrite the database.
See Pre-Production and Migration Import Options on page16.
12 1: Planning a Migration
f. Review the migration scenario that you selected:
For Scenario 1 (Basic Migration with the Replica Instances Online), see
Performing a Basic Migration with the Replica Instances Online on
page49.
For Scenario 2 (Basic Migration with All Instances Offline), see
Performing a Basic Migration with All Instances Offline on page65.
For Scenario 3 (Advanced Migration), see Performing an Advanced
Migration on page81.
If you have a standalone primary deployment, see AppendixE, Migrating
a Standalone Primary Deployment.
g. Review the post-migration tasks. See Chapter 7, Post-Migration Tasks.
h. Review the list of data that is migrated and not migrated. See AppendixA,
Migrated Data and AppendixB, Non-Migrated Data.
2. Complete the setup tasks. See Pre-Migration Checklist on page25.
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 version8.1 into production, perform the selected
scenario.
Performing a Basic Migration with the Replica Instances Online on page49.
For Scenario 2 (Basic Migration with All Instances Offline), see Performing a
Basic Migration with All Instances Offline on page65.
For Scenario 3 (Advanced Migration), see Performing an Advanced
5. Perform the post-migration tasks. See Chapter 7, Post-Migration Tasks.
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 Administrators 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 organizations 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 page14.
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.
Migration Scenarios. Be familiar with the different scenarios and with the
organizations particular needs to lead the decision-making process.
See Factors that Affect Migration on page14.
See Selecting a Migration Scenario on page22.
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 AppendixA, Migrated Data and AppendixB,
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 page14.
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
Migration on Existing Hardware
Migrating data from version 7.1 to version 8.1 on existing RSA SecurID
Appliance3.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 version8.1 installation overwrites version7.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 version7.1 deployment has multiple replica instances, you can create a test
environment by removing a replica instance from your deployment and installing
version8.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 page16.
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 version8.1 on the
original 7.1 primary instance until the version 7.1 replica instances have been
upgraded and attached to the version8.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 version7.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 AppendixE, Migrating a Standalone
Primary Deployment.
Pre-Production and Migration Import Options
You can test the migration process and version8.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
version7.1 without stopping services on the deployment. This data is then imported
into the 8.1 testing environment.
When you are ready for the version8.1 primary instance to enter production, you
create a new migration package. This package includes data that version7.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 version8.1 with the latest data from version7.1 and retain the system
settings and deployment topology of version8.1. This option preserves the overall
setup that you tested, and you import data that was updated on version7.1 during
the testing period, such as user and token data. For a list of data that is retained
and imported, see AppendixC, Retained and Imported Pre-Production Data.
Completely remove existing data from version8.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
version8.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 page41
After migration, each hardware appliance in your 8.1 deployment is configured with
the same hostname and IP address that was set originally in version7.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 version7.1
instance, the migration scenarios as documented do not require that you update
authentication agents. The agents that communicated with version7.1 can
automatically communicate with version8.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 version8.1, and distribute the
file to all agents. For more information, see the Administrators 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 page16.
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 version7.1 includes a remote RSA RADIUS
server.
RADIUS users cannot authenticate until you update RADIUS clients with the
hostname, IP address, or both of version8.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.
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 version7.1 is installed, and the operating system of version7.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.
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
page44. If you complete these tasks and decide to preserve pre-production
settings during import, see the post-migration tasks listed in RSA RADIUS on
page105.
If you decide to completely overwrite pre-production settings during your
migration, see the post-migration tasks listed in RSA RADIUS on page108.
For a complete list of data that is migrated and not migrated, see AppendixA,
Migrated Data and AppendixB, Non-Migrated Data.
Migration of Multiple Realms from Version 7.1
In version8.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 version7.1, you can create multiple realms in a deployment
and distribute your organizational hierarchy throughout these realms. However,
version8.1 does not support multiple realms within a single deployment. Each
deployment has one realm that is automatically created when you set up version8.1.
The version7.1 hierarchy is migrated to version 8.1 as follows:
Version7.1 realms are converted into security domains under the version 8.1
top-level security domain, SystemDomain.
Version7.1 security domains are nested under the new security domains that were
formerly version 7.1 realms.
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 version7.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
version8.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.
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 version8.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 Administrators 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 Administrators 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
version8.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 version7.1 realm are no longer administrators in
version8.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
AppendixA, Migrated Data and AppendixB, Non-Migrated Data.
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
authentication updates
from the replica
instances?
Start
See Scenario 3
(Advanced
Migration)
To expedite the
migration, can you
afford authentication
downtime?
NO
See Scenario 1
(Basic Migration
with the Replica
Instances Online)
See Scenario 2
(Basic Migration
with All Instances
Offline)
Do you have a
standalone primary
instance
deployment?
YES
Do you want to create a
test environment with
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
NO
NO
NO
YES
NO
YES
YES
For more detailed information, see the appropriate reference.
For a high-level comparison of the scenarios, see AppendixE, 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)
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 AuthenticationManager 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
Appliance 3.0 do not support RSA Authentication Manager 8.1.
For more information, see Determine if You Can Upgrade the Hardware
Appliance on page13.
Determine the Method You Will Use to Back Up the Appliance
The process of migrating to version 8.1 overwrites the version 7.1 installation on
the RSA SecurID Appliance 3.0. A backup of an existing appliance is required to
ensure that you can revert an 8.1appliance back to RSA SecurID Appliance 3.0. If
you need to restore version 7.1 to the hardware, you use the backup to overwrite
the 8.1 installation.
RSA recommends using PING to create a backup image of the hardware
appliance in case you need to restore the hardware appliance with an image of
Appliance 3.0. For more information, see the RSA Knowledgebase article
https://knowledge.rsasecurity.com/scolcms/knowledge.aspx#a49116. To
download PING, go to http://ping.windowsdream.com/.
Download RSA Authentication Manager 8.1 - Hardware Appliance Installer
To prepare for the software upgrade process, you must download the
RSA Authentication Manager 8.1 - Hardware Appliance Installer ISO file from
Download Central and save the ISO file to a location where you can burn the file
onto a DVD. You must use disc burning software that can burn the ISO file as a
bootable disk image.
To download the RSA Authentication Manager 8.1 - Hardware Appliance
Installer, go to https://download.rsasecurity.com.
26 2: Setting Up for Migration
Determine Which Replica Instance You Will Use As the Version 8.1 Primary
Instance
RSA recommends that you use an existing version 7.1 replica instance to initially
migrate the deployment to version 8.1 for the following reasons:
You can continue to use the version 7.1 primary instance during
pre-production and testing.
You may need to access the version 7.1 primary instance for troubleshooting
the migration. If you migrate the primary first, you need to restore it before
you attempt to resolve any issues related to the migration process.
Ensure that Authentication Manager 7.1 is Running Service Pack 4
RSA Authentication Manager 7.1 requires Service Pack 4 to run the
RSA AuthenticationManager 7.1Migration Export Utility. If the 7.1 deployment
being migrated has a trust relationship with another 7.1 deployment, you must
update the 7.1 trusted realm deployment to Service Pack 4 Patch 21 or higher.
To verify the version of Authentication Manager 7.1, in the Security Console, go
to Help >About RSA Security Console, and click See Software Version
Information.
To obtain RSA Authentication Manager 7.1 Service Pack 4 or any Service Pack 4
patch, go to RSA SecurCare Online at https://knowledge.rsasecurity.com, and
download the update. For instructions on installing Service Pack 4, see the RSA
Authentication Manager 7.1 Service Pack 4 Release Notes. For instructions on
installing a Service Pack 4 patch, see the Readme file associated with the patch in
RSA SecurCare Online.
Confirm that the Authentication Manager 7.1 Deployment is Functioning
The 7.1 deployment must be in a healthy state. Authentication Manager services,
including database services, must be running. Data must be replicating. If a
RADIUS server is associated with an instance or trusted realm, the RADIUS
server must be available.
Save Completed Reports
Completed reports are not migrated. If you want to save these reports, you can
save the output of completed reports.
For instructions on viewing and saving the report output, see the Security Console
Help topic View Report J obs.
Complete Pending User Requests
You must complete all pending user requests for self-service enrollment, hardware
tokens, software tokens, and on-demand tokencodes. Pending user requests are
not migrated.
For instructions, see the Security Console Help topics Approve and Reject User
Requests and Complete User Requests.
Copy and Save the E-mail Notification Template for Approved Software
Token Requests
The 7.1 e-mail notification template for approved software token requests is not
migrated. By default, version 8.1 includes an improved e-mail notification
template for approved software token requests.
If you want to reuse the content of the 7.1 e-mail notification template for
approved software token requests, copy and save the template to an accessible
location. During pre-production or after completing a migration, modify the saved
7.1 template for use in version8.1.
Schedule a Cleanup Job
Use a scheduled cleanup job to automatically remove unresolvable users and user
groups on version7.1. This process deletes users and user groups that do not exist
in an identity source.
A cleanup job that is started manually does not remove references to unresolvable
user groups.
To schedule a cleanup job, see the Security Console Help topic Schedule
Cleanup.
Prepare for RADIUS Post-Migration Tasks
The following RADIUS settings are not migrated from version 7.1:
RSA RADIUS server certificate
RSA RADIUS configuration files (.conf, .ini, .aut)
RADIUS dictionary files from a remote RADIUS server
Trusted root certificate for RADIUS servers
After migration, you can import RADIUS files such as the server certificate,
remote RADIUS dictionary files, and the trusted root certificate. To import, save a
copy of these files to an accessible location. If you are migrating to a new
appliance, you can perform some of these tasks during pre-production testing.
If you have a remote RADIUS server, the 7.1 remote RADIUS dictionary files are
located in the following locations:
On Windows: RSA_AM_HOME/radius/Service
On Linux: RSA_AM_HOME/radius
If you edited the RSA RADIUS configuration files and you want to apply these
edits to 8.1, record the edits that you made to the 7.1 RADIUS configuration files.
Record Manual Contact Lists
Version 7.1 manual contact lists for authentication agents are not migrated. After
migration, recreate the agent contact lists and assign the lists to authentication
agents.
If you want to recreate the contact lists from version 7.1, record each contact list
and save it to an accessible location.
Record Network Settings Associated with the 7.1 Instances
Record the following network settings of each 7.1 instance:
Fully qualified domain name (FQDN)
IP Address
Subnet mask
Default gateway
Domain Name System (DNS) servers and search domain configuration
During a migration scenario, you apply these settings when deploying the
hardware appliance.
Install the RSA Authentication Manager 7.1 Migration Export Utility
The Migration Export Utility is used to export data from the 7.1 deployment. For
more information, see Migration Export Utility Installation on page28.
Migration Export Utility Installation
You must install the RSA Authentication Manager 7.1 Migration Export Utility on the
version7.1 primary instance appliance. The RSA SecurID Appliance 3.0 requires the
command line version of the Migration Export Utility. This utility securely extracts
data to an encrypted migration package that you import to the
RSA AuthenticationManager 8.1 primary instance.
The Migration Export Utility installation file is located in the RSA Authentication
Manager 8.1 download kit. You must copy the following installation file from the
RSA Authentication Manager 8.1 download kit to an accessible location on the 7.1
host machine:
migration-installer.sh
migration-installer.jar
The migration-installer.jar file must exist in the same directory as the installation file
You can use a number of methods to copy the files to version7.1. For example, you
can use a Secure Copy Protocol (SCP) client to copy these files from your local
computer to the RSA SecurID Appliance 3.0.If you use an SCP client to copy the
installation files to the Appliance, log on as emcsrv and enter the operating system
password that you specified during Quick Setup.
Install the Migration Export Utility
Use this procedure to install the RSA AuthenticationManager
7.1MigrationExport Utility through a command line. You must use the command line
to install the utility on the RSA SecurIDAppliance3.0.
Before You Begin
Locate the correct installation file, as described in Migration Export Utility
Installation on page28. Using a Windows file sharing mechanism, Secure Copy
Protocol (SCP) client, or another method, copy the installation file and the
migration-installer.jar file from the RSA Authentication Manager 8.1 download
kit to an accessible location on the RSA Authentication Manager 7.1 primary
instance host machine. Place the files in the same directory. To determine which
installation file you need, see Migration Export Utility Installation on page28.
Make sure you can log on as root. You must run the installer as the root user.
Make sure that the execute permission is enabled on migration-installer.sh.
You must enable Secure Shell (SSH). For instructions, see the 7.1 Operations
Console Help topic Enable SSH on an Appliance NIC.
Procedure
1. Do the following to access the installer:
a. Using an SSH client, log on to the Appliance operating system with the
User ID emcsrv, and the operating system password created during Quick
Setup.
b. Change users to root. Type:
sudo su -
and press ENTER.
c. When you are prompted for a password, enter the operating system
password specified during Quick Setup.
d. Change directories to the location where you copied
migration-installer.sh and migration-installer.jar to the server.
e. Type the following command, and press ENTER:
./migration-installer.sh -console
2. On the Welcome screen, type 1 to continue, and press ENTER.
3. On the License Agreement screens, press ENTER to proceed through each
Agreement screen.
4. Type 1 to accept the terms of the License Agreement, and press ENTER.
5. To install the utility, enter a full path that does not exist, and press ENTER. The
installer will create this path.
6. Confirm the location that you specified.
7. Type1 to begin the installation process, and press ENTER.
8. Do one of the following:
To run the utility after installation, type 1, and press ENTER.
Run the utility only when you are ready to export data.
To exit the installer and export data at a later time, type 2, and press ENTER.
Next Steps
Test the migration process. For instructions, see Chapter 3, Pre-Production and
Testing Version 8.1.
3: Pre-Production and Testing Version 8.1 31
3 Pre-Production and Testing Version 8.1
Pre-Production
A pre-production test environment is a deployment of RSA Authentication
Manager 8.1 that is not yet live in your network and is used for testing and setup
purposes while version7.1 is in production.
You can only test the migration and Authentication Manager 8.1 when the 7.1
deployment is replicated. The testing process requires that you remove a replica
instance from your deployment and install version8.1 on the appliance. If you decide
to perform a test migration, make sure that your version 7.1 deployment can be
without a replica instance before upgrading to version 8.1.
Note: If you plan to test the migration and perform an Advanced Migration, your
deployment must include at least two replica instances.
The following graphic shows the process that is required to create a temporary 8.1
primary instance for testing. For detailed steps, see Testing the Migration on page33.
32 3: Pre-Production and Testing Version 8.1
A pre-production environment allows you to set up version8.1 with the deployment
topology and system settings that you require in production. When completing the
migration, you can preserve these settings and use them when version8.1 goes into
production.
Pre-production offers the following benefits:
Testing the migration allows you to export data from the 7.1 primary instance
without stopping administration and authentication. Because services continue to
run, the database is updated while the export is in progress. In turn, this option
does not guarantee that the migration package includes the latest database records.
After you import the migration package, the pre-production test environment can
be set up to resemble a real production environment. This allows you to
thoroughly test version8.1 before you complete migration and enter production.
Note: Before you begin testing and applying settings to version 8.1, import data
from the version 7.1 deployment. Importing a migration package into version 8.1
for the first time overwrites all data in the 8.1 deployment and removes any
attached replica instances.
When you are ready to go into production and import a new migration package,
you can retain the deployment topology and the system settings of the test
environment, or completely overwrite the database with the data in the migration
package. If you retain the deployment topology and the system settings, you can
configure settings that are otherwise required after migration. For a list of settings,
see Pre-Production Setup Tasks on page41.
If you choose to completely overwrite the pre-production environment, you must
reconfigure the system settings and deployment components in the production
deployment.
For a list of data that is retained or overwritten, see AppendixC, Retained and
Imported Pre-Production Data.
For more information about pre-production and the migration import options, see
Pre-Production and Migration Import Options on page16.
Migration Package
You use the RSA Authentication Manager 7.1 Migration Export Utility to extract data
into an encrypted file called a migration package. The migration package contains
data such as users, tokens, and administrative roles. You can optionally export logs
that are stored in the RSA Authentication Manager internal database.
For more information about the data in the migration package, see AppendixA,
Migrated Data.
The filename of the migration package includes the following components:
hostname_timestamp_instance_migration.pkg
where:
hostname is the hostname of the 7.1 instance.
timestamp is the date and time when the migration package is generated. The date
and time displays with the following format: YYYY-MM-DD-HHMM.
instance is the instance where the package is generated. The instance displays as
pri for the primary instance and rep for a replica instance.
The data in this file is encrypted with a migration package password that you create
during export. The migration package is decrypted with this same password during
import.
Follow these important guidelines:
Throughout the migration process, ensure that the migration package is stored in a
secure location.
The migration package should only be available to administrators who will
perform the migration.
After the migration process is successfully completed, delete the migration package.
Testing the Migration
Use the following procedures to export data from the 7.1 primary instance without
stopping services and import this data into the 8.1 test environment.
Procedure
1. Back up the 7.1 replica appliance that you selected to temporarily use as the 8.1
primary instance. You must create a backup image of the hardware appliance, in
case you need to restore RSA Authentication Manager 7.1. RSA recommends
using PING. See Create a Backup Image of the Hardware Appliance on page34.
2. Install RSA Authentication Manager 8.1. See instructions, Install RSA
Authentication Manager 8.1 on the RSA SecurID Appliance 3.0 on page35.
3. Deploy the hardware appliance and perform Quick Setup to configure the version
8.1 appliance as a primary instance. Make sure to use a new hostname and IP
address. For instructions, see the chapter Deploying a Primary Appliance in the
RSA Authentication Manager 8.1 Setup and Configuration Guide.
4. Use the RSA Authentication Manager 7.1 Migration Export Utility to export data
from the RSA Authentication Manager 7.1 primary instance. See Export Data
from the Primary Instance on page36.
5. Import data to RSA Authentication Manager 8.1. See Import Data to RSA
Authentication Manager 8.1 on page38.
6. Verify that data is migrated to RSA Authentication Manager 8.1.
7. Perform pre-production setup tasks. See Pre-Production Setup Tasks on page41.
8. Test version8.1.
9. After you have tested version8.1 and are ready to complete the migration, see the
chapter for your migration scenario.
Chapter 4, Performing a Basic Migration with the Replica Instances Online.
For Scenario 2 (Basic Migration with All Instances Offline), see Chapter 5,
Performing a Basic Migration with All Instances Offline.
For Scenario 3 (Advanced Migration), see Chapter 6, Performing an
Advanced Migration.
Create a Backup Image of the Hardware Appliance
Before installing version8.1, you must create a backup image of the
RSA SecurIDAppliance3.0 hardware appliance. This process produces a full backup
of Authentication Manager and the appliance operating system.
RSA recommends that you use PING to perform the back up. You can store a backup
image of the appliance on a Network File System (NFS), Windows Share, or a USB
drive.
Before You Begin
Attach a keyboard and monitor to the appliance.
Take note of the appliance network settings, such as the hostname, IP address and
the default gateway. After installing version8.1, you must provide these settings.
Determine where you will securely store the backup image of the hardware
appliance. You can store a backup image on an NFS, Windows Shared folder, or a
USB drive.
Procedure
See the RSA Knowledgebase article
https://knowledge.rsasecurity.com/scolcms/knowledge.aspx#a49116. To download
PING, go to http://ping.windowsdream.com/
Next Steps
Install RSA Authentication Manager 8.1. See Install RSA Authentication Manager 8.1
on the RSA SecurID Appliance 3.0 on page35.
Install RSA Authentication Manager 8.1 on the RSA SecurID
Appliance 3.0
After creating a backup image of the RSA SecurID Appliance 3.0, you can install
RSA Authentication Manager 8.1 on the appliance.
Before You Begin
Create a backup image of the hardware appliance. See Create a Backup Image of
the Hardware Appliance on page34.
Attach a keyboard and monitor to the appliance
Procedure
1. Insert the DVD that you created with the RSA Authentication Manager 8.1 -
Hardware Installer ISO file.
2. Reboot the appliance. Do one of the following:
To reboot the appliance through the Operations Console, in the Operations
Console, click Maintenance > Reboot Appliance.
To reboot the appliance through a command line, do the following:
a. Enable SSH on the appliance. For instructions, see the RSA SecurID
Appliance 3.0 product documentation.
b. Using an SSH client, log on to the appliance operating system with the
user emcsrv and the operating system password.
c. Type the following command to reboot the appliance, and press ENTER.
sudo reboot
d. If prompted for a password, enter the operating system password, and
press ENTER.
If the appliance does not automatically boot from the DVD, press the F11 function
key to access the appliance BIOS. In the appliance BIOS, select SATA CD-ROM
to set the appliance to boot from the DVD, and press ENTER.
3. In the Installer menu, select Install RSA Authentication Manager and press
ENTER.
The Authentication Manager 8.1 installation process begins. Wait for the
following message to display:
RSA Authentication Manager installed successfully.
Please remove the RSA Authentication Manager DVD.
Do you want to shut down the appliance? (yes/no)
4. Type no and press ENTER.
Next Steps
Deploy the hardware appliance and perform Quick Setup to configure the version 8.1
appliance as a primary instance. Make sure to use a new IP address. For instructions,
see the chapter Deploying a Primary Appliance in the RSA Authentication Manager
8.1 Setup and Configuration Guide.
Export Data from the Primary Instance
Use this procedure to export data from the 7.1 primary instance with the command
line version of the RSA AuthenticationManager 7.1MigrationExport Utility. You
must use the command line utility on the RSA SecurIDAppliance3.0.
This procedure does not interrupt services on the 7.1 deployment.
Before You Begin
Complete the Pre-Migration Checklist on page25.
Install the RSA Authentication Manager 7.1 Migration Export Utility. For more
information see, Migration Export Utility Installation on page28.
Make sure you can log on as root. You must run the utility as the root user.
Procedure
1. If you ran the Migration Export Utility immediately after installing it, go to step 2.
If you did not run the utility, do the following:
a. Using an SSH client, log on to the Appliance operating system with the
User ID emcsrv, and the operating system password created during Quick
Setup.
sudo su -
and press ENTER.
c. When you are prompted for a password, enter the operating system
password specified during Quick Setup.
d. Change directories to the location where you installed the utility.
e. Type the following command to launch the utility, and press ENTER:
./migration-exporter.sh -console
2. When prompted, enter the master password for the 7.1 deployment, and press
ENTER.
3. When prompted to choose the type of 8.1 environment that you are setting up,
type 1 to select Testing Environment, and press ENTER.
4. Choose whether to export 7.1 database log records. Exporting log records
increases both export and import time. Do one of the following:
Type 1 to export 7.1 database log records and include the logs in the migration
package, and press ENTER.
Type 2 to not export 7.1 log records, and press ENTER.
5. Enter the full path of the location where you want to save the migration package,
and press ENTER.
You must have write permission in the directory that you specify. If the location
does not exist, a directory is automatically created in this location.
Remember the location. You need it to access the migration package for the
import operation.
6. Type 1 to continue, and press ENTER.
7. When prompted, create a migration package password, and press ENTER.
The password must contain 8 to 32 characters that include at least one alphabetic
character and one special character. Do not use a space or the special characters @
or ~.
You need this password to import the migration package into RSA Authentication
Manager 8.1.
8. Enter the migration package password again to confirm the password, and press
ENTER.
9. Confirm that you will export data from the primary instance without stopping
services, and the location of the migration package.
10. Type 1 to begin the export process, and press ENTER.
The utility displays a list of completed export tasks.
Wait until the export process completes. A screen with the location of the
migration package and any required Next Steps displays.
11. Exit the command prompt window.
Next Steps
To prepare for import, manually copy the migration package to one of the
following locations:
Your local machine. This option allows you to upload the migration package
through your browser. If the migration package exceeds 2 GB, you cannot use
this option.
A Network File System (NFS)
A Windows shared folder
The RSA Authentication Manager 8.1 server in the directory
/opt/rsa/am/migration. To copy the migration package to version8.1, you
can use a Secure Copy Protocol (SCP). If you use an SCP client, log on as
rsaadmin, and enter the operating system password that you specified during
Quick Setup.
Depending on your network and the size of the migration package, you may want
to place the migration package on the Authentication Manager 8.1 server to
expedite the import.
Import data to the 8.1 primary instance. For instructions, see Import Data to RSA
Import Data to RSA Authentication Manager 8.1
Use this procedure to import the 7.1 migration package to RSA Authentication
Manager 8.1.
All 7.1 administrative accounts are migrated. The 7.1 Super Admin and Operations
Console administrator accounts replace the Super Admin and Operations Console
administrator accounts that are created during the version8.1 Quick Setup.
Before You Begin
Export data from a 7.1 primary instance. For instructions, see Export Data from
the Primary Instance on page36.
Make sure that you placed the migration package in one of the following
locations:
Your local machine
/opt/rsa/am/migration.
If the migration package exceeds 2 GB, you cannot import the migration package
from the local machine, the option that uploads the package through your browser.
Procedure
1. Log on to the Operations Console for the Authentication Manager 8.1 primary
instance.
2. Click Deployment Configuration >Migration >From Version 7.1 >Import
7.1 Migration Package.
3. Under Package File Location, do one of the following:
Select Local Machine, and browse to locate the migration package on your
local machine.
Select Windows Shared Folder to locate the migration package on a
Windows shared folder. Do the following:
In the Windows Shared Folder field, enter the path to an existing
Windows shared folder, for example, \\example.com\migration_folder
If the shared folder requires a user name, enter the user name in the
Folder User Name field.
If the shared folder requires a password, enter the password in the Folder
Password field.
Select NFS (Network File System) Shared Folder to locate the migration
package on an NFS. In the NFS Shared Folder field, enter the path to an NFS
server and file directory, for example,
fileserver.example.net:/migration_directory.
Select Authentication Manager 8.1 Server to locate the migration package
at the following location on RSA AuthenticationManager 8.1:
/opt/rsa/am/migration
4. In the Migration Package Password field, enter the migration package password
that you created during export.
5. Click Next.
If you select the Local Machine as the package file location, the upload time
varies, depending on the size of the migration package. For example, it may take
several minutes to upload a 1 GB migration package file.
If the Confirmation screen displays, skip steps 6 and 7, and go to step 8.
6. If the specified location contains more than one migration package, do the
following:
a. In the Package File Location drop-down list, select the migration package
that you want to import.
b. If you want to import a different package, select Import a different package,
and do one of the following:
Select Local Machine, and browse to locate the migration package on
your local machine.
Windows shared folder. Enter the path to an existing shared folder, for
example, \\example.com\migration_folder, and enter the username and
password for the shared folder.
Select NFS (Network File System) Shared Folder to locate the
migration package on an NFS. In the NFS Shared Folder field, enter the
path to an NFS server and file directory, for example,
Select Authentication Manager 8.1 Server to locate the migration
package at the following location on RSA AuthenticationManager 8.1:
c. In the Migration Package Password field, enter the migration package
password that you created during export.
d. Click Next.
varies, depending on the size of the migration package. For example, it may
take several minutes to upload a 1 GB migration package file.
7. If you previously imported a migration package from a 7.1 primary instance, you
must select how you want to import the current migration package into
version8.1.
a. Select one of the following:
Retain system settings and the deployment topology during import.
This option preserves the system settings and the deployment topology of
version 8.1, and imports the remaining data from the new migration
package.
For a list of data that is retained and imported with this option, see
AppendixC, Retained and Imported Pre-Production Data.
Remove all existing data, and import data from the migration
package.
b. Click Next.
8. On the Confirmation page, select Yes, import data from the provided migration
package to confirm the import.
9. Click Start Migration.
The status of the import process displays. You can click Advanced Status View to
see more information about the import.
10. Click Next.
11. Click Download Migration Report to view more details about the migration.
12. Click Done.
Next Steps
Do the following in this order:
Verify that the 7.1 data is migrated to version8.1. For information about
discrepancies between the total number of data in the migration summary and data
in the Operations Console or Security Console, see the Migration Results on
page162. For a complete list of data that is migrated or not migrated, see
AppendixA, Migrated Data and AppendixB, Non-Migrated Data.
If the import is successful, delete the migration package.
Perform pre-production setup tasks. See Pre-Production Setup Tasks on page41.
Pre-Production Setup Tasks
After importing data into the pre-production environment, you can configure the
following settings in that environment. If you retain the system settings and the
deployment topology, these settings are preserved in the 8.1 deployment. Otherwise,
these settings are overwritten and require reconfiguration after migration.
Deployment Configuration
The following table includes deployment configuration tasks that you can complete as
part of pre-production.
Task Description Reference
Install a web tier (optional). A web tier is a secure platform for installing
and deploying the Self-Service Console,
dynamic seed provisioning, and the risk-based
authentication (RBA) service.
The chapter Installing Web
Tiers in the RSA
Authentication Manager 8.1
Setup and Configuration Guide
Manage application trust,
console, and virtual host
certificates.
You can import the following certificates:
Application trust certificate
Console certificate
Virtual host certificate
Operations Console Help
topics:
Add a New Application
Trust Certificate
Import a Console
Certificate
Import a Signed Virtual
Host Certificate
System Configuration
The following table includes system settings that you can configure as part of
pre-production.
Configure critical system
event notification.
If you want to notify administrators
immediately by e-mail if a critical system
event occurs, enable critical system event
notifications. This option can notify the Super
Admin or individuals that you choose.
Security Console Help topic
Configure Critical System
Event Notification
Configure session handling
settings.
Version7.1 session handling settings are not
migrated. You can apply the session handling
settings that were previously used in
version7.1.
Configure Session Handling
Edit session lifetime
settings.
Session lifetime settings and custom session
lifetime from version7.1 are not migrated.
You can edit the session lifetime settings in
version8.1
Edit Session Lifetime
Settings
Configure Simple Network
Management Protocol
(SNMP) settings.
SNMP settings are not migrated from
RSA AuthenticationManager 7.1.
If you previously configured SNMP and you
want to apply these settings to the 8.1
deployment, you must reconfigure these
settings.
You must use SNMP clients that support
SNMP Version 3.
Configure SNMP
Configure logging settings. In version8.1, you can configure the log levels
and the following log data destinations for
administrative audit, runtime audit, or system
log data:
Database only
Database and local operating system
SysLog
Database and remote SysLog host
Any modification that was made to the 7.1
ims.properties file to allow Authentication
Manager to send log messages to a local or
remote Syslog is not migrated.
Configure Logging
Schedule log archival. Log archive jobs are not migrated from the 7.1
deployment. You can reschedule these jobs on
version8.1.
Archive Logs Using Schedule
Log Archival
Configure log rotation
settings.
Log rotation settings prevent the appliance
operating system logs from growing
indefinitely. You can configure how and when
the appliance logs are rotated.
Operations Console Help topic
Configure Appliance Log
Settings
Configure operating system
access settings.
You can configure operating system access
settings, including whether to enable Secure
Shell (SSH), session lifetime settings, or
change the operating system password.
topics:
Enable Secure Shell on the
Appliance
Change the Operating
System Account Password
Configure date and time
settings.
You can update the date and time settings, if
necessary.
Update System Date and Time
Settings
Reconfigure scheduled
backups.
Scheduled backup jobs are not migrated. On
version 8.1, reconfigure scheduled backups.
Create a Backup Using
Schedule Backups
Specify product update
locations.
To allow version8.1 to locate product updates,
you must specify the location where updates
are stored.
Specify a Product Update
Location
Configure security questions
and security question
requirements.
You can import new security questions and
configure the number of questions that are
required during enrollment or authentication
into the Self-Service Console.
Security Console Help topics:
Managing Security
Questions
Import Security Questions
Set Requirements for
Security Questions
Configure Simple Mail
Transfer Protocol (SMTP)
and caching settings for a
replica instance.
The SMTP and caching settings associated
with a replica instance are not migrated. If you
configured these settings for a 7.1 replica
instance and you want to apply them in 8.1,
you must reconfigure the SMTP and the
caching settings for an 8.1 replica instance.
Configure the SMTP Mail
Service
Configure the Cache
RSA RADIUS
The following table includes RSA RADIUS settings that you can configure as part of
pre-production.
Edit RSA RADIUS
configuration files.
The version7.1 RADIUS configuration files
are not migrated.
If you edited the default settings of the
RADIUS configuration files in version 7.1,
you must apply these settings to the RADIUS
configuration files in version8.1.
Edit RADIUS Server Files
Replace RSA RADIUS
server certificate, if
necessary.
If you replaced the RSA RADIUS server
certificate with another certificate in version
7.1, and you want to use this certificate in
version 8.1, you must replace the RSA
RADIUS server certificate through the
Operations Console.
To replace the 8.1 RSA RADIUS server
certificate with the certificate that you used in
version 7.1, you must copy the certificate from
version 7.1 and use the 8.1 Operations Console
to replace the certificate.
Replace a RADIUS Server
Certificate
Add trusted root certificates
to the primary RADIUS
server.
The trusted root certificates for the RSA
RADIUS servers are not migrated.
To ensure that the RSA RADIUS server can
verify the identity of a RADIUS client during
Extensible Authentication Protocol-Tunneled
Transport Layer Security (EAP-TTLS)
authentications, you must manually add the
version 7.1 trusted root certificate to the
primary RADIUS server on the 8.1 primary
instance.
Add a Trusted Root
Certificate
Authentication
The following table includes tasks related to authentication that you can complete as
part of pre-production.
Add, edit, or copy RADIUS
dictionary files from a
remote RADIUS server.
The dictionary files from a remote RADIUS
server are not migrated.
Do one of the following:
If your 7.1 deployment has multiple
customized RADIUS dictionary files for a
remote RADIUS server and you want to
make these files available to the RADIUS
server on an 8.1 instance, you can use a
Secure Copy Protocol (SCP) to manually
copy files from the remote RADIUS server
to RSA Authentication Manager 8.1.
If your 7.1 deployment has only a few
customized dictionary files for a remote
RADIUS server and you want to make these
files available to the RADIUS server on an
8.1 instance, you can use the 8.1 Operations
Console to upload individual RADIUS
dictionary files to version8.1.
If your 7.1 deployment contains edits to
existing remote RADIUS dictionary files,
you can make these edits to the RADIUS
dictionary files on an 8.1 instance.
To copy files from
version7.1 to version8.1
using an SCP client, see
Copy the RADIUS
Dictionary Files on
page122.
To add a new RADIUS
dictionary, see the
topic Add a RADIUS
Dictionary.
To edit an existing remote
RADIUS dictionary file, see
the Operations Console Help
topic Edit RADIUS Server
Files.
Create software token
profiles.
In version8.1, software token device types are
associated with a software token profile.
Software token profiles specify software token
configuration and distribution options.You
must configure a software token profile for
each platform to which you plan to distribute
software tokens.
Add a Software Token
Profile
The chapter Deploying and
Administering RSA SecurID
Tokens in the RSA
Administrators Guide
Self-Service
The following table includes self-service settings that you can configure as part of
pre-production.
Configure Short Message
Service (SMS) settings for
Clickatell.
If you used the Clickatell plug-in for
delivering on-demand tokencodes in
version7.1, you must select HTTP as the SMS
plug-in and reconfigure these settings in
version8.1.
The RSA SMS HTTP Plug-In
Implementation Guide that is
available through the EMC
Solutions Gallery at
https://gallery.emc.com/co
mmunity/marketplace?vie
w=overview. On the
website, search for the title
of the document. Under
Clickatell Gateway, click the
Collateral tab to locate the
document.
Configure the HTTP
Plug-In for On-Demand
Tokencode Delivery
Configure alternative
instance IP addresses.
Alternative IP addresses are not migrated for a
7.1 instance. If you want an 8.1 instance to use
an alterative IP address, you set it in
version8.1.
Add Alternative IP Addresses
for Instances
Select the software tokens
available for users to request
through the Self-Service
Console.
After you create software token profiles for the
device types you need, you can select the
software tokens that are available for users to
request through the Self-Service Console.
On the Manage Authenticator page in the 8.1
Security Console, select the software token
profile of the software token that you want to
make available for request, and configure the
options associated with the software token.
Select Software Tokens for
Provisioning
Modify 7.1 e-mail
notification templates
In version 8.1, e-mail notification templates
use the tag ConfirmNumber for all requests,
while the 7.1 e-mail notification templates
uses the tag RequestID.
After migration, you must modify migrated
e-mail templates to use the ConfirmNumber
tag.
Update the E-mail Notification
Template After Migrating from
Version 7.1 on page122
The following table includes a task related to authentication agents that you can
complete as part of pre-production.
Reporting
The following table includes a task that you can complete as part of pre-production.
Application Programming Interface Update
If you use the RSA application programming interface (API) to develop custom
software applications for Authentication Manager 7.1, you may need to modify the
custom application to work with version 8.1. Before you complete a migration
scenario and version 8.1 goes into production, test the custom application in your
deployment and modify them as needed.
For more information, see the RSA Authentication Manager 8.1 Developers Guide.
Configure the Approved
Software Token Notification
template
If you want to reuse the e-mail notification
template for approved software token requests,
you can modify the 7.1 software token e-mail
notification template so that it works in 8.1.
Template After Migration on
page123
Set the shipping address for
user requested tokens.
If a user record includes identity attribute
definitions with the users address, you can
map these attributes to the shipping address
used in the Self-Service Console for token
requests. This option allows a users address to
automatically display when the user requests a
token through the Self-Service Console.
Configure Shipping
Addresses for Hardware
Authenticators
Create manual contacts lists
for agents.
The 7.1 agent contact list is not migrated. If
you want to use a 7.1 manual contact list in
version8.1, you must create a new manual
contact list with the needed instances.
Add a Manual Contact List
Run a report job with the
Software Tokens template to
view the device type of 7.1
distributed software tokens.
After import, you cannot identify the device
type of a 7.1 distributed software token when
viewing or managing the token. If you want to
see the device type of a migrated software
token, you must run a report job using the
Software Tokens template.
If you have not created a
report with the Software
Tokens template, see the
Add a Report.
Run a Report J ob
Selected Migration Scenario
After you have tested version8.1 and are ready to complete the migration, go the
chapter that applies to your migration scenario.
Scenario Chapter
Scenario 1 (Basic Migration with the
Replica Instances Online)
with the Replica Instances Online
Scenario 2 (Basic Migration with All
Instances Offline)
with All Instances Offline
Scenario 3 (Advanced Migration) Chapter 6, Performing an Advanced
Migration
4: Performing a Basic Migration with the Replica Instances Online 49
4 Performing a Basic Migration with the
Replica Instances Online
Scenario 1: Basic Migration with the Replica Instances Online
A Basic Migration with the replica instances online migrates data from the primary
instance only. The replica instances continue to authenticate users. Authentication
updates that are recorded on the replica instances, such as log data and PIN changes,
are not migrated.
Services are stopped on the primary instance, preventing database changes and partial
data migration. Data is completely collected. The following also applies:
After export, the primary instance remains stopped.
The replica instances authenticate users while the primary instance is unavailable
during migration.
Although data such as PIN changes or log data is recorded while the primary
instance is unavailable, this data is lost because it is not exported from the 7.1
deployment.
The following graphics show the high-level steps that are required to migrate data into
version8.1 and start authentication on version8.1.
50 4: Performing a Basic Migration with the Replica Instances Online
In the following graphic, a version 7.1 replica instance has already been configured as
a version 8.1 primary instance. This graphic assumes that a test migration took place
or if you did not test the migration, that you removed a replica instance from version
7.1, upgraded the hardware appliance to version 8.1, and configured the hardware
appliance as an 8.1 primary instance.
For a detailed description of steps, see Performing a Basic Migration with the Replica
Instances Online on page52.
When performing the upgrade and migration, you recreate the version7.1
deployment. As illustrated, the 8.1 primary instance uses the hostname and IP address
that applied when the hardware appliance was originally a 7.1 replica instance. If you
tested the migration, you must change the unique hostname and IP address of the
8.1primary instance to the settings that applied when the appliance was a 7.1 replica
instance. The remaining replica instances are also upgraded and configured with their
original hostname and IP address.
As shown in this graphic, the version 7.1 primary instance, which is the last instance
upgraded to version 8.1, uses its 7.1 hostname and IP address when configured as an
8.1 replica instance. A promotion for maintenance is completed to promote this
instance and demote the existing 8.1 primary instance to a replica instance. Because
every instance ultimately reuses the hostname and IP address that was previously used
in version 7.1, there is no need to update authentication agents.
Note: If you need to roll back the migration process and the replica instances have not
replicated data to the 7.1 primary instance in more than seven days, you must reattach
the replica instances. For more information, see AppendixD, Restoring a Hardware
Appliance.
Migration After Pre-Production Testing
If you created a pre-production test environment, during migration you import a new
migration package from version7.1 with the latest data. You can either retain the
system settings and deployment topology of the test environment and import the
remaining data, or completely overwrite the database with the new migration package.
If you overwrite the database, you lose the data from the test environment. To
understand more about pre-production and the import options, see Pre-Production and
Migration Import Options on page16.
Performing a Basic Migration with the Replica Instances Online
Use this procedure to migrate data from an existing version 7.1 primary instance to a
new appliance without experiencing authentication downtime. The replica instances
continue to authenticate users, but authentication updates such as PIN and password
changes are not exported.
Before You Begin
If you are testing the migration process, do the following:
See Chapter 3, Pre-Production and Testing Version 8.1.
If you plan to retain the deployment topology and system settings from the
pre-production testing period, you can take a backup of the 8.1 testing
environment. If needed, this allows you to return version 8.1 to the state it was
in during pre-production.
You can back up the version 8.1 database also. See the Operations Console
Help topic Create a Backup using Back Up Now.
Procedure
1. If you did not test the migration process, do the following to create the temporary
8.1 primary instance:
a. Back up the 7.1 replica appliance that you selected to use as the 8.1 primary
instance. You must create a backup image of the hardware appliance, in case
you need to restore RSA Authentication Manager 7.1. RSA recommends
using PING. For more information, see Create a Backup Image of the
Hardware Appliance on page54.
b. On the 7.1 replica appliance, install Authentication Manager. For instructions,
see Install RSA Authentication Manager 8.1 on the RSA SecurID Appliance
3.0 on page54
c. Deploy the hardware appliance and perform Quick Setup to configure the
version 8.1 appliance as a primary instance. You can deploy the primary
appliance with the hostname and IP address of the original 7.1 replica
instance. For instructions, see the chapter Deploying a Primary Appliance
in the RSA Authentication Manager 8.1 Setup and Configuration Guide.
from the version 7.1 primary instance. For instructions, see Export Data on
page56.
3. On the 8.1 primary instance, import the 7.1 migration package. For instructions,
see Import Data to RSA Authentication Manager 8.1 on page58.
4. If you tested the migration and in turn, created a temporary primary instance with
a unique hostname and IP address, change the hostname and IP address of the 8.1
primary instance to the hostname and IP address of the original 7.1 replica
instance. For instructions, see Change the Hostname and IP Address of the
Primary Instance on page61.
5. For each remaining replica instance that you want to upgrade to version 8.1, do
the following:
a. Back up the hardware appliance for the instance. You must create a backup
image of the hardware appliance, in case you need to restore RSA
Authentication Manager 7.1. RSA recommends using PING. For instructions,
see Create a Backup Image of the Hardware Appliance on page54.
b. Install Authentication Manager 8.1 and configure the appliance as a replica
instance. For instructions, see Install RSA Authentication Manager 8.1 on the
RSA SecurID Appliance 3.0 on page54.
version 8.1 appliance as a replica instance.
When deploying the hardware appliance, configure the appliance with the
hostname and IP address that was previously used for the instance in version
7.1.
For instructions, see the chapter Deploying a Replica Appliance in the
d. Attach the replica instance. For instructions, see the chapter Deploying a
Replica Appliance in the RSA Authentication Manager 8.1 Setup and
Configuration Guide.
e. Repeat steps 5a to 5d on each 7.1 replica instance.
6. Upgrade and configure the version 7.1 primary instance as a version 8.1 replica
instance. To do this, complete steps 5a to 5d on the version7.1 primary appliance.
7. To make the former version 7.1 primary instance a primary instance in the 8.1
deployment, perform a promotion for maintenance.
A promotion for maintenance promotes a replica instance to become the primary
instance and automatically demotes the existing primary instance to a replica
instance.
For instructions, see the System Maintenance and Disaster Recovery chapter in
the RSA Authentication Manager 8.1 Administrators Guide.
drive.
Before You Begin
USB drive.
Review the high-level steps to verify that you performed the necessary steps for
this scenario. See Performing a Basic Migration with the Replica Instances Online
on page52.
Procedure
Next Steps
Appliance 3.0
Before You Begin
Attach a keyboard and monitor to the appliance
Procedure
sudo reboot
press ENTER.
ENTER.
Next Steps
Deploy the hardware appliance and perform Quick Setup to configure the version
8.1 appliance as an instance. For instructions, see the RSA Authentication
Manager 8.1 Setup and Configuration Guide.
Review the high-level procedure for this scenario to determine your next steps.
See Performing a Basic Migration with the Replica Instances Online on page52.
Export Data
To migrate existing version 7.1 data to version 8.1, you must create a migration
package using the Migration Export Utility.
line version of the RSA AuthenticationManager 7.1MigrationExport Utility.
This procedure stops services on the primary instance. After export, services stay
stopped on the primary instance.
Before You Begin
Review the high-level steps of this scenario to make sure that you understand the
overall procedure. See Performing a Basic Migration with the Replica Instances
Online on page52.
Procedure
a. Using an SSH client, log on to the Appliance operating system with the User
ID emcsrv, and the operating system password created during Quick Setup.
sudo su -
and press ENTER.
c. When you are prompted for a password, enter the operating system password
specified during Quick Setup.
ENTER.
type 2 to select Production Environment, and press ENTER.
4. On the Migration Options screen, type 1 to select Option 1: Basic Migration
(Replica Instances Online), and press ENTER.
and press ENTER.
import operation.
or ~.
Manager 8.1.
ENTER.
10. Confirm the selected migration option and the location of the migration package.
When you begin the export, the utility stops services on the primary instance.
The utility stops services on the primary instance and displays a list of completed
export tasks while it generates the migration package. If you have replica
instances on version7.1, replication stops but the replica instances continue to
authenticate users while the primary instance is unavailable.
Next Steps
this option.
Quick Setup.
to manually copy the migration package to the Authentication Manager 8.1 server
to expedite the import.
Manager 8.1.
If you tested the migration process, you can either retain or overwrite the system
settings and the deployment topology of the 8.1 testing environment.
All version 7.1 administrative accounts are migrated. The 7.1 Super Admin and
Operations Console administrator accounts replace the Super Admin and Operations
Console administrator accounts that are created during the version8.1 Quick Setup.
Before You Begin
Export data from a 7.1 primary instance. For instructions, see Export Data on
page56.
locations:
Your local machine
Quick Setup.
Procedure
instance.
local machine.
Password field.
5. Click Next.
following:
your local machine.
d. Click Next.
version8.1.
package.
package.
b. Click Next.
10. Click Next.
12. Click Done.
Next Steps
page162.
Review the high-level steps to determine the next step that applies to your
deployment. See Performing a Basic Migration with the Replica Instances Online
on page52.
Change the Hostname and IP Address of the Primary Instance
If you tested the migration process and in turn, created a temporary 8.1 primary
instance with a unique hostname and IP address on what was originally a 7.1 replica,
you can configure the instance with its original 7.1 network settings. This allows you
to recreate your 7.1 deployment in version 8.1.
When you use the same hostname and IP address as version 7.1, authentication agents
can communicate with the 8.1 primary instance, thus allowing the 8.1 primary
instance to be in production.
If you do not want to give the 8.1 primary instance the same hostname and IP address
as the 7.1 primary instance, you must generate a new configuration (sdconf.rec) file
and distribute the file to the authentication agents.
Perform this procedure to configure the temporary 8.1 primary instance with the
hostname and IP address of the original version 7.1 replica.
Before You Begin
Ensure that you have exported data from the 7.1 primary instance and imported
the data to the 8.1 primary instance.
this scenario. See Performing a Basic Migration with the Replica Instances Online
on page52.
Procedure
1. On the 8.1 primary instance, log on to the Operations Console.
2. Click Administration > Network > Appliance Network Settings.
3. Under Global Settings, configure the following:
In the Fully Qualified Domain Name field, modify the fully qualified
domain name (FQDN).
For DNS Servers, add, update or remove an IP address from the list of IP
addresses for DNS servers.
To add an IP address, enter the IP address in the DNS Server IP Address
field and click Add.
To update an IP address, select the IP address from the list, modify the IP
address in the DNS Server IP Address field and click Update.
To remove an IP address, select the IP address form the list and click
Remove.
To change the order in which the DNS servers are used, select an IP
address and click the up or down arrow.
You may enter multiple IP addresses, and specify the order. Authentication
Manager submits DNS lookup queries to the DNS servers in the order listed.
For DNS Search Domains, add, update or remove a domain from the list of
DNS search domains.
To add a search domain, enter the name of the domain in the DNS Search
Domain field and click Add.
To update a search domain, select the name of the domain from the list,
modify the name in the DNS Search Domain field and click Update.
To remove a search domain, select the domain from the list and click
Remove.
To change the order in which the domains are searched, select the domain
and click the up or down arrow.
You may enter multiple search domains, and specify the order. Authentication
Manager uses the search domains in the order listed.
4. For each network interface card (NIC) that you want to use, configure the
following:
a. In the IPv4 Address field, modify the IP address.
b. In the IPv4 Subnet Mask field, modify the subnet mask.
c. In the IPv4 Default Gateway field, modify the IP address.
To configure an additional NIC, select the Enabled checkbox under the name of
the NIC, and configure the settings.
RSA recommends using a different subnet for each NIC. If two NICs share the
same subnet and one NIC becomes unavailable, then Authentication Manager
services will not be available on either NIC.
Note: Configure IPv6 Settings only if your deployment contains authentication
agents that use the IPv6 protocol. The IPv6 settings contain an additional field,
IPv6 Prefix.
5. Click Next. The Operations Console displays a review page.
6. Review the changes you made, highlighted in bold and italic. Click Apply
Network Settings to accept the changes, click Back to make additional changes,
or click Cancel.
To apply the changes, Authentication Manager restarts the system-level
networking service. If you changed the hostname or IP address, Authentication
Manager restarts additional services. After the services are running, the
Operations Console and the Security Console are available at the new hostname
and IP address.
Next Steps
Determine if you need to perform the tasks described in Additional Tasks for a
Changed Hostname and IP Address on the Version8.1 Primary Instance on
page64.
See Performing a Basic Migration with the Replica Instances Online on page52.
Additional Tasks for a Changed Hostname and IP Address on the Version 8.1
Primary Instance
Determine whether you need to complete the following tasks after changing the
hostname and IP address of the 8.1 primary instance.
Task Reference
In a replicated deployment, log on to the replica
instance Operations Console and update the primary
instance hostname and IP address on the replica
instance.
See the Operations Console topic
Update the Primary Instance
Hostname and IP Address on a
Replica Instance.
If you install a third-party SSL certificate, the
certificate is deactivated after you change the
hostname, and the deployment reverts to the RSA
SSL certificate that is enabled when the instance is
deployed.
To replace the RSA SSL certificate, import a new
third-party SSL certificate whose common name
(CN) is the new hostname.
See the Operations Console Help
topic Replacing the Console
Certificate.
If the 8.1 deployment includes trusted realms, you
must reestablish trusted realm relationships.
Reestablishing Trusted Realm
Relationships on page116
If the 8.1 deployment includes a web tier, you must
do the following:
In a deployment with a standalone primary
instance, you must reinstall the web tier.
In a replicated deployment, the web tier obtains
the primary instance hostname from a replica
instance. After you update the primary instance
hostname on every replica instance, wait five
minutes for the web tier to update. You can make
additional hostname changes as needed.
See the chapter Installing Web
Tiers in the RSA Authentication
Manager 8.1 Setup and
If the 7.1 deployment included a remote RADIUS
server, you must update RADIUS clients with the
new 8.1 hostname, IP address, or both.
For more information about
updating the RADIUS clients, see
your RADIUS client
documentation.
If necessary, update other external clients such as
SNMP clients to use the new hostname and IP
address.
See the documentation for your
client.
In a replicated deployment, check the replication
status. Synchronize the replica instances, if
necessary.
Synchronize a Replica Instance.
Check the replication status for RADIUS. See the Security Console Help
topic Initiate Replication to
RADIUS Replica Servers.
5: Performing a Basic Migration with All Instances Offline 65
5 Performing a Basic Migration with All
Instances Offline
Scenario 2: Basic Migration with All Instances Offline
A Basic Migration with all instances offline migrates data from the 7.1 primary
instance while the primary and replica instances are made unavailable.
During this type of migration, the following applies:
Before exporting, you must manually stop services on the replica instances to
prevent data collection while the primary is offline. Version7.1 deployment data
can be exported without losing the data that would have been recorded by the
replica instances.
The utility stops services on the primary instance to prevent database changes.
After export, services remain stopped on the primary instance.
Administration is down until the 8.1 primary instance is available.
version 8.1 and start authentication on version 8.1.
66 5: Performing a Basic Migration with All Instances Offline
For a detailed description of steps, see Performing a Basic Migration with All
Instances Offline on page68.
tested the migration, you must change the unique hostname and IP address of the 8.1
primary instance to the settings that applied when the appliance was a 7.1 replica
In this scenario, creating a temporary 8.1 primary instance allows you to migrate the
version 7.1 deployment to version8.1 with minimal authentication downtime.
Although services are stopped on the 7.1 deployment, the 8.1 deployment is in
production and authenticates users after the primary 8.1 appliance uses the IP address
that was used on the 3.0 appliance in version 7.1.
instance and demote the existing 8.1 primary instance to a replica instance. Because
every instance ultimately reuses the hostname and IP address that was previously used
in version 7.1, there is no need to update authentication agents.
Note: If you need to roll back the migration process and the replica instances have not
replicated data to the 7.1 primary instance in more than seven days, you must reattach
the replica instance. For more information, see AppendixD, Restoring a Hardware
Appliance.
migration package from version 7.1 with the latest data. You can either retain the
system settings and deployment topology of the test environment and import the
remaining data, or completely overwrite the database with the new migration package.
If you overwrite the database, you lose the data from the test environment. To
understand more about pre-production and the import options, see Pre-Production and
Migration Import Options on page16.
Performing a Basic Migration with All Instances Offline
Use this procedure to migrate data from the 7.1 primary instance. In this procedure,
you stop services. Authentication is down until the hostname and IP address of an
instance on the 8.1 deployment is changed to match the hostname and IP address of
version 7.1, or a new configuration file is distributed to authentication agents.
Before You Begin
Procedure
1. Stop RSA Authentication Manager services on the 7.1 replica instances. For
instructions, see the RSA SecurIDAppliance 3.0 product documentation.
2. If you did not test the migration process, do the following to create the temporary
b. On the 7.1 replica instance, install Authentication Manager 8.1. For
instructions, see Install RSA Authentication Manager 8.1 on the RSA SecurID
Appliance 3.0 on page71.
from the RSA Authentication Manager 7.1 primary instance. See Export Data on
page72.
see Import Data to RSA Authentication Manager 8.1 on page75.
6. For each remaining replica instance that you want to upgrade to version 8.1, do
the following:
a. Back up the hardware appliance for the instance. You must create a backup
image of the hardware appliance, in case you need to restore RSA
Authentication Manager 7.1. RSA recommends using PING. For instructions,
see Create a Backup Image of the Hardware Appliance on page70.
b. Install Authentication Manager 8.1. For instructions, see Install RSA
7.1.
d. Attach the replica instance. For instructions, see the chapter Deploying a
e. Repeats steps 6a to 6d on each 7.1 replica instance.
7. Upgrade and configure the version 7.1 primary instance as a version 8.1 replica
instance. To do this, complete steps 6a to 6d on the version 7.1 primary appliance.
8. To make the former version 7.1 primary instance a primary instance in the 8.1
deployment, perform a promotion for maintenance.
A promotion for maintenance promotes a replica instance as the primary instance
and automatically demotes the existing primary instance to a replica instance.
drive.
Before You Begin
USB drive
this scenario. See Performing a Basic Migration with All Instances Offline on
page68.
Procedure
Next Steps
Appliance 3.0
Before You Begin
Procedure
sudo reboot
press ENTER.
ENTER.
Next Steps
Review the high-level steps to determine your next steps. See Performing a Basic
Migration with All Instances Offline on page68.
Export Data
Before You Begin
overall procedure. See Performing a Basic Migration with All Instances Offline
on page68.
Stop RSA Authentication Manager services on the 7.1 replica instances. For
instructions, see the RSA SecurIDAppliance 3.0 product documentation.
Procedure
sudo su -
and press ENTER.
ENTER.
4. On the Migration Options screen, type 2 to select Option 2: Basic Migration (All
Instances Offline), and press ENTER.
and press ENTER.
import operation.
or ~.
Manager 8.1.
ENTER.
export tasks while it generates a migration package.
Next Steps
this option.
/opt/rsa/am/migration. To copy the migration package to version 8.1, you
Quick Setup.
Manager 8.1.
administrator accounts that are created during the version 8.1 Quick Setup.
Before You Begin
page72.
locations:
Your local machine
Quick Setup.
Procedure
instance.
local machine.
Password field.
5. Click Next.
following:
your local machine.
d. Click Next.
version8.1.
package.
package.
b. Click Next.
10. Click Next.
12. Click Done.
Next Steps
Verify that the 7.1 data is migrated to version 8.1. For information about
page162.
deployment. See Performing a Basic Migration with All Instances Offline on
page68.
When you use the same hostname and IP address as version 7.1, authentication agents
instance to be in production.
hostname and IP address of the original version 7.1 replica
Before You Begin
this scenario. See Performing a Basic Migration with All Instances Offline on
page68.
Procedure
domain name (FQDN).
Remove.
DNS search domains.
Remove.
following:
IPv6 Prefix.
or click Cancel.
and IP address.
Next Steps
page80.
See Performing a Basic Migration with All Instances Offline on page68.
Primary Instance
Task Reference
instance.
Replica Instance.
deployed.
Certificate.
do the following:
your RADIUS client
documentation.
address.
client.
necessary.
6: Performing an Advanced Migration 81
6 Performing an Advanced Migration
Scenario 3: Advanced Migration
If you perform an Advanced Migration, you migrate data from the primary instance,
and the authentication updates that are recorded on the replica instances. The
following applies:
All services stop on the primary instance to ensure that data does not change
during the export, and that all data is completely exported. After export, services
are stopped.
While services are stopped on the primary instance, the 7.1 replica instances
authenticate users. Data that is recorded by the replica instances can be exported
later, thus no data is lost. To export updates from the replica instances, the RSA
Authentication Manager 7.1 Migration Export Utility must be installed and run on
each replica instance.
Although administration is available on 8.1, you may not be able to administer
users who authenticate to the 7.1 replica instances. For example, if a 7.1 replica
instance logs a locked user account and this event is not captured by the 8.1
primary instance, you cannot resolve this issue until you migrate the
authentication updates from the replica instance.
During the migration process an instance in both the version 7.1 deployment and
the version 8.1 deployment may be available to authenticate users. This means
that data between the 7.1 and 8.1 deployments may be out-of-sync until the
authentication updates from the 7.1 replica instances are migrated.
When exporting data from the 7.1 primary instance, the RSA Authentication Manager
7.1 Migration Export Utility configures the replica instances to capture authentication
updates, for example PIN changes, so that the utility can export this data later in the
migration. The utility records data for export purposes only. For a list of authentication
updates that are migrated from a replica instance, see Authentication Updates
Migrated from a Version 7.1 Replica Instance on page131.
version8.1 and start authentication on version 8.1.
82 6: Performing an Advanced Migration
For a detailed description of steps, review the steps of this migration scenario. See
Performing an Advanced Migration on page84.
tested the migration, you must change the unique hostname and IP address of the
8.1primary instance to the settings that applied when the appliance was a 7.1 replica
In this scenario, you also export authentication updates from each replica instance in
your deployment, and import each migration package into the 8.1 primary instance.
Keep in mind that in the process of migrating authentication updates from the 7.1
replica instances, both deployments may be available to authenticate users. As a
result, you may not be able to administer users who authenticate to the 7.1 replica
instances until you migrate the authentication updates from the replica instances. You
should migrate authentication updates as quickly as possible to avoid this issue.
instance and demote the existing 8.1 primary instance to a replica. Because every
instance ultimately reuses the hostname and IP address that was previously used in
version 7.1, there is no need to update authentication agents.
Note: If you perform an Advanced Migration and you must return version 7.1 to its
pre-migration state, a rollback operation is required to resume replication. If the
replica instances have not replicated data to the 7.1 primary instance in more than
seven days, you must reattach the replica instance. For more information about
rollback, see AppendixD, Restoring a Hardware Appliance.
migration package from the 7.1 primary instance with the latest data. You can either
retain the system settings and deployment topology of the test environment and import
the remaining data, or completely overwrite the database with the new migration
package. If you overwrite the database, you lose the data from the test environment.
To understand more about pre-production and the import options, see Pre-Production
and Migration Import Options on page16.
Performing an Advanced Migration
Use this procedure to migrate data from the 7.1 primary instance. In this procedure,
you stop services. Authentication is down until the existing appliance is upgraded to
version 8.1.
Before You Begin
Repair or remove replica instances that cannot communicate with the 7.1 primary
instance. To view the replication status, log on to the Operations Console, and
click Deployment Configuration >Instances >Status Report.
Procedure
1. If you did not test the migration process, do the following to create a temporary
b. On the 7.1 replica appliance, install Authentication Manager. For instructions,
3.0 on page87.
from the RSA Authentication Manager 7.1 primary instance. See Export Data on
page88.
see Import a Migration Package from the Version 7.1 Primary Instance on
page91.
5. For each replica instance that you want to migrate, do the following:
a. Use the Migration Export Utility to export authentication updates such as PIN
and password changes from the replica instance. For more instructions, see
Export Authentication Updates from a Replica Instance on page98.
b. Back up the replica hardware appliance. You must create a backup image of
the hardware appliance, in case you need to restore RSA Authentication
Manager 7.1. RSA recommends using PING. For instructions, see Create a
Backup Image of the Hardware Appliance on page86.
c. On the 8.1 primary instance, import the migration package from the 7.1
replica instance. For instructions, see Import a Migration Package from a
Version7.1 Replica Instance on page100.
d. Install Authentication Manager 8.1 on the replica instance. For instructions,
3.0 on page87.
e. Deploy the hardware appliance and perform Quick Setup to configure the
7.1.
f. Attach the replica instance. For instructions, see the chapter Deploying a
g. Repeat steps 5a to 5f on each 7.1 replica instance.
6. Do the following to the version 7.1 primary instance:
a. Back up the hardware appliance. For instructions, see Create a Backup Image
of the Hardware Appliance on page86.
b. Install Authentication Manager 8.1. For instructions, see Install RSA
7.1.
7. If you want to use the former version 7.1 primary instance as the primary in the
8.1 deployment, perform a promotion for maintenance.
A promotion for maintenance promotes a replica instance to become the primary
instance and automatically demotes the existing primary instance to a replica
instance.
Before installing version8.1, you must create a backup image of
drive.
Before You Begin
USB drive
this scenario. See Performing an Advanced Migration on page84.
Procedure
Next Steps
Appliance 3.0
Before You Begin
the Hardware Appliance on page86
Procedure
sudo reboot
press ENTER.
ENTER.
Next Steps
See Performing an Advanced Migration on page84.
Export Data
The utility also prepares the replica instances for exporting authentication updates
such as PIN and password changes that are recorded on the replica instances while
services are stopped on the primary instance.
Before You Begin
overall procedure. See Performing an Advanced Migration on page84.
Procedure
sudo su -
and press ENTER.
ENTER.
4. On the Migration Options screen, type 3 to select Option 3: Advanced
Migration, and press ENTER.
and press ENTER.
import operation.
or ~.
Manager 8.1.
ENTER.
The utility displays a list of completed export tasks while it generates a migration
package. Services on the primary instance and replication are stopped. The 7.1
replica instances authenticate users while the primary instance is unavailable.
Next Steps
this option.
Quick Setup.
Import data to the 8.1 primary instance. For instructions, see, Import a Migration
Package from the Version 7.1 Primary Instance on page91.
Import a Migration Package from the Version 7.1 Primary Instance
Manager 8.1.
administrator accounts that are created during the version 8.1 Quick Setup.
Before You Begin
page88.
locations:
Your local machine
Quick Setup.
Procedure
instance.
local machine.
Password field.
5. Click Next.
following:
your local machine.
d. Click Next.
version8.1.
package.
package.
b. Click Next.
10. Click Next.
12. Click Done.
Next Steps
page162.
deployment. See Performing an Advanced Migration on page84
When you use the same hostname and IP address as version7.1, authentication agents
instance to be in production. While authentication resumes on the 8.1 primary
instance, you may not be able to administer users who authenticate to the 7.1 replica
instances. For example, if a 7.1 replica instance logs a locked user account and this
event is not captured by the 8.1 primary instance, you cannot resolve this issue until
you migrate the authenticate updates from the replica instance.
hostname and IP address of the original version 7.1 replica
Before You Begin
Procedure
domain name (FQDN).
Remove.
DNS search domains.
Remove.
following:
IPv6 Prefix.
or click Cancel.
and IP address.
Next Steps
page97.
Primary Instance
Task Reference
instance.
Replica Instance.
deployed.
Certificate.
do the following:
your RADIUS client
documentation.
address.
client.
necessary.
Export Authentication Updates from a Replica Instance
Use this procedure to export authentication updates, such as PIN and password
changes from a 7.1 replica instance with the command line version of the
RSA AuthenticationManager 7.1MigrationExport Utility.
This procedure stops services on a replica instance. After export, services stay stopped
on the replica instance.
Before You Begin
Install the Migration Export Utility on the replica instance. For instructions, see
the Migration Export Utility Installation on page28.
Procedure
1. If you run the Migration Export Utility immediately after installing it, go to step 2.
If you choose to run the utility later, do the following:
b. Changes user to root. Type:
sudo su -
and press ENTER.
ENTER.
and press ENTER.
Remember the location. You need to know this location to access the migration
package for the import operation.
or ~.
Manager 8.1.
ENTER.
7. Confirm that the utility will export data from the replica instance, and the location
of the migration package.
A warning message indicates that the utility will stop services on the replica
instance.
The utility displays a list of completed export tasks while it generates a migration
package. Services are stopped on the replica instance.
Next Steps
this option.
Quick Setup.
Import the migration package from the replica instance to the 8.1 primary
instance. For instructions, see Import a Migration Package from a Version7.1
Replica Instance on page100.
Import a Migration Package from a Version 7.1 Replica Instance
Use this procedure to import a migration package from a 7.1 replica instance.
The import process merges authentication updates from a 7.1 replica instance into
version 8.1.
Before You Begin
Export authentication updates from a 7.1 replica instance. For instructions, see
Export Authentication Updates from a Replica Instance on page98.
locations:
Your local machine
Procedure
instance.
local machine.
Password field.
5. Click Next.
If the Confirmation screen displays, skip step 6, and go to step 7.
following:
a. In the Package File Location drop down list, select the migration package
your local machine.
d. Click Next.
9. Click Next.
11. Click Done.
Next Steps
7: Post-Migration Tasks 103
7 Post-Migration Tasks
After completing a migration, additional tasks may be required. Complete the steps
that apply to your deployment.
If you did pre-production testing and when performing a migration scenario,
retained the settings, see Post-Migration Tasks When Version 8.1 Settings Are
Retained During Import on page103.
If you did pre-production testing but did not retain the settings when performing a
migration scenario, see Post-Migration Tasks When the Version 8.1 Database is
Completely Overwritten During Import on page107.
If you chose not to complete pre-production testing, see Post-Migration Tasks
When the Version 8.1 Database is Completely Overwritten During Import on
page107.
Post-Migration Tasks When Version 8.1 Settings Are Retained
During Import
The following post-migration tasks may be required if you retained the deployment
topology and the system settings of the pre-production, testing environment.
These lists are organized with tasks based on the completion of the pre-production
setup tasks in Chapter 3, Pre-Production and Testing Version 8.1. If you did not
complete any pre-production task and you retained settings during the import, you can
perform any overlooked task after migration.
If you migrated without testing or completely overwrote the pre-production settings at
import, see Post-Migration Tasks When the Version 8.1 Database is Completely
Overwritten During Import on page107.
104 7: Post-Migration Tasks
The following table lists post-migration tasks related to the 8.1 deployment
configuration.
Administration
The following table lists post-migration tasks related to administration.
Reestablish trusted realm
relationships.
After migration, you must reestablish trusted
realm relationships with the realms that trusted
the original 7.1 deployment.
Configure settings for 7.1
realms.
In version 8.1, 7.1 realms are converted to
security domains.
If the 7.1 deployment has multiple realms, you
can ensure a similar organizational hierarchy
in version8.1.
Reconfigure Converted Version
7.1 Realms After Migration on
page120
Reconfigure any identity
source connection to a
replica instance.
If you configured an identity source to connect
to a 7.1 replica instance, this configuration is
not migrated. On the 8.1 primary instance, you
can edit the identity source and manually
configure the identity source to connect to an
8.1 replica instance.
Edit an Identity Source
Configure new administrative
role permissions.
Version 8.1 includes new administrative role
permissions. To assign new permissions, you
must edit existing administrative roles and
assign the permission, or create a new role
with the required permission.
Administrative Role
Permissions in Version 8.1
on page121
Allow Token Distributors to
view users in their scope.
After migration, the Token Distributor
administrative role does not include the
permission to view users. You need to
manually enable this general permission.
Edit an Administrative
Role
RSA RADIUS
The following table lists a post-migration task related to RSA RADIUS.
The following table lists a post-migration task related to authentication agents.
Update RADIUS clients
with the hostname or IP
address associated with the
RADIUS server.
Perform this task when either of the following
applies:
You migrated data from a remote RADIUS
server. As a result, the RADIUS clients do
not contain the hostname, IP address, or
both of the RADIUS server on the 8.1
instance.
You migrated data from a local RADIUS
server and completed a migration where the
8.1 deployment has a different hostname
and IP address than the original 7.1
deployment.
See your RADIUS client
documentation
Notify administrators who
are not Super Admins and
originally had permission to
edit or view RADIUS
setting in 7.1 that they no
longer have this permission.
In version 8.1, the permission to edit or view
RADIUS settings for administrators who are
not Super Admins is not migrated. In 8.1, you
must be a Super Admin to edit or view the
following RADIUS settings:
Selected RADIUS profile priority
Default RADIUS profile
Whether RADIUS attributes are sent to the
RADIUS server
Selected RADIUS Attribute Format
Notify administrators who are affected by this
change that they can no longer edit or view
RADIUS settings.
If an administrator requires the ability to edit
or view RADIUS settings, assign the Super
Admin role to him or her.
Assign an Administrative
Role
Assign Manual Contact
Lists.
If you created manual contact lists during
pre-production, you must assign the contacts
lists to the authentication agents.
Assign a Contact List to an
Authentication Agent
Reporting
The following table lists a post-migration task related to reporting.
Self-Service
The following table lists a post-migration task related to self-service.
After migration, you cannot identify the
device type of a 7.1 distributed software token
when viewing or managing the token. If you
want to see the device type of a migrated
software token, you must run a report job
using the Software Tokens template.
Add a Report.
Run a Report J ob
Retain custom SQL queries
created in version 7.1.
If you created custom SQL queries for
enhanced reporting, the read-only user account
in version 7.1 that allows access to the internal
database is not migrated to version 8.1.
If you want to continue using custom SQL
queries, you must do the following:
Recreate the read-only user account using
the version 8.1 Manage Readonly Database
Users utility, manage-readonly-dbusers.
Verify that your SQL queries continue
working with the version 8.1 SDK.
See SQL Access to the RSA
Authentication Manager
Database in the RSA
Developer's Guide.
Advise migrated self-service
users to request a new
software token when they
need to replace a software
token or report a lost or
damaged token.
After migration, self-service users cannot
request replacement software tokens until you
associate the tokens with a software token
profile. To avoid redistributing all migrated
software tokens, advise self-service users to
request a new token when they need to replace
a token or report a lost or damaged token. In
the token request, users can describe the
reason for the request.
If you redistribute a migrated software token
using a software token profile, users can
request a replacement token as they would
normally. After redistributing a software
token, a user cannot authenticate until he or
she imports the new token to the client device.
Software Token Profiles
Instruct self-service users to
see the Self-Service Console
Help topic Request an
Additional Token
Post-Migration Tasks When the Version 8.1 Database is Completely
Overwritten During Import
Complete the tasks that are applicable to your deployment when one of the following
applies:
You did not create an 8.1 pre-production test environment and imported data for
the first time during migration.
You created an 8.1 pre-production test environment, and chose to overwrite the
deployment topology and the system settings of the test environment during
migration.
The following table lists post-migration tasks related to the 8.1 deployment
configuration.
Reestablish trusted realm
relationships.
After migration, you must reestablish trusted
realm relationships with the realms that trusted
the original 7.1 deployment.
Configure settings for 7.1
realms.
Version 7.1 realms are converted to security
domains in version 8.1.
If the 7.1 deployment has multiple realms, you
can complete post-migration steps to ensure a
similar organizational hierarchy.
Reconfigure Converted Version
7.1 Realms After Migration on
page120
Install a web tier (optional). A web tier is a secure platform for installing
and deploying the Self-Service Console,
dynamic seed provisioning, and the risk-based
authentication (RBA) service.
The chapter Installing Web
Tiers in the RSA
Setup and Configuration Guide
Manage application trust,
console, and virtual host
certificates.
You can import the following certificates:
Application trust certificate
Console certificate
topics:
Add a New Application
Trust Certificate
Import a Console
Certificate
Import a Signed Virtual
Host Certificate
Reconfigure any identity
source connection to a
replica instance
If you configured an identity source to connect
to a 7.1 replica instance, this configuration is
not migrated. On the 8.1 primary instance, you
can edit the identity source and manually
configure the identity source to connect to an
8.1 replica instance.
Edit an Identity Source
RSA RADIUS
The following table lists post-migration tasks related to RSA RADIUS.
Update RADIUS clients
with the hostname or IP
address associated with the
RADIUS server.
Perform this task when either of the following
applies:
You migrated data from a remote RADIUS
server. As a result, the RADIUS clients do
not contain the hostname, IP address, or
both of the RADIUS server on the 8.1
instance.
You migrated data from a local RADIUS
server and completed a migration where the
8.1 deployment has a different hostname
and IP address than the original 7.1
deployment.
See your RADIUS client
documentation.
Add trusted root certificates
to the primary RADIUS
server.
The trusted root certificates for the RSA
RADIUS servers are not migrated.
To ensure that the RSA RADIUS server can
verify the identity of a RADIUS client during
Extensible Authentication Protocol-Tunneled
Transport Layer Security (EAP-TTLS)
authentications, you must manually add a
trusted root certificate to the primary RADIUS
server on the 8.1 primary instance.
Add a Trusted Root
Certificate
Edit RSA RADIUS
configuration files.
The 7.1 RADIUS configuration files are not
migrated.
If you edited the default settings of the
RADIUS configuration files in version 7.1,
you must apply these settings to the RADIUS
In the 8.1 RADIUS configuration files, apply
any changes that you made to the RADIUS
Edit RADIUS Server Files
Add, edit, or copy RADIUS
dictionary files from a
remote RADIUS server.
The dictionary files from a remote RADIUS
server are not migrated.
You can do one of the following:
If your 7.1 deployment has multiple
customized RADIUS dictionary files for a
remote RADIUS server and you want to
make these files available to the RADIUS
server on an 8.1 instance, you can use a
Secure Copy Protocol (SCP) to manually
copy files from the remote RADIUS server
to RSA Authentication Manager 8.1.
If your 7.1 deployment has only a few
customized dictionary files for a remote
RADIUS server and you want to make these
files available to the RADIUS server on an
8.1 instance, you can use the 8.1 Operations
Console to upload individual RADIUS
dictionary files to RSA Authentication
Manager 8.1.
If your 7.1 deployment contains edits to
existing remote RADIUS dictionary files,
you can make these edits to the RADIUS
dictionary files on an 8.1 instance.
To copy files from version
7.1 to version 8.1 using an
SCP client, see Copy the
RADIUS Dictionary Files on
page122.
To add a new RADIUS
dictionary, see the
topic Add a RADIUS
Dictionary.
To edit an existing remote
RADIUS dictionary file, see
the Operations Console Help
topic Edit RADIUS Server
Files.
Replace RSA RADIUS
server certificate, if
necessary.
If you replaced the RSA RADIUS server
certificate with another certificate in version
7.1, and you want to use this certificate in
version 8.1, you must replace the RSA
RADIUS server certificate through the
Operations Console.
To replace the 8.1 RSA RADIUS server
certificate with the certificate that you used in
version 7.1, you must copy the certificate from
version 7.1 and use the 8.1 Operations Console
to replace the certificate.
Replace a RADIUS Server
Certificate
Authentication
The following table lists post-migration tasks related to authentication.
Notify administrators who
are not Super Admins and
originally had permission to
edit or view RADIUS
setting in 7.1 that they no
longer have this permission.
In version 8.1, the permission to edit or view
RADIUS settings for administrators who are
not Super Admins is not migrated. In 8.1, you
must be a Super Admin to edit or view the
following RADIUS settings:
Selected RADIUS profile priority
Whether RADIUS attributes are sent to the
RADIUS server
Selected RADIUS Attribute Format
Notify administrators who are affected by this
change that they can no longer edit or view
RADIUS settings.
If an administrator requires the ability to edit
or view RADIUS settings, assign the Super
Admin role to him or her.
Assign an Administrative
Role
Create software token
profiles.
In version 8.1, software token device types are
associated with a software token profile.
Software token profiles specify software token
configuration and distribution options. You
must configure a software token profile for
each platform to which you plan to distribute
software tokens.
Add a Software Token
Profile
The chapter Deploying and
Administering RSA SecurID
Tokens in the RSA
Administrators Guide
Configure alternative
instance IP addresses.
Alternative IP addresses are not migrated for
an 7.1 instance. If you want an 8.1 instance to
use an alterative IP address, you set it in
version8.1.
Add Alternative IP Addresses
for Instances
The following table lists a post-migration task related to authentication agents.
Configure Short Message
Service (SMS) settings for
Clickatell.
If you used the Clickatell plug-in for
version7.1, you must select HTTP as the SMS
plug-in and reconfigure these settings in
version8.1.
The RSA SMS HTTP Plug-In
Implementation Guide that is
available through the EMC
Solutions Gallery at
https://gallery.emc.com/co
mmunity/marketplace?vie
w=overview. On the
website, search for the title
of the document. Under
Clickatell Gateway, click the
Collateral tab to locate the
document.
Configure the HTTP
Plug-In for On-Demand
Tokencode Delivery
Create and assign manual
contact lists.
Version 7.1 agent contact lists are not
migrated. If you want to use a manual contact
list in version 8.1, you must create the agent
contact and assign the contact list to an
authentication agent.
Add a Manual Contact List
Assign a Contact List to an
The following table lists post-migration tasks related to system configuration.
Configure Simple Network
Management Protocol
(SNMP) settings.
SNMP settings are not migrated from version
7.1.
If you previously configured SNMP and you
want to apply these settings to the 8.1
deployment, you must reconfigure these
settings.
You must use SNMP clients that support
SNMP Version 3.
Configure SNMP
Configure logging settings. In version8.1, you can configure the log levels
and the following log data destinations for
administrative audit, runtime audit, or system
log data:
Database only
Database and local operating system
SysLog
Database and remote SysLog host
Any modification that was made to the 7.1
ims.properties file to allow Authentication
Manager to send log messages to a local or
remote Syslog is not migrated.
Configure Logging
Configure critical system
event notification.
If you want to notify administrators
immediately by e-mail if a critical system
event occurs, enable critical system event
notifications. This option can notify the Super
Admin or individuals that you choose.
Configure Critical System
Event Notification
Configure operating system
access settings.
You can configure operating system access
settings, including whether to enable Secure
Shell (SSH), session lifetime settings, or
change the operating system password.
topics:
Enable Secure Shell on the
Appliance
Change the Operating
System Account Password
Configure security questions
and security question
requirements.
You can import new security questions and
configure the number of questions that are
required during enrollment or authentication
into the Self-Service Console.
Managing Security
Questions
Import Security Questions
Set Requirements for
Security Questions
Schedule log archival. Log archive jobs are not migrated from the 7.1
deployment. You can reschedule these jobs on
version 8.1.
Archive Logs Using Schedule
Log Archival
Configure log rotation
settings.
Log rotation settings prevent the appliance
operating system logs from growing
indefinitely. You can configure how and when
the appliance logs are rotated.
Configure Appliance Log
Settings
Configure date and time
settings.
If necessary, you can update the system date
and time settings.
Update System Date and Time
Settings
Configure session handling
settings.
Version7.1 session handling settings are not
migrated. You can apply the session handling
settings that were previously used in version
7.1.
Configure Session Handling
Reconfigure scheduled
backups.
Scheduled backup jobs are not migrated. On
version8.1, reconfigure scheduled backups.
Create a Backup Using
Schedule Backups
Specify product update
locations.
To allow version8.1 to locate product updates,
you must specify the location where updates
are stored.
Specify a Product Update
Location
Edit session lifetime
settings.
Session lifetime settings and custom session
lifetime from version 7.1 are not migrated.
You can edit the session lifetime settings in
version 8.1
Edit Session Lifetime
Settings
Configure Simple Mail
Transfer Protocol (SMTP)
and caching settings for a
replica instance.
The SMTP and caching settings associated
with a replica instance are not migrated. If you
configured these settings for a 7.1 replica
instance and you want to apply them in
version8.1, you must reconfigure the SMTP
and the caching settings for an 8.1 replica
instance.
Configure the SMTP Mail
Service
Configure the Cache
Self-Service
The following table lists post-migration tasks related to self-service.
Select the software tokens
available for users to request
through the Self-Service
Console.
After you create software token profiles for the
device types you need, you can select the
software tokens that are available for users to
request through the Self-Service Console.
On the Manage Authenticator page in the 8.1
Security Console, select the software token
profile of the software token that you want to
make available for request, and configure the
options associated with the software token.
Select Software Tokens for
Provisioning
Advise migrated self-service
users to request a new
software token when they
need to replace a software
token or report a lost or
damaged token.
After migration, self-service users cannot
request replacement software tokens until you
associate the tokens with a software token
profile. To avoid redistributing all migrated
software tokens, advise self-service users to
request a new token when they need to replace
a token or report a lost or damaged token. In
the token request, users can describe the
reason for the request.
If you redistribute a migrated software token
using a software token profile, users can
request a replacement token as they would
normally. After redistributing a software
token, a user cannot authenticate until he or
she imports the new token to the client device.
Software Token Profiles
Instruct self-service users to
see the Self-Service Console
Help topic Request an
Additional Token
Modify 7.1 e-mail
notification templates.
In version 8.1, e-mail notification templates
use the tag ConfirmNumber for all requests,
while the 7.1 e-mail notification templates use
the tag RequestID.
After migration, you must modify migrated
e-mail templates to use the ConfirmNumber
tag.
Update the E-mail Notification
Template After Migrating from
Version 7.1 on page122
Administration
The following table lists post-migration tasks related to administration.
template.
If you want to reuse the e-mail notification
template for approved software token requests,
modify the 7.1 software token e-mail
notification template for use in version 8.1.
Template After Migration on
page123
Set the shipping address for
user requested tokens.
If a user record includes identity attribute
definitions with the users address, you can
map these attributes to the shipping address
used in the Self-Service Console for token
requests. This option allows a users address to
automatically display when the user requests a
token through the Self-Service Console.
Configure Shipping
Addresses for Hardware
Authenticators
Configure new
administrative role
permissions.
Version 8.1 includes new administrative role
permissions. To assign new permissions, you
must edit existing administrative roles and
assign the permission, or create a new role
with the required permission.
Administrative Role
Permissions in Version 8.1 on
page121
Allow Token Distributors to
view users in their scope.
After migration, the Token Distributor
administrative role does not include the
permission to view users. You need to
manually enable this general permission.
Edit an Administrative Role
Reporting
The following table includes post-migration tasks related to reporting.
Reestablishing Trusted Realm Relationships
A trust relationship gives users in one realm permission to authenticate and access
resources on another realm. In version 8.1, a deployment is a single realm.
An 8.1 deployment can have a trust relationship with realms in version 6.1, 7.1, and
8.1.
After migration, you must reestablish trusted realm relationships with version 7.1 and
version 8.1. Because you reuse the hostname and IP address of version 7.1, you do not
need to reestablish trusted realm relationships with version 6.1.
This process does not require that you add trusted users or trusted user groups. Instead,
use the following procedures to reestablish the connections between the realms.
To reestablish a trust relationship between the migrated version8.1 deployment and a
trusted realm, perform the task that is appropriate for the version of Authentication
Manager in the trusted realm.
After migration, you cannot identify the
device type of a 7.1 distributed software token
when viewing or managing the token. If you
want to see the device type of a migrated
software token, you must run a report job
using the Software Tokens template.
Add a Report.
Run a Report J ob
Retain custom SQL queries
created in version 7.1.
If you created custom SQL queries for
enhanced reporting, the read-only user account
in version 7.1 that allows access to the internal
database is not migrated to version 8.1.
If you want to continue using custom SQL
queries, you must do the following:
Recreate the read-only user account using
the version 8.1 Manage Readonly Database
Users utility, manage-readonly-dbusers.
Verify that your SQL queries continue
working with the version 8.1 SDK.
See SQL Access to the RSA
Database in the RSA
Developer's Guide.
Reestablish a Trust with a Version 7.1 Realm
Regardless of the hostname and IP address of the version 8.1 deployment, you must
reestablish a trust with a version 7.1 realm. Use the following procedure to reestablish
a trust between the migrated version 8.1 realm and the version 7.1 realm.
Before You Begin
You and the 7.1 trusted realm administrator must communicate directly while
performing this procedure.
Procedure
1. On version 8.1, generate a trust package and securely send this package to the 7.1
trusted realm administrator. To generate a trust package, do the following:
a. In the 8.1 Security Console, click Administration >Trusted Realms >
Manage Existing.
b. Under Trusted Realm Name, click the 7.1 trusted realm that you need to
repair.
c. From the Context menu, click Generate Trust Package and save the file
(TrustPackage.xml).
2. Instruct the 7.1 trusted realm administrator to import the 8.1 trust package and
record the Current Realm Confirmation Code. For instructions, advise the 7.1
trusted realm administrator to see the Security Console Help topic Reimport a
Trust Package.
3. As part of import, the 7.1 trusted realm administrator must verify the Trusted
Realm Confirmation Code. On version 8.1, do the following to locate the
confirmation code for your realm and share the confirmation code with the 7.1
trusted realm administrator:
Manage Existing.
repair.
c. From the Context menu, click View, and locate the confirmation code for the
Current Realm Confirmation Code. Read the code to the 7.1 trusted realm
administrator to confirm that the trust package is valid.
The version 8.1 Current Realm Confirmation Code and the 7.1 Trusted
Realm Confirmation Code must match. If the confirmation codes do not
match, you must generate and securely send the 7.1 trusted realm
administrator a new trust package.
4. After reimport, instruct the 7.1 trusted realm administrator to generate a trust
package and securely send this package to you. For instructions, advise the 7.1
trusted realm administrator to see the 7.1 Security Console Help topic Generate a
Trust Package for Reimport.
5. On version 8.1, import the 7.1 trust package to repair the trusted realm
relationship. To import the 7.1 trust package and complete the repair, do the
following:
a. After receiving the trust package, in the 8.1 Security Console, click
Administration >Trusted Realms >Manage Existing.
repair.
c. From the Context menu, click Repair Trust.
d. In the Trust Package from Trusted Realm field, enter the path to the new
trust package by browsing to the package file, and click Open.
e. Click Next, and contact the 7.1 realm administrator to verify the confirmation
code.
The 7.1 trusted realm administrator must share the Current Realm
Confirmation Code. The confirmation code must match the Trusted Realm
Confirmation Code that displays in version 8.1. If the confirmation codes do
not match, the 7.1 realm administrator must generate and send a new trust
package.
f. Click Confirm and Next.
g. Click Save.
6. Instruct the 7.1 trusted realm administrator to test communication with the 8.1
trusted realm that is associated with your deployment. If the test is unsuccessful,
the 7.1 trusted realm administrator must restart Authentication Manager services.
For instructions on testing 7.1 trusted realm communication, advise the 7.1 trusted
realm administrator to see the 7.1 Security Console Help topic Test a Trusted
Realm.
For instructions on restarting services, advise the 7.1 trusted realm administrator
to see the RSA Authentication Manager 7.1 product documentation.
Repair a Trust with a Version 8.1 Trusted Realm
If you have a trusted realm relationship with a version 8.1 realm, the trust between the
migrated deployment and the trusted realm must be reestablished. Both trusted realm
administrators must complete the following steps.
Perform the following procedure only after completing a migration. If you need to
perform a repair after restoring a backup file, see the RSA Authentication Manager 8.1
Administrators Guide.
Before You Begin
Procedure
1. You and the trusted realm administrator must generate a trust package and
securely exchange trust packages. To generate a trust package, do the following:
a. In the Security Console, click Administration >Trusted Realms >Manage
Existing.
repair.
(TrustPackage.xml).
2. You and the trusted realm administrator must do the following to import a trust
package.
a. After receiving the trust package, click Administration >Trusted Realms >
Manage Existing.
repair.
e. Click Next, and contact the other realm administrator.
3. You and the trusted administrator must do the following to confirm confirmation
codes and complete the repair process:
a. On the Update Trusted Realm page under Trusted Realm Confirmation
Code, read theTrust Package Confirmation Code to the trusted realm
The Trusted Realm Confirmation Code that displays must match the
Current Realm Confirmation Code that belongs to the trusted realm.
If the confirmation codes do not match, ask the trusted realm administrator to
generate and send a new trust package.
b. Click Confirm and Next.
c. Click Save.
Reconfigure Converted Version 7.1 Realms After Migration
In version 8.1, the 7.1 realms are converted to security domains. The following
applies:
If your 7.1 deployment has multiple realms, the administrative roles and policies
from each realm are not migrated.
Identity source users that were managed in the 7.1 realm are associated with the
new security domain. If an identity source user was never managed in the 7.1
realm, that user is associated with the top-level security domain (SystemDomain).
For more information, see Migration of Multiple Realms from Version 7.1 on page19.
Complete the following high-level tasks in version 8.1 to handle this conversion.
Procedure
1. Recreate the 7.1 realm policies and assign them to the new security domains, or
assign an existing policy to the new security domains. If you do not do this, the
security domains are automatically configured with the default policies. For
instructions, see the Security Console Help topic Choose Policies for a Security
Domain.
2. Recreate the administrative roles that existed in the 7.1 realm with the scope to
manage the new security domains and assign the role to a user, or give existing
administrators the scope to manage the new security domains. For instructions,
see the Security Console Help topic Add an Administrative Role.
3. To automatically add unmanaged users to the new security domains, configure
security domain mapping. If you only want to move some of the users to a specific
security domain, you can manually move users through the Security Console. For
instructions, see the Security Console Help topic Add Default Security Domain
Mappings or Move Users Between Security Domains.
Administrative Role Permissions in Version 8.1
The following table lists administrative role permissions that are new to 8.1. To allow
an administrator to manage features, such as risk-based authentication (RBA) policies,
or perform actions such as enabling users for RBA, you must assign the appropriate
permissions.
To assign the new permissions, you must edit an existing administrative role, or create
a new administrative role. For instructions, see the Security Console Help topics Edit
an Administrative Role or Add an Administrative Role.
The following 7.1 administrative role permissions are no longer supported in 8.1:
Delete RADIUS server. RSA RADIUS is automatically installed and configured
with the product. In 8.1, you can edit or view a RADIUS server, but you cannot
delete a RADIUS server.
RADIUS realm settings. An administrator who is permitted to view or edit
RADIUS realm settings in 7.1 can no longer view or edit the following settings:
RADIUS Profile Priority
Default RADIUS Profile
RADIUS Attribute Format
Sending RADIUS attributes to the RADIUS server upon successful
authentication
In version 8.1, these settings are located in the System Settings page of the
Security Console. You must be a Super Admin to view or edit these settings. Do
one of the following:
If an administrator needs to view or edit these RADIUS settings, assign the
Super Admin role to him or her. For instructions, see the Security Console
Help topic Assign an Administrative Role.
If you do not assign a Super Admin role, notify administrators who are
affected by this change that they can no longer view or edit these RADIUS
settings.
Authentication Grades. Authentication Grades are not supported in 8.1.
Feature Permission
Policies RBA policies
Workflow policies
RBA message policy
Security domains View security questions list
Users Enable users for RBA
Delete RBA device history
Security domain mappings
Copy the RADIUS Dictionary Files
You can use a Secure Copy Protocol (SCP) to manually copy all customized
dictionary files from the RSA AuthenticationManager 7.1 remote RADIUS server to
RSA Authentication Manager 8.1.
If you customized only a few dictionary files and prefer to use the Operations Console
to copy individual files to RSA AuthenticationManager 8.1, see the Operations
Console Help topic Add a RADIUS Dictionary.
Before You Begin
Copy the dictionary files from the following location on the remote RADIUS
server to your local machine:
On Windows: RSA_AM_HOME/radius/Service
On Linux: RSA_AM_HOME/radius
Make sure that SSH is enabled on the RSA Authentication Manager 8.1 primary
instance. For instructions, see the Operations Console Help topic Enable Secure
Shell on the Appliance.
Procedure
1. Log on to the SCP client as rsaadmin, and enter the operating system password.
2. Copy the dictionary files from your local machine to the following location on
RSA AuthenticationManager 8.1:
/opt/rsa/am/radius
Update the E-mail Notification Template After Migrating from
Version 7.1
After migrating from Authentication Manager 7.1 to 8.1, you need to update the
e-mail notification templates. In version8.1, e-mail notification templates use the tag
ConfirmNumber for all requests, while in version7.1 e-mail notification templates
used the tag RequestID. For e-mails created using these templates, these tags are
replaced with unique identifiers for individual user requests. After migration, all 7.1
workflow definitions and e-mail notifications, with the exception of the template for
approved software token requests, are migrated into the version8.1 initial workflow
policy. You can either modify the migrated e-mail notification to reflect
ConfirmNumber instead of RequestID or create a new workflow policy with new
templates. For instructions, see the Security Console Help topics Configure a
Workflow Policy and Change the Default Workflow Policy.
Note: You can update the 8.1 e-mail notification template for approved software token
requests with content from the 7.1 e-mail notification template. For more information,
see Configure the Approved Software Token Notification Template After Migration
on page123.
Procedure
1. In the Security Console, click Setup >Self-Service Settings.
2. Under Provisioning, click Workflow Policies.
3. Use the search fields to find the policy that you want to edit.
4. Select the policy that you want to edit and click Edit from the Context menu.
5. On each Workflow Policy page, under E-mail Notification Templates, replace
every ${UCMRequest.RequestID} tag with ${UCMRequest.ConfirmNumber} in
all templates.
6. Click Save.
Configure the Approved Software Token Notification Template After
Migration
By default, version 8.1 includes an e-mail notification template for approved software
tokens in the initial workflow policy. You can update the e-mail notification template
with content from the 7.1 software token e-mail notification template which you saved
prior to migration, or you can use the e-mail notification template that is provided in
the 8.1 default policy.
If you want to reuse the approved software token template from Authentication
Manager 7.1 after migrating to version 8.1, you need to update the approved software
token notification template you saved prior to migration.
Procedure
1. Open the saved version 7.1 e-mail notification template in a text editor.
2. The mapping for the e-mail template tag ${MailComposer.TokenType}
has changed. The tag now maps to the Device Type of a software token profile.
Edit any conditional statements containing the TokenType tag to reflect the new
mapping. For example, if the token type was Android_1.x in 7.1, change it to
Android 1.x for 8.1.
3. If your template included custom CT-KIP URLs for the following device types,
remove the URLs and update the template to use the e-mail template tag
${MailComposer.CtkipUrl}:
Android (version 1.x)
iPhone (version 1.0, 1.2, and 1.3)
Nokia (version 1.x)
Browser Toolbar (version 1.3 and 1.4)
Windows Phone (version 1.x)
This tag automatically generates custom URLs and you do not need to add syntax
to generate them manually.
4. If you plan to distribute software tokens using dynamic seed provisioning
(CT-KIP), add the following text after each ${MailComposer.CtkipUrl}
tag to display the expiration date for the activation code:
#if( ${MailComposer.CtkipAuthCodeExpirationDate})
Activation Code Expires On:
${MailComposer.CtkipAuthCodeExpirationDate}
${MailComposer.NL} ${MailComposer.NL}
#end
If you configure the activation code to never expire, the expiration date does not
display in the e-mail notification.
5. If you plan to distribute software tokens using Compressed Token Format (CTF),
add the following text:
#if( ${MailComposer.TokenTypeCTF} )
Compressed Token Format String: ${MailComposer.CtfString}
${MailComposer.NL}
#end
6. In the template, replace every ${UCMRequest.RequestID} tag with
${UCMRequest.ConfirmNumber}.
7. Save the text file with the modified e-mail template.
8. Do the following:
a. In the Security Console, click Setup >Self-Service Settings.
b. Under Provisioning, click Workflow Policies.
c. Use the search fields to find the policy that you want to edit.
d. Select the policy that you want to edit and click Edit from the Context
menu.
e. Select the Software Token tab.
f. Under E-mail Notification Templates, in the Body field, replace the
content currently in the 8.1 template with the modified content in the text
file.
g. Click Save & Finish.
9. Repeat step 8 for every workflow policy that you want to update.
A: Migrated Data 125
A Migrated Data
This appendix describes the data that is migrated to RSA AuthenticationManager 8.1.
For a list of data that is not migrated, see Non-Migrated Data on page133.
Migrated Data
The following table describes the data that is migrated.
Data Type Included in Migration
Users All users
Account information and settings
associated with each user, such as the
identity source and security domain.
Users assigned group membership
Administrative role
SecurID tokens
Authentication settings
User Groups All user groups
User and user group memberships
Restricted access times
Restricted agents
User groups security domain
User groups identity source
Identity Attribute Definitions Attribute definitions and settings
Identity attribute categories and
mappings
Policies Settings associated with the following:
Password policies
Lockout policies
Self-service troubleshooting policies
Token policies
Offline authentication policies
The assigned default policies, and the
security domain associated with each
policy are migrated.
126 A: Migrated Data
Logs You can migrate 7.1 log data, including the
administrative audit, runtime audit, and
system logs. Trace logs are not migrated.
SecurID Tokens SecurID PIN management settings
Hardware and software tokens in any of
the following states:
Assigned or unassigned
Disabled or enabled
Expired
In Next Tokencode Mode
Requiring PIN change
Emergency access tokencode settings
Note: Certain self-service software token
data is not included in the migration. For
more information, see AppendixB,
Non-Migrated Data.
On-Demand Tokencodes Users who are enabled or disabled for
on-demand tokencodes
Tokencode delivery method settings
Software Token Device Types All software token device types,
including imported device types
Values for device attribute definitions
(device class or device ID; nickname)
Token Attribute Definitions All token attribute definitions and the
security domain associated with each
definition.
Authentication Agents All settings for restricted or unrestricted
agents, including:
Agent hostname and IP address
Agent IP address protection
Alternate IP addresses
Authentication agent attributes such as
agent type, agent access, and whether an
agent is enabled or disabled.
Trusted realms settings are also migrated.
If an agent is enabled for trusted realm
authentication, the option selected to allow
all trusted users or only trusted users in
trusted users groups access the agent is
migrated.
Reports All reports and scheduled report jobs
Report settings, such as:
Security domain with administrators
who have the scope to manage the report
Basic information about the report such
as the report name, the scope of the
administrator who can run the report,
and the template used for the report
Report output columns
Report input parameter values
Completed reports are not migrated.
RSA RADIUS The following local and remote
RSA RADIUS data:
RADIUS client data, including the client
association with an agent.
RADIUS profiles associated with users,
user aliases, trusted users, and agents.
Custom and standard RADIUS user
attribute definitions, including the
attributes that are mapped to identity
sources, and the attributes assigned to
users and trusted users.
Extensible Authentication Protocol
Protected One-Time Password
(EAP-POTP) settings.
RADIUS dictionary files are only migrated
from a local RADIUS server.
Trusted Realms RSA AuthenticationManager 7.1
trusted realm settings, including the
authentication status, the security
domain where trusted users are created,
the trusted name identifier, and the
trusted realm status.
Trusted user settings, including the
security domain where a user is
managed, the trusted realm name, the
default shell assigned to a user, the
trusted group membership, and the
trusted user associated with a RADIUS
profile and RADIUS user attributes.
Trusted user group settings, including
the security domain where a user group
is managed and the members of trusted
user groups.
Whether trusted users in trusted groups
or all trusted users are granted access to
an agent.
Restricted access times for trusted user
groups.
Realm certificate
Settings associated with a legacy
RSA AuthenticationManager 6.1 realm,
including the server name, network IP
address, and the security domain where
trusted users are created.
Version 7.1 Realms If you have a 7.1 deployment with multiple
realms, during migration, the realms are
converted to security domains. In an 8.1
deployment, each deployment represents
one realm.
The following data is migrated from each
realm:
Users and user groups
Identity sources associated with the
realm
Tokens associated with users
Security domains
Authentication agents
Scheduled report jobs
For more information see, Migration of
Multiple Realms from Version 7.1 on
page19.
Security Domains Security domain hierarchy
All settings associated with a security
domain
Administrative Roles Custom administrative roles
Predefined administrative roles,
including predefined roles that were
edited.
Operations Console administrator and
the Super Admin
The 7.1 Super Admin and Operations
Console administrator accounts replace
the Super Admin and Operations
Console administrator accounts that are
created during the version 8.1 Quick
Setup.
Instances The following configuration settings from
the primary instance:
Caching
Mail Server (SMTP)
Logging levels for Administrative Audit,
Runtime Audit, and System logs
Console Display Options Security Console display options
Identity Sources Settings associated with external and
internal identity sources
Identity source SSL certificates
Scheduled cleanup jobs
Note: The configuration to external
identity sources is migrated to version8.1.
After migration, the 8.1 deployment has
read-only access to these identity sources.
For more information, see the chapter
Integrating LDAP Directories in the
Administrators Guide.
Security Console Authentication Methods Authentication method settings for
accessing the Security Console, such as the
authentication method, options for
non-unique user IDs, and non-native
authentication methods.
Password Dictionary The password dictionary file
Authentication Manager Settings Agent auto-registration
Configuration settings
CT-KIP configuration
EAP-POTP settings
Domain Name mapping
Self-Service Settings Settings associated with self-service,
including:
Self-Service Console authentication
methods
Identity source configuration for
enrolling self-service users
Security domain configuration for
enrolling self-service users
Customized user profiles
Header text for the Self-Service Console
home page
User group membership configuration
for enrolling self-service users
E-mail notification settings
E-mail notification templates, except the
template for approved software token
requests
Workflow definitions
Token management settings for
hardware tokens, on-demand
tokencodes, emergency access
tokencodes, token file passwords,
emergency access tokencodes for
permanently lost or broken tokens,
emergency access tokencodes for
temporarily unavailable tokens, and
expiring token parameters
Settings for software token types that are
available for request are not migrated.
Administrative roles associated with
self-service and token provisioning
requests such as the Token Distributer
and the Request Approver role
Certificates The following certificates:
Identity source certificates
Realm certificates
CT-KIP certificates
Authentication Updates Migrated from a Version 7.1 Replica Instance
Advanced Migration migrates the authentication updates that are recorded on the
replica instances while the primary instance is unavailable. The following table
summarizes the changes that are migrated from the replica instances during an
Advanced Migration.
Data Type
Authentication Updates Included in
Advanced Migration
Authentication Agents New or updated agent record as a result of
agent auto-registration
Runtime Audit Logs Log messages related to authentication
activity
Administrative audit and system logs are
not migrated.
Authenticators PIN changes
History of previously used PINs
Token status changes as a result of
authentication, such as tokens in next
tokencode mode due to unsuccessful
authentication attempts
Date and time when a token or
on-demand tokencode was last used for
authentication
Users Used online or offline emergency access
codes
Fixed passcode changes such as a new
fixed passcode, or an update to the date
and time that a fixed passcode was used.
Password changes
Date and time a user or trusted user logs
in
Date and time of an EAP32 session
Locked status changes due to
unsuccessful logons
History of previously used passwords
and fixed passcodes.
B: Non-Migrated Data 133
B Non-Migrated Data
This appendix describes the data that is not migrated to
RSA AuthenticationManager 8.1.
Data That is Not Migrated
The following table describes the data that is not migrated and the relevant
post-migration tasks.
Data Type Not Included in Migration Post-Migration Tasks
SNMP Settings Network management (SNMP)
configuration settings, including SNMP
trap settings.
You must reconfigure SNMP settings
for each instance in version8.1.
Contact Lists
Authentication Manager contacts lists If you created manual Authentication
Manager contact lists in version 7.1,
and you want to use these lists in
version 8.1, you must recreate them.
For instructions, see the Security
Console Help topic Add a Manual
Contact List.
RSA RADIUS Server The configuration data for a 7.1 local or
remote RSA RADIUS server, including
the server certificate.
By default, version8.1 has a RADIUS
server on the primary instance and
replica instance. In the Operations
Console, you can manage the server files
or Extensible Authentication Protocol
(EAP) certificates.
To replace the 8.1 RADIUS server
certificate with the certificate that you
used in version 7.1, you must copy the
RADIUS server certificate from version
7.1 and use the 8.1 Operations Console to
replace the certificate.
To edit the server files, see the 8.1
Operations Console Help topic Edit
RADIUS Server Files.
To replace the RADIUS server
certificate, see the 8.1 Operations
Console Help topic Replace a
RADIUS Server Certificate.
RSA RADIUS
Configuration Files
RSA RADIUS configuration files (.conf,
.ini, .aut). By default, RADIUS is
configured in version8.1.
If you edited the RADIUS
configuration files in version7.1 and
the new 8.1 RADIUS server requires
these changes, you can manually edit
the configuration files.
134 B: Non-Migrated Data
Remote RADIUS
Dictionary Files
RADIUS dictionary files from a remote
RADIUS server.
You can manually add these files to
the RADIUS server on the 8.1
instance.
Trusted Root Certificates for
RADIUS Servers
Trusted root certificates for a RADIUS
server.
You must manually add trusted root
certificates to each RADIUS server
on an 8.1 instance.
Local RADIUS server
Authentication agent that is associated
with the 7.1 local RADIUS server.
An authentication agent that is associated
with the 8.1 RADIUS server is
automatically created when you setup
Authentication Manager.
N/A
Administrative Permissions
to Edit or View RADIUS
Settings
The permission granted to an
administrator who is not a Super Admin
to view or edit the following RADIUS
settings:
RADIUS profile priority
Whether to send RADIUS attributes to
the RADIUS server
Format of RADIUS attributes
In version8.1, you must be a Super
Admin to view or edit RADIUS settings.
Notify administrators who are
affected by this change that they can
no longer view and edit RADIUS
settings.
If an administrator requires the
ability to view and edit RADIUS
settings, assign the Super Admin role
to him or her.
Version 7.1 Realms In a 7.1 deployment with multiple
realms, the following data from each
realm:
Realm configuration settings
Realm preferences
Policies
Administrative roles
During migration, 7.1 realms are
converted to security domains.
To assign the policies and
administrative roles that were used to
manage realms in version 7.1, you
must recreate these policies and
administrative roles in version 8.1.
For more information about the
conversion, see Migration of
Multiple Realms from Version 7.1 on
page19.
Authenticator Image File The image file associated with the
following types of authenticators:
Hardware tokens
Software tokens
On-demand tokencode service
N/A
Version 8.1 includes new image files
for each type of authenticator.
Completed User Requests All 7.1 approved, distributed, cancelled,
and rejected user requests for self-service
enrollment, user group membership,
hardware tokens, software tokens,
on-demand tokencodes, and the
replacement of lost or expired tokens.
N/A
These requests are stored only in the
7.1 database.
E-mail Notification
Template for Software
Tokens
E-mail notification template for
approved software token requests
If you want to reuse the 7.1 e-mail
notification template for approved
software tokens, modify the 8.1
software token e-mail notification
template with content from the 7.1
template. For instructions, see
Configure the Approved Software
Token Notification Template After
Pending User Requests All pending user requests for self-service
enrollment, hardware tokens, software
tokens, and on-demand tokens.
N/A
Before migration, you must complete
pending user requests.
Software Token Types
Available for Request
Settings for software token device types
that are available for request
In version 8.1, software token device
types are associated with software
token profiles. After you create a
software token profile for the type of
software token you need, you must
make the software tokens available
for request through the Self-Service
Console, and configure the settings
associated with the software token.
For instructions, see the Security
Console Help topic Select Software
Tokens for Provisioning.
Session Handling Settings Session handling settings for a 7.1
instance
You must reconfigure session
handling settings in version8.1.
Completed Reports Output for completed reports.
You can save completed reports before
performing a migration.
136 B: Non-Migrated Data
Backup and Restore Settings The following backup and restore
settings:
Scheduled backups
Backup location
Maximum number of backups
You must reschedule backups in
version8.1. The maximum number
of backups are configured when
scheduling backups.
In version8.1, the backup location
settings are configured when
performing a backup, or restoring
from a backup.
Console Session Lifetime Not supported in RSA Authentication
Manager 8.1.
N/A
Trace Logs The trace logs associated with
version7.1
N/A
Configuration to Send Log
Messages to a Local or
Remote Syslog Server
Any configuration made to the 7.1
ims.properties file, located in
RSA_AM_HOME/utils/resources/, that
allows Authentication Manager to send
log messages to a local or remote Syslog
server.
You must configure the log data
destination of administrative audit,
runtime audit, and system log data.
Authentication Grades Not supported in RSA Authentication
Manager 8.1.
N/A
Log Archive J obs All log archive jobs. In version8.1, you can reschedule a
log archive job that was previously
scheduled in version8.1.
Internal System Batch J obs Batch jobs that are automatically
configured and submitted by the 7.1
system.
N/A
Version8.1 includes internal batch
jobs that are automatically
configured.
Alternative IP addresses Alternative IP addresses for a 7.1
instance
If you configured these settings in
version 7.1, you can configure them
in version 8.1.
Short Message Service
(SMS) Configuration
Settings for the Clickatell
Plug-In
Clickatell SMS plug-in settings If you used the Clickatell plug-in for
version 7.1, you must select HTTP as
the SMS plug-in and reconfigure
these settings in version 8.1.
Replica Instance Connection
Settings to External Identity
Sources
The connection settings that a 7.1 replica
instance has to an external identity
source
Edit the identity source to connect to
the replica instance.
Settings for the 7.1 Replica
Instance
The following system configuration
settings for the replica instance:
The Simple Mail Transfer Protocol
(SMTP) settings
Caching settings
The SMTP, and caching settings that
apply to the 7.1 primary instance are
migrated.
You can manually reapply these
settings for an 8.1 replica instance.
User account that allows
SQL access to the RSA
internal database
The read-only user account created to run
custom SQL queries against the internal
database.
Use the version 8.1 Manage
Readonly Database Users utility,
manage-readonly-dbusers, to
recreate the read-only user account
after migration.
For more information, see SQL
Access to the RSA Authentication
Manager Database in the RSA
Developer's Guide.
C: Retained and Imported Pre-Production Data 139
C Retained and Imported Pre-Production Data
This appendix describes the data that is preserved and imported during a migration
when you retain the system settings and deployment topology of a test environment
before it goes into production.
You are presented with the option to preserve data only when a migration package
from a 7.1 primary instance was previously migrated into version 8.1.
Retained Version 8.1 Data
The following 8.1 data is not overwritten at import when you retain the system
settings and deployment topology of your pre-production test environment.
Data Type Retained Settings
Agents Authentication agent contact list
RADIUS server agent
Authentication Scheduled log archival
Software device types
Software token profiles
Risk-based authentication (RBA) policies and
risk-based authentication message policies. If you
assign a custom RBA policy or a custom RBA
message policy to a security domain during the
pre-production test period, the next import overwrites
this setting and assigns the initial RBA policy and
RBA message policy to the security domain.
Self-Service Self-Service e-mail notification settings for user
account changes
Self-Service Console authentication settings
Enabled or disabled features
Authenticators available for request
Shipping address for user-requested tokens
Workflow policy
140 C: Retained and Imported Pre-Production Data
System Alternative instance IP addresses
Caching settings
Ports for legacy cross (trusted) realm
Advanced RADIUS settings such as replication, and
EAP-POTP settings
Simple Network Management Protocol (SNMP)
settings
Agent auto-registration, agent communication ports,
and domain name mapping for Windows agents
Token settings related to PIN requirements, deletion
of replacement tokens, and dynamic seed
provisioning
On-demand tokencode delivery
Password dictionary
Security question requirements and management
settings
Customized security questions in any supported
language
Critical system notification settings
Simple Mail Transfer Protocol (SMTP) settings
Logging settings
Security Console authentication methods
Security Console display options
Session handling and session lifetime settings
Setup Scheduled cleanup jobs
Administration Date and time settings
Log rotation settings
Network settings such as appliance network, hosts
file, and network tool settings
Secure Shell (SSH) settings
Deployment Application trust certificates
Console certificate
RADIUS server configuration
RADIUS dictionary files
Replica instance configuration
Virtual host and load balancing settings
Web tier configuration
Maintenance Backup and restore settings
Update and rollback settings and patch history
Data Type Retained Settings
C: Retained and Imported Pre-Production Data 141
Imported Data from Version 7.1
The following 8.1 data is overwritten at import when you retain the system settings
and deployment topology of your test environment.
Data Type Imported Settings
Agent Authentication agent settings
Security Console Preferences Set preferences for the Security Console
Administration Administrative roles
Security domains
Trusted realms
Authentication On-demand tokencode settings
Policies, except for risk based authentication (RBA)
policies and risk based authentication message
policies
Token attribute definitions
Tokens
Identity Identity attribute definitions
Users
User groups
RADIUS RADIUS attributes
RADIUS clients
RADIUS profiles
Reports Reports and scheduled report jobs
Deployment Configuration Identity source certificates
Identity sources
System Logs
D: Restoring a Hardware Appliance 143
D Restoring a Hardware Appliance
This appendix describes how to restore your appliance and return to your original
version7.1 deployment.
Consequences of Restoring a Hardware Appliance
Restoring the hardware appliance allows you to revert the migration and return the 7.1
deployment to a pre-migration state. You must use the backup image of the appliance
that you created during migration. If you did not create a backup of the hardware
appliance image, you cannot restore your hardware to version 7.1.
Consider the following consequences of rolling back a migration:
Data Loss. All data related to 8.1 administration or authentication activity is lost
after the restore. The 7.1 instances revert to a pre-migration state. If you want 8.1
administrative activity to be reflected in version 7.1, you must perform the
administrative tasks in version 7.1.
Administrative Downtime. You cannot administer the deployment until services
are restarted on the restored 7.1 primary instance.
Replication. If the replica instances are available for more than seven days while
the primary instance is offline due to migration, the replica instances cannot
synchronize with the 7.1 primary instance during a restore. If this occurs, reattach
the replica instances. During reattachment, data that accumulated on the replica
instances and did not replicate to the 7.1 primary instance is lost.
If the replica instances can synchronize with the primary instance once you restore
and start services on the 7.1 deployment, you may see extra activity occurring
between the primary instance and replica instances on the network.
Reestablish Trusted Realm Relationships. Trusted realm relationships must be
reestablished.
144 D: Restoring a Hardware Appliance
Rolling Back to an RSA Authentication Manager 7.1 Deployment
Use the following procedure to roll back a migration and restore the appliance to its
pre-migration state.
Administrative and authentication data stored on the 8.1 primary instance cannot be
recovered for use in version7.1.
Before You Begin
If you experiencing an issue during migration, consult the troubleshooting appendix to
verify that it cannot resolved. See AppendixF, Troubleshooting Migration.
Procedure
1. Restore the primary appliance with the backup image file of the version 7.1
primary. For more information, see Restore an Image on the Hardware Appliance
on page144.
2. Restore each replica appliance with the its backup image file. For more
information, see Restore an Image on the Hardware Appliance on page144.
3. If your deployment includes trusted realms, you must reestablish trust
relationships to ensure that users from trusted realms can authenticate. For more
information, see Rolling Back Trusted Realm Relationships on page145.
4. If you performed an Advanced Migration (Scenario 3), you must use the
Migration Export Utility to roll back this scenario. For instructions, see Roll Back
an Advanced Migration Using a Command Line on page147.
Restore an Image on the Hardware Appliance
In the event that the Authentication Manager 8.1 installation fails, you can restore
Authentication Manager 7.1 to the appliance. RSA recommends downloading and
using PING to back up and restore the hardware appliance..
Before You Begin
Make sure that you know the location of the backup image. Attach the external
hard drive containing the backup image, if necessary.
Attach a keyboard and monitor to the appliance. For more information, see the
Procedure
Rolling Back Trusted Realm Relationships
If your deployment includes trusted realms, you must reestablish trusted realm
relationships with version 7.1 and 8.1 realms. Because you reused the 7.1 hostname
and IP address in version8.1, you do not need to reestablish trusted realm
relationships with version 6.1.
This process allows you to reestablish the connection between realms without
recreating trusted users and trusted user groups.
Use the following procedure to reestablish a trust between the reverted version 7.1
deployment and a version 7.1 realm.
Before You Begin
Procedure
1. You and the trusted realm administrator must generate a trust package and
securely exchange trust packages. For instructions, see the 7.1 Security Console
Help topic Generate a Trust Package for Reimport.
2. You and the trusted realm administrator must reimport the trust package. As part
of reimport, you and the trusted realm administrator must communicate to verify
confirmation codes. For instructions, see the 7.1 Security Console Help topic
Reimport a Trust Package.
3. Instruct the 7.1 trusted realm administrator to test communication with the trusted
realm that is associated with your deployment. If the test is unsuccessful, advise
the 7.1 trusted realm administrator to restart Authentication Manager services.
For instructions on testing communication from a version 7.1 trusted realm, see
the 7.1 Security Console Help topic Test a Trusted Realm.
For instructions on restarting services, see the RSA Authentication Manager 7.1
product documentation.
Use the following procedure to reestablish a trusted between the reverted version 7.1
deployment and a version 8.1 realm.
Before You Begin
Procedure
1. Instruct the 8.1 trusted realm administrator to generate a trust package and
securely send this trust package to you. To generate the trust package, the 8.1
trusted realm administrator must do the following:
Manage Existing.
b. Under Trusted Realm Name, click the trusted realm that you need to repair.
(TrustPackage.xml).
2. On version 7.1, import the 8.1 trust package and record the Current Realm
Confirmation Code during this process. For instructions, see the Security
Console Help topic Reimport a Trust Package.
3. As part of the import process in step 2, verify the Trusted Realm Confirmation
Code. To do this, instruct the 8.1 trusted realm administrator to locate the
confirmation code with the following steps:
Manage Existing.
b. Under Trusted Realm Name, click the trusted realm that needs a repair.
c. From the Context menu, click View, locate the confirmation code for Current
Realm Confirmation Code, and read the code to the 7.1 trusted realm
d. The version 8.1 Current Realm Confirmation Code and the 7.1 Trusted
Realm Confirmation Code must match. If the confirmation codes do not
match, you must generate and securely send the 7.1 trusted realm
administrator a new trust package.
4. On version 7.1, generate a trust package and securely send this package to the 8.1
trusted realm administrator. For instructions, see the Security Console Help topic
Generate a Trust Package for Reimport.
5. Instruct the 8.1 trusted realm administrator to do the following to import the 7.1
trust package and complete the repair:
Manage Existing.
repair.
e. Click Next, and contact the 7.1 realm administrator to verify the confirmation
code.
The 7.1 trusted realm administrator must share theCurrent Realm
Confirmation Code. The confirmation code must match the Trusted Realm
Confirmation Code that displays in version 8.1. If the confirmation code do
not match, the 7.1 realm administrator must generate and send a new trust
package.
f. Click Confirm and Next.
g. Click Save.
6. Instruct the 8.1 trusted realm administrator to test communication with the 7.1
trusted realm that is associated with your deployment. If the test is unsuccessful,
the 8.1 trusted realm administrator must restart Authentication Manager services.
For instructions on testing communication, the 8.1 trusted realm administrator can
see the 8.1 Security Console Help topic Test a Trusted Realm.
For instructions on restarting Authentication Manager services, the 8.1 trusted
realm administrator can see the RSA Authentication Manager 8.1 Administrators
Guide.
Roll Back an Advanced Migration Using a Command Line
Use the following procedure to roll back an Advanced Migration (Scenario 3) and
return all instances to a pre-migration state. This procedure uses the
RSA Authentication Manager 7.1 Migration Export Utility to resume replication and
undo the configuration that was implemented at export to capture authentication
updates while the primary instance was unavailable. You run this procedure only on
the 7.1 primary instance.
You must use this procedure for the RSA SecurIDAppliance3.0.
Before You Begin
Complete the rollback procedure. See Rolling Back to an RSA Authentication
Manager 7.1 Deployment on page144.
On the RSA SecurID Appliance 3.0, make sure you can log on as root. You must
run the utility as the root user.
Procedure
1. On the 7.1 primary instance, run the Migration Export Utility. Do the following:
sudo su -
and press ENTER.
A screen that warns a previous export is detected displays.
f. Type 1 to continue, and press ENTER.
2. Enter the master password for the 7.1 deployment, and press ENTER.
A confirmation screen displays.
3. Type 1 to begin the rollback process, and press ENTER.
4. Wait until the rollback process completes.
Uninstall the Migration Export Utility
If you do not plan on running another export or a roll back operation on the 7.1
deployment, you can uninstall the RSA Authentication Manager 7.1 Migration Export
Utility.
Before You Begin
Make sure you can log on as root. You must run the utility as a root user.
Procedure
1. Using an SSH client, log on to the Appliance operating system with the User ID
emcsrv, and the operating system password created during Quick Setup.
2. Change users to root. Type:
sudo su -
and press ENTER.
3. When you are prompted for a password, enter the operating system password
4. Type the following command to uninstall the utility, and press ENTER:
location/uninstall/uninstaller.sh -console
where location is the installation location of the utility.
E: Migrating a Standalone Primary Deployment 151
E Migrating a Standalone Primary Deployment
Performing a Basic Migration on a Standalone Primary Deployment
If you have a standalone primary deployment, you can only perform a Basic
Migration. When you export data from the primary instance, services are stopped. The
deployment experiences administrative and authentication downtime until you install
version8.1 and deploy the appliance as an 8.1 primary instance.
Note: You cannot test the migration process in a standalone primary deployment
unless you have access to another appliance that can be used for testing.
Before You Begin
Procedure
1. Export data from the version 7.1 primary instance. For instructions, see Export
Data on page152.
2. Back up the 7.1 primary appliance. You must create a backup image of the
hardware appliance, in case you need to restore RSA Authentication Manager 7.1.
RSA recommends using PING. For more information, see Create a Backup Image
of an Existing Hardware Appliance on page154.
3. Install RSA Authentication Manager 8.1. For instructions, see Install RSA
4. Deploy the hardware appliance and perform Quick Setup to configure the version
8.1 appliance as a primary instance.
hostname and IP address that was previously used for the instance in version 7.1.
For instructions, see the chapter Deploying a Primary Appliance in the RSA
Authentication Manager 8.1 Setup and Configuration Guide.
152 E: Migrating a Standalone Primary Deployment
Export Data
Before You Begin
overall procedure. See Performing a Basic Migration on a Standalone Primary
Deployment on page151.
Procedure
sudo su -
and press ENTER.
ENTER.
and press ENTER.
import operation.
or ~.
Manager 8.1.
ENTER.
export tasks while it generates the migration package. If you have replica
instances on version7.1, replication stops but the replica instances continue to
authenticate users while the primary instance is unavailable.
Next Steps
this option.
When the 8.1 primary is installed, you can copy to the following location
Quick Setup.
Back up the primary appliance. See Create a Backup Image of an Existing
Create a Backup Image of an Existing Hardware Appliance
Before installing version8.1 on an appliance, you must create a backup image of the
RSA SecurID Appliance 3.0. RSA recommends that you use PING to perform the
back up.
Before You Begin
Take note of the appliance hostname, IP address and the default gateway. You
must run Quick Setup to reconfigure the hostname, IP address and the default
gateway after the version 8.1 installation completes.
USB drive.
Procedure
Next Steps
Install RSA Authentication Manager 8.1. See Install RSA Authentication
Manager 8.1 on the RSA SecurID Appliance 3.0 on page155.
Appliance 3.0
Before You Begin
an Existing Hardware Appliance on page154
Procedure
sudo reboot
press ENTER.
ENTER.
Next Steps
8.1 appliance as a primary instance. For instructions, see the RSA Authentication
Import the migration package into the primary instance. For instructions, see
Import Data to RSA Authentication Manager 8.1 on page156.
Manager 8.1.
All version 7.1 administrative accounts are migrated. The 7.1 Super Admin and
Operations Console administrator accounts replace the Super Admin and Operations
Console administrator accounts that are created during the version8.1 Quick Setup.
Before You Begin
locations:
Your local machine
Quick Setup.
Procedure
instance.
local machine.
Password field.
5. Click Next.
following:
your local machine.
d. Click Next.
version8.1.
package.
package.
b. Click Next.
10. Click Next.
12. Click Done.
Next Steps
page162.
Perform the post-migration tasks. See Chapter 7, Post-Migration Tasks.
F: Troubleshooting Migration 161
F Troubleshooting Migration
This chapter provides guidance for troubleshooting migration problems.
Migration Export Utility Logs
If the export is unsuccessful, you can use logs files to diagnose the problem. The log
files are located in a log directory where the RSA Authentication Manager 7.1
Migration Export Utility is installed. If you cannot resolve an issue or run a successful
export, contact RSA Customer Support.
Resolve Import Errors
If importing a migration package to RSA Authentication Manager 8.1 is unsuccessful
or you need to resolve an import error, use the following high-level steps to
troubleshoot the issue.
For more information about the migration report, see Migration Report on page163.
Procedure
1. Identify why the import was unsuccessful. Do one of the following:
If you can view the Migration Report from the import status page or from the
migration summary page in the Operations Console, click Download
Migration Report and review the report to identify the errors.
If you can no longer access the Migration Report, in the Operations Console,
go to Administration >Download Troubleshooting Files, and download the
Authentication Manager Log Files. Review the log files to identify the errors.
For instructions, see Download Troubleshooting Files on page164.
If you cannot download support files because the RSA Runtime Server is
stopped and you cannot access the Download Troubleshooting Files page in
the Operations Console, see Access the Migration Report When the RSA
Runtime Server is Stopped on page166.
2. If you installed version8.1 on the original 7.1 primary instance, restore the
hardware appliance and return to this procedure. For instructions, see Restore an
Image on the Hardware Appliance on page144.
162 F: Troubleshooting Migration
3. If you have not yet installed version8.1 on the original primary instance, you can
do one of the following to resolve an import issue:
If you experienced an issue while importing data from the 7.1 primary
instance during a Basic Migration, manually restart services on the 7.1
primary instance to access the instance. For instructions, see the version7.1
product documentation.
If you experienced an error while importing data from the 7.1 primary
instance during an Advanced Migration, you must complete a rollback and
return to this procedure. For instructions, see Roll Back an Advanced
Migration Using a Command Line on page147.
4. If you experienced an error while importing a replica migration package, you must
restore the replica appliance. For instructions, see Restore an Image on the
5. Resolve the issues that affected import.
6. Generate a new migration package. For instructions, see the export instructions
that apply to your scenario.
7. Import the migration package to version8.1, and continue with your migration
scenario.
Next Steps
If you resolved the import errors, continue with the migration process. See the
instructions that apply to your scenario.
If you cannot resolve an issue, contact RSA Customer Support.
Migration Results
After a successful migration, the Operations Console lists the type of data and the total
number of data that was exported from version7.1 and imported into version8.1. You
might notice some discrepancies between data you see in the Operations Console and
the Security Console. The following applies when importing data from the 7.1 primary
instance:
The Security Console lists two more users than the number of imported internal
database users. In version8.1, two system users are automatically configured.
The Security Console lists an additional agent that is not recorded in the summary
after import. By default, version 8.1 is configured with an agent that is associated
with the RADIUS server. Although version7.1 is also configured with an
RADIUS agent, this agent is not migrated.
The Security Console displays one more identity attribute than the number of
migrated identity attributes. In version 8.1, an identity attribute definition is
configured in Authentication Manager by default.
If you experience an error or want to see more details about the migration, see
Migration Report on page163.
Migration Report
After an import, you can view and download a migration report
(migrationReport.log) from the Operations Console. If you navigate away from the
Operations Console, the migration report is only available with the Authentication
Manager log files.
When you download troubleshooting files, a .zip file is produced with Authentication
Manager log files. The .zip file contains the migration logs in the following location:
Authentication Manager Logs/server/logs/
In this location, you find a migration folder with a timestamp that contains logs for
your migration. If you imported data and retained the system settings and deployment
topology of the pre-production test environment, refresh is included in the folder
name.
The following table describes the contents of the report for each migration status.
For instructions on downloading the Authentication Manager log files that contains
the migration log files and the report, see Download Troubleshooting Files on
page164.
Migration Status Report Contents
Completed The same information that displays on the migration
summary page of the Operations Console.
Completed with Errors The data and database tables that are migrated. The
number of migrated data objects, errors, and the
migrated status of each data table also displays.
When migrating authentication updates from the 7.1
replica instance, the report also lists the records that
were discarded during import.
Unsuccessful Migration errors.
Download Troubleshooting Files
You can use the Operations Console to download logs and reports to use for
troubleshooting. Since these log files are not included in the product backup, you can
archive them by periodically downloading them. You can also download
troubleshooting files to access migration log files, including the migration report.
The log files are bundled into a .zip file for downloading. RSA Customer Support may
ask to see the .zip file for troubleshooting. This .zip file contains sensitive information
about hosts file, IP address, database schemas, and so on. The .zip file is
password-protected. Use Winzip version 9 and above to view the contents of the .zip
archive file.
Note: If you do not want to share a log containing sensitive information, delete it
before making the .zip archive file available to RSA Customer Support. Do not share
the .zip archive file with non-RSA personnel.
Before You Begin
You must be a Super Admin. However, if the RSA Runtime Server is down, you can
access this page using Operations Console credentials.
Procedure
1. In the Operations Console, click Administration > Download Troubleshooting
Files.
2. If prompted, enter your Super Admin credentials, and click OK.
3. Select the logs to download. Different options may display depending on whether
the instance is a primary or replica. The following table shows all available
options.
Option Description
Product Information Files that detail the configuration of
Authentication Manager, such as information
related to licensing, the version of Authentication
Manager and the operating system, configured
identity sources, and more.
Note: If the internal database or the RSA Runtime Server is down, only a subset
of files from the Product Information option are downloaded., and the System Log
Report option is unavailable on the primary instance.
4. In the Create Password field, enter a valid password.
5. Confirm the password.
Carefully note the password. You need this password to view the contents of the
.zip archive file. If you share the .zip archive file with RSA Customer Support,
you will have to provide this password.
6. Click Generate and Download Zip File.
Progress is displayed in the Progress Monitor page. This may take a few minutes
to complete.
7. In the Progress Monitor page, click Download Zip File.
In the location Authentication Manager Logs/server/logs/, a migration folder
with a timestamp contains logs for the migration. The folder name may refer to the
7.1 instance that was migrated or the migration scenario. If you retained settings
from pre-production, the term refresh is also included in the folder name.
Authentication Manager Log
Files
Logs that detail deployment activity such as
administrative operations and user actions. Log
files include:
Authentication Manager instance log
Quick Setup log
Operating system files
Replication log files
Migration log files
System Log Report (primary
instance only)
A report that displays deployment activity,
administrative operations, and the results of any
activity in a Comma Separated Value (CSV) file.
Option Description
Access the Migration Report When the RSA Runtime Server is
Stopped
Use this procedure to access the migration report when you cannot access the report
from the Operations Console because the RSA Runtime Server is stopped. You can
use an Secure Copy Protocol (SCP) to copy the report from the RSA Authentication
Manager 8.1 server to your local machine.
Before You Begin
Make sure that Secure Shell (SSH) is enabled on the RSA Authentication Manager 8.1
primary instance. For instructions, see the Operations Console Help topic Enable
Secure Shell on the Appliance.
Procedure
1. Log on to the SCP client as rsaadmin, and enter the operating system password.
2. Copy the migration report from the following location on the 8.1 server to your
local machine:
/opt/rsa/am/server/logs/migration_type-timestamp
where:
type is either the 7.1 instance that was migrated or the migration scenario if
you retained settings from the pre-production test environment. If you
retained settings from pre-production, the term refresh is also included in the
folder name.
timestamp is the date and time that the import completed. The timestamp
displays in the following format: YYYY-MM-DD-HHMM.
G: Summary of Migration Scenarios 167
G Summary of Migration Scenarios
Migration Scenarios
The following table summarizes each migration scenario.
Scenarios
Exported
Instances
Data
Loss
Authentication
Downtime
Description
Scenario 1:
Basic
Migration
with the
Replica
Instances
Online
Primary
Instance
Only
Yes No No need to a generate new configuration file for
agents.
Agents service authentication requests at all times.
The 7.1 replica instances authenticate users.
Data is not migrated from the 7.1 replica instances.
After migration, trusted realm relationships must be
reestablished.
You can administer the deployment once the 8.1
primary instance is available.
Scenario 2:
Basic
Migration
With All
Instances
Offline
Primary
Instance
Only
No Yes No need to generate a new configuration file for
agents.
The 7.1 deployment does not authenticate users
while data from the primary instance is migrated.
Authentication is down until the 8.1 primary
instance uses the same hostname and IP address as
the 7.1 primary instance.
reestablished.
Scenario 3:
Advanced
Migration
Primary
Instance
and
Replica
Instances
No No No need to generate a new configuration file for
agents.
The 7.1 replica instances authenticate users.
You can export authentication updates from the 7.1
replica instances.
Authentication agents service authentication
requests at all times.
reestablished.
Glossary 169
Glossary
Active Directory
The directory service that is included with Microsoft Windows Server 2003 SP2,
Microsoft Windows Server 2008, and Microsoft Windows Server 2008 R2.
Active Directory forest
A federation of identity servers for Windows Server environments. All identity servers
share a common schema, configuration, and Global Catalog.
administrative role
A collection of permissions and the scope within which those permissions apply.
administrator
Any user with one or more administrative roles that grant administrative permission to
manage the system.
agent host
The machine on which an agent is installed.
appliance
The hardware or guest virtual machine running RSA Authentication Manager. The
appliance can be set up as a primary instance or a replica instance.
approver
A Request Approver or an administrator with approver permissions.
assurance level
For risk-based authentication, the system categorizes each authentication attempt into
an assurance level that is based on the users profile, device, and authentication
history. If the authentication attempt meets the minimum assurance level that is
required by the RBA policy, the user gains access to the RBA-protected resource.
Otherwise, the user must provide identity confirmation to access the RBA-protected
resource.
attribute
A characteristic that defines the state, appearance, value, or setting of something. In
Authentication Manager, attributes are values associated with users and user groups.
For example, each user group has three standard attributes called Name, Identity
Source, and Security Domain.
attribute mapping
The process of relating a user or user group attribute, such as User ID or Last Name, to
one or more identity sources linked to the system. No attribute mapping is required in
a deployment where the internal database is the primary identity source.
audit information
Data found in the audit log representing a history of system events or activity
including changes to policy or configuration, authentications, authorizations, and so
on.
170 Glossary
audit log
A system-generated file that is a record of system events or activity. The system
includes four such files, called the Trace, Administrative, Runtime Audit, and System
logs.
authentication
The process of reliably determining the identity of a user or process.
authentication agent
A software application installed on a device, such as a domain server, web server, or
desktop computer, that enables authentication communication with Authentication
Manager on the network server. See agent host.
authentication method
The type of procedure required for obtaining authentication, such as a one-step
procedure, a multiple-option procedure (user name and password), or a chained
procedure.
authentication protocol
The convention used to transfer the credentials of a user during authentication, for
example, HTTP-BASIC/DIGEST, NTLM, Kerberos, and SPNEGO.
authentication server
A component made up of services that handle authentication requests, database
operations, and connections to the Security Console.
authenticator
A device used to verify a user's identity to Authentication Manager. This can be a
hardware token (for example, a key fob) or a software token.
authorization
The process of determining if a user is allowed to perform an operation on a resource.
backup
A file that contains a copy of your primary instance data. You can use the backup file
to restore the primary instance in a disaster recovery situation. An RSA
Authentication Manager 8.1 backup file includes: the internal database,
appliance-only data and configuration, keys and passwords used to access internal
services, and internal database log files. It does not include all the appliance and
operating system log files.
certificate
An asymmetric public key that corresponds with a private key. It is either self-signed
or signed with the private key of another certificate.
certificate DN
The distinguished name of the certificate issued to the user for authentication.
command line utility (CLU)
A utility that provides a command line user interface.
Glossary 171
core attributes
The fixed set of attributes commonly used by all RSA products to create a user. These
attributes are always part of the primary user record, whether the deployment is in an
LDAP or RDBMS environment. You cannot exclude core attributes from a view, but
they are available for delegation.
Cryptographic Token-Key Initialization Protocol (CT-KIP)
A client-server protocol for the secure initialization and configuration of software
tokens. The protocol requires neither private-key capabilities in the tokens, nor an
established public-key infrastructure. Successful execution of the protocol results in
the generation of the same shared secret on both the server as well as the token.
custom attributes
An attribute you create in Authentication Manager and map to a field in an LDAP
directory. For example, you could create a custom attribute for a users department.
data store
A data source, such as a relational database (Oracle or DB2) or directory server
(Microsoft Active Directory or Oracle Directory Server). Each type of data source
manages and accesses data differently.
delegated administration
A scheme for defining the scope and responsibilities of a set of administrators. It
permits administrators to delegate a portion of their responsibilities to another
administrator.
delivery address
The e-mail address or the mobile phone number where the on-demand tokencodes will
be delivered.
deployment
An installation of Authentication Manager that consists of a primary instance and,
optionally, one or more replica instances.
demilitarized zone
The area of a network configured between two network firewalls.
device history
For risk-based authentication, the system maintains a device history for each user. It
includes the devices that were used to gain access to protected resources.
device registration
For risk-based authentication, the process of saving an authentication device to the
users device history.
distribution file password
A password used to protect the distribution file when the distribution file is sent by
e-mail to the user.
distributor
A Token Distributor or an administrator with distributor permissions.
DMZ
See demilitarized zone.
172 Glossary
dynamic seed provisioning
The automation of all the steps required to provide a token file to a device that hosts a
software token, such as a web browser, using the Cryptographic Token-Key
Initialization Protocol (CT-KIP).
e-mail notifications
Contain status information about requests for user enrollment, tokens, and user group
membership that is sent to users who initiated the request. For token requests, e-mail
notifications also contain information about how to download and activate tokens.
Request Approvers and Token Distributors receive e-mail notifications about requests
that require their action. See e-mail templates.
e-mail templates
Templates that administrators can use to customize e-mail notifications about user
requests for user enrollment, tokens, user group membership, or the on-demand
tokencode service. See e-mail notifications.
excluded words dictionary
A dictionary containing a record of words that users cannot use as passwords. It
prevents users from using common, easily guessed words as passwords.
fixed passcode
Similar to a password that users can enter to gain access in place of a PIN and
tokencode. The format for fixed passcodes is defined in the token policy assigned to a
security domain. An administrator creates a fixed passcode in a users authentication
settings page. Fixed passcodes can be alphanumeric and contain special characters,
depending on the token policy.
Global Catalog
A read-only, replicated repository of a subset of the attributes of all entries in an
Active Directory forest.
Global Catalog identity source
An identity source that is associated with an Active Directory Global Catalog. This
identity source is used for finding and authenticating users, and resolving group
membership within the forest.
identity attribute
Customer-defined attributes that are mapped to an existing customer-defined schema
element. They are always stored in the same physical repository as the users or user
groups core attribute data. You can search, query, and report on these attributes. Each
identity attribute definition must map to an existing attribute in an LDAP directory or
RDBMS.
identity confirmation method
For risk-based authentication, an authentication method that can be used to confirm a
users identity.
identity source
A data store containing user and user group data. The data store can be the internal
database or an external directory server, such as Microsoft Active Directory.
Glossary 173
instance
An installation of RSA Authentication Manager 8.1 that can be set up as a primary
instance or a replica instance. An instance also includes a RADIUS server.
internal database
The Authentication Manager proprietary data source.
keystore
The facility for storing keys and certificates.
load balancer
A deployment component used to distribute authentication requests across multiple
computers to achieve optimal resource utilization. The load balancer is usually
dedicated hardware or software that can provide redundancy, increase reliability, and
minimize response time. See Round Robin DNS.
lower-level security domain
In a security domain hierarchy, a security domain that is nested within another security
domain.
minimum assurance level
See assurance level.
node secret
A long-lived symmetric key that the agent uses to encrypt the data in the
authentication request. The node secret is known only to Authentication Manager and
the agent.
on-demand tokencode
Tokencodes delivered by SMS or SMTP. These tokencodes require the user to enter a
PIN to achieve two-factor authentication. On-demand tokencodes are user-initiated, as
Authentication Manager only sends a tokencode to the user when it receives a user
request. An on-demand tokencode can be used only once. The administrator
configures the lifetime of an on-demand tokencode. See on-demand tokencode
service.
on-demand tokencode service
A service that allows enabled users to receive tokencodes by text message or e-mail,
instead of by tokens. You configure the on-demand tokencode service and enable
users on the Security Console.
Operations Console
An administrative user interface through which the user configures and sets up
Authentication Manager, for example, adding and managing identity sources, adding
and managing instances, and disaster recovery.
permissions
Specifies which tasks an administrator is allowed to perform.
preferred instance
The Authentication Manager instance that the risk-based authentication service in the
web tier communicates with first. Also, the instance that provides updates to the web
tier. Any instance can be the preferred instance. For example, you can configure a
replica instance as the preferred instance.
174 Glossary
primary instance
The installed deployment where authentication and all administrative actions are
performed.
promotion, for disaster recovery
The process of configuring a replica instance to become the new primary instance.
During promotion, the original primary instance is detached from the deployment. All
configuration data referring to the original primary instance is removed from the new
primary instance.
promotion, for maintenance
The process of configuring a replica instance to become the new primary instance
when all instances are healthy. During promotion, a replica instance is configured as a
primary instance. The original primary instance is demoted and configured as a replica
instance.
provisioning
See token provisioning.
provisioning data
The provisioning server-defined data. This is a container of information necessary to
complete the provisioning of a token device.
RADIUS
See Remote Authentication Dial-In User Service.
RBA
See risk-based authentication.
RBA integration script
A script that redirects the user from the default logon page of a web-based application
to a customized logon page. This allows Authentication Manager to authenticate the
user with risk-based authentication. To generate an integration script, you must have
an integration script template.
realm
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. Each deployment has only one realm.
Remote Authentication Dial-In User Service (RADIUS)
A protocol for administering and securing remote access to a network. A RADIUS
server receives remote user access requests from RADIUS clients, for example, a
VPN.
replica instance
The installed deployment where authentication occurs and at which an administrator
can view the administrative data. No administrative actions are performed on the
replica instance.
replica package
A file that contains configuration data that enables the replica appliance to connect to
the primary appliance. You must generate a replica package before you set up a replica
appliance.
Glossary 175
requests
Allows users to enroll, as well as request tokens, the on-demand tokencode service,
and user group membership.
Request Approver
A predefined administrative role that grants permission to approve requests from users
for user enrollment, tokens, or user group membership.
risk-based authentication (RBA)
An authentication method that analyzes the users profile, authentication history, and
authentication device before granting access to a protected resource.
risk engine
In Authentication Manager, the risk engine intelligently assesses the authentication
risk for each user. It accumulates knowledge about each users device and behavior
over time. When the user attempts to authenticate, the risk engine refers to its
collected data to evaluate the risk. The risk engine then assigns an assurance level,
such as high, medium, or low, to the users authentication attempt.
round robin DNS
An alternate method of load balancing that does not require dedicated software or
hardware. When the Domain Name System (DNS) server is configured and enabled
for round robin, the DNS server sends risk-based authentication (RBA) requests to the
web-tier servers. See Load Balancer.
scope
In a deployment, the security domain or domains within which a roles permissions
apply.
Secure Sockets Layer (SSL)
A protocol that uses cryptography to enable secure communication over the Internet.
SSL is widely supported by leading web browsers and web servers.
Security Console
An administrative user interface through which the user performs most of the
day-to-day administrative activities.
security domain
A container that defines an area of administrative management responsibility,
typically in terms of business units, departments, partners, and so on. Security
domains establish ownership and namespaces for objects (users, roles, permissions,
and so on) within the system. They are hierarchical.
security questions
A way of allowing users to authenticate without using their standard method. To use
this service, a user must answer a number of security questions. To authenticate using
this service, the user must correctly answer all or a subset of the original questions.
self-service
A component of Authentication Manager that allows the user to update user profiles,
change passwords for the Self-Service Console, configure life questions, clear devices
enabled for risk-based authentication, change e-mail addresses or phone numbers for
on-demand authentication, and manage on-demand authentication PINs. The user can
also request, maintain, and troubleshoot tokens.
176 Glossary
Self-Service Console
A user interface through which the user can update user profiles, change passwords
for the Self-Service Console, configure life questions, clear devices enabled for
risk-based authentication, change e-mail addresses or phone numbers for on-demand
authentication, and manage on-demand authentication PINs. Users can also request,
maintain, and troubleshoot tokens on the Self-Service Console.
session
An encounter between a user and a software application that contains data pertaining
to the users interaction with the application. A session begins when the user logs on
to the software application and ends when the user logs off of the software application.
shipping address
An address used by distributors to distribute hardware tokens.
silent collection
For risk-based authentication, a period during which the system silently collects data
about each users profile, authentication history, and authentication devices without
requiring identity confirmation during logon.
SSL
See Secure Sockets Layer.
Super Admin
An administrator with permissions to perform all administrative tasks in the Security
Console. A Super Admin:
Can link identity sources to system
Has full permissions within a deployment
Can assign administrative roles within a deployment
system event
System-generated information related to nonfunctional system events, such as server
startup and shutdown, failover events, and replication events.
System log
A persistable store for recording system events.
time-out
The amount of time (in seconds) that the users desktop can be inactive before
reauthentication is required.
token distributor
A predefined administrative role that grants permission to act upon requests from
users for tokens. Distributors record how they plan to deliver tokens to users and close
requests.
token provisioning
The automation of all the steps required to provide enrollment, user group
membership, RSA SecurID tokens, and the on-demand tokencode service to users.
See also self-service.
Glossary 177
top-level security domain
The top-level security domain is the first security domain in the security domain
hierarchy. The top-level security domain is unique in that it links to the identity source
or sources and manages the password, locking, and authentication policy for the entire
deployment.
Trace log
A persistable store for trace information.
trusted realm
A trusted realm is a realm that has a trust relationship with another realm. Users on a
trusted realm have permission to authenticate to another realm and access the
resources on that realm. Two or more realms can have a trust relationship. A trust
relationship can be either one-way or two-way.
trust package
An XML file that contains configuration information about the deployment.
UDP
See User Datagram Protocol.
User Datagram Protocol (UDP)
A protocol that allows programs on networked computers to communicate with one
another by sending short messages called datagrams.
User ID
A character string that the system uses to identify a user attempting to authenticate.
Typically a User ID is the users first initial followed by the last name. For example,
J ane Does User ID might be jdoe.
virtual host
Physical computer on which a virtual machine is installed. A virtual host helps
manage traffic between web-based applications, web-tier deployments, and the
associated primary instance and replica instances.
virtual hostname
The publicly-accessible hostname. End users use this virtual hostname to authenticate
through the web tier. The system also generates SSL information based on the virtual
hostname. The virtual hostname must be same as the load balancer hostname.
web tier
A web tier is a platform for installing and deploying the Self-Service Console,
Dynamic Seed Provisioning, and the risk-based authentication (RBA) service in the
DMZ. The web tier prevents end users from accessing your private network by
receiving and managing inbound internet traffic before it enters your private network.
workflow
The movement of information or tasks through a work or business process. A
workflow can consist of one or two approval steps and a distribution step for different
requests from users.
workflow participant
Either approvers or distributors. Approvers review, approve, or defer user requests.
Distributors determine the distribution method for token requests and record the
method for each request. See also workflow.
Index 179
Index
A
administrative downtime, 18
administrative roles
migrated data, 129
permissions, 121
advanced migration, 18, 81102
change hostname and IP of
primary, 94
create appliance backup image, 86
export data, primary, 88
export data, replica, 98
import data, 91, 100
install Authentication Manager, 87
scenario high-level steps, 84
alternative IP addresses
configuring, 46, 110
non-migrated, 136
API. See application programming
interface
application programming interface, 47
authentication agent
assign contact lists, 105, 111
create contact lists, 47
migrated data, 126, 131
migration, 17
Authentication Manager settings
migrated data, 130
authentication method
migrated data, 129
authenticator
image file, 134
migrated data, 131
B
backup
appliance image, 34, 54, 70, 86, 154
schedule, 43, 113
settings, non-migrated, 136
basic migration, all instances offline, 17,
18, 6580
primary, 78
export data, 72
import data, 75
basic migration, replica instances
online, 18, 4964
primary, 61
export data, 56
import data, 58
basic migration, standalone primary
deployment, 151159
export data, 152
import data, 156
batch jobs
internal, 136
C
caching settings
configure for replica, 43, 113
non-migrated, 137
certificates
application trust, 41, 107
console, 41, 107
migrated data, 130
trusted root, 44, 108
completed user requests, 135
contact lists
assigning, 105, 111
creating, 47
non-migrated, 133
critical system event notification
configure, 42, 112
D
data
migrated, 125131
non-migrated, 133137
display
console, 129
180 Index
E
e-mail notification templates
approved software token, 47, 115
modify, 46, 114
excluded words dictionary
migrated data, 129
export data
basic migration, all instances
offline, 72
online, 56
deployment, 152
testing migration, 36
export utility. See RSA Authentication
Manager 7.1 Migration Export Utility
H
hardware appliance
create appliance backup image, 34,
54, 70, 86
install Authentication Manager, 35,
54, 71, 87, 155
migration, 15
upgrade eligibility, 13
I
identity attribute
migrated data, 125
identity source
migrated data, 129
identity source connection
configure for replica, 107
replica, 136
import data
offline, 75
online, 58
deployment, 156
instance
migrated data, 129
L
license
ID, 9
serial number, 9
logs
configure logging settings, 42, 112
configure rotation settings, 43, 113
Migration Export Utility, 161
non-migrated, 136
schedule archive, 42, 113
M
migration
7.1 realms, 19, 120
administrative downtime, 18
administrative role permissions, 121
authentication agent, 17
offline, 17, 18, 6580
online, 18, 4964
deployment, 151159
create appliance backup image, 34,
54, 70, 86
data loss, 18
hardware appliance, 15
high-level steps, 11
imported pre-production data, 141
install Authentication Manager, 35,
54, 71, 87, 155
migrated data, 125131
migration report, 163
migration results, 162
non-migrated data, 133137
planning, 13, 14
pre-migration checklist, 25
pre-production, 3148, 51, 67, 84
remote RSA RADIUS dictionary
files, 122
required expertise for
administrators, 13
restore hardware appliance, 143
retained pre-production data, 139
140
RSA RADIUS clients, 17
selecting a scenario, 22
Index 181
Migration Export Utility
installation, 2830
logs, 161
uninstall, 148
migration package, 33
O
on-demand tokencodes
configure SMS, 46, 111
migrated data, 126
operating system access
configure, 43, 112
P
password dictionary, 129
pending user requests, 135
policies
migrated data, 125
post-migration tasks
when 8.1 database is completely
overwritten, 107
when 8.1 settings are retained, 103
pre-migration checklist, 25
pre-production, 16, 3148
advanced migration, 84
offline, 67
online, 51
imported data, 141
retained data, 139140
setup tasks, 41
product update locations
specify, 43, 113
R
realms, 19
configure after migration, 107
migrated data, 128
non-migrated, 134
replica instance
7.1 authentication updates, 131
reports
migrated data, 127
non-migrated, 135
SQL queries, 106, 116, 137
restore hardware appliance, 143
procedure, 144
reestablish trusted realms, 145147
roll back advanced migration, 147
RSA Authentication Manager 7.1
Migration Export Utility
installation, 2830
log files, 161
uninstall, 148
RSA RADIUS
adding trusted root certificate, 44,
108
administrative permissions, 134
authentication agent, 134
certificate, 133
clients, 17
configuration files, 108, 133
edit configuration files, 44
migrated data, 127
migration, 19
non-migrated, 133134
remote RADIUS dictionary files, 45,
109, 122, 134
replace server certificate, 44, 109
trusted root certificates, 134
update clients, 105, 108
S
Secure Shell
configure, 43, 112
Security Console
authentication methods, 129
security domains
migrated data, 129
security questions
configure, 43, 112
self-service
migrated data, 130
non-migrated, 135
Self-Service Console
configure security questions, 43, 112
session
handling, 42, 113, 135
lifetime, 42, 113
shipping address for tokens
configure, 47, 115
Short Message Service
configure for Clickatell
non-migrated, 136
Simple Mail Transfer Protocol
settings for replica, 43, 113, 137
Simple Network Management Protocol
configure, 42, 112
non-migrated, 133
SMS. See Short Message Service
182 Index
SMTP. See Simple Mail Transfer Protocol
SNMP. See Simple Network Management
Protocol
software tokens
create profile, 45, 110
determining device type, 47, 116
device type, 106, 126
e-mail notification template, 47, 115,
135
requests, 106, 114
selecting for Self-Service, 46, 114
types available for request, 135
SSH. See Secure Shell
system date and time
configure, 43, 113
T
export data, 36
import data, 38
tokens
attribute definitions, 126
migrated data, 126
shipping address, 47, 115
Trace log
non-migrated data, 136
troubleshooting
download troubleshooting files, 164
Migration Export Utility logs, 161
migration report, 163
migration results, 162
resolve import errors, 161
stopped RSA Runtime Server, 166
trusted realm relationships
migrated data, 128
post-migration, 116
rolling back, 145
U
user groups
migrated data, 125
users
V
version
viewing, 9
virtual host, 41, 107
W
web tier
install, 41, 107
H12985

h12280 Am8 Migration Guide 7.1 PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

h12280 Am8 Migration Guide 7.1 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

RSA

Authenti cati on Manager 7.1 to 8.1

Authentication Manager 8.1 Documentation........................................................... 7

Authentication Manager 7.1 and upgrade

Authentication Manager 8.1 Documentation

Das könnte Ihnen auch gefallen