RSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 8.x, 7.1, 6.1

The currently deployed version of Authentication Manager is out of support, and the number of upgrades required would require excessive effort.

• Authentication Manager 8.7 was end of lifed in May 2025 (May 2026 or May 2027, if you have Level 1 or Level 2 extended support).
• The oldest version of Authentication Manager still supported is 8.6. End of support is set for August 2026 if you have Level 2 extended support).
• Migrating from 6.1 or 7.1 requires an install of AM 8.1.1.15, which cannot be run in modern browsers and requires a legacy browser like Firefox 25.0, which is no longer available from Mozilla Firefox.
• Going from 8.5 to 8.6 requires the RSA Authentication Manager 8.6 Pre-Upgrade Check Tool utility to scan the RADIUS database for incompatibilities between the legacy Steel Belted RADIUS and the currently supported FreeRADIUS in use by Authentication Manager.
• Older hardware appliances cannot be upgraded beyond AM 8.7.
• Almost all agents that were compatible with Authentication Manager 8.2 and earlier are also end-of-lifed, as RSA now uses REST API almost exclusively.
• Each patch applied to each Authentication Manager appliance instance takes anywhere from 20 to 60 minutes to complete.

• Obtain the newest appliance image from https://my.rsa.com or from your cloud provider. Please refer to the appropriate RSA Authentication Manager Appliance Getting Started Guide for specifics).
• Download the newest supported patch for Authentication Manager as well as the matching web tier download, if used in your deployment.

Sometimes the simplest solution is to start over.  You can leave current current deployment intact while building a new system that will mirror the configuration in production.  When this system is online, you can configure the agents to authenticate to the new deployment, then dismantle the old one once the cutover is complete.

1. First deploy the new appliance that will become your new Primary.  Obtain the necessary appliance image from https://my.rsa.com or from your cloud provider. Please refer to the appropriate RSA Authentication Manager Appliance Getting Started Guide for specifics).

2.  Use the instructions from the appropriate Getting Started Guide, following the section titled "Set Up a Primary Instance."  

3. Configure your external identity source(s) 
   1. Logon to the Operations Console of your old Primary.  Navigate to Deployment Configuration > Identity Sources > Manage Existing.
   2. If your current configuration uses LDAPS, download and install the certificate from your domain controller onto the new Primary following these instructions on how to retrieve the LDAPS certificate and configure an external identity source to use LDAPS.
   3. Logon to the Operations Console of your new Primary.  Navigate to Deployment Configuration > Identity Sources > Add New.
   4. Copy and paste the configuration information from the old Primary to the new Primary.  You will need to retype the passwords for your service account.
   5. After testing the connection, proceed to the Mapping tab and continue to copy the configurations for items like user Base DN and User Group Base DN, etc. from your old Primary to the new one.  Click Save.
   6. Log onto the Security Console of the new Primary and link your identity sources to the system.  Navigate to Setup > Identity Sources > Link Identity Source to System.  Click the right-facing arrow to move them to the Linked column.
   7. Search for users and verify they show up the same in both the old and new Primary servers.

4. Export users and tokens from the old Primary to the new one

NOTE:  If your new Primary is on version 8.9, you must apply Patch 1 or later  to import users and tokens.  Apply the newest patch before proceeding.

1. 1. Recreate any Software Token profiles.
      1. On the old Primary, go to Authentication > Software Token Profiles > Manage Existing.
      2. For every profile name still in use, go to the new Primary under Authentication > Software Token Profiles > Add New and recreate each one exactly.  Profile names are case sensitive;   Device Type, Authentication Type, and Delivery Method must also match exactly.
   2. In the Security Console of the new Primary, go to Administration > Export/Import Tokens and Users > Download Encryption Key.
   3. In the Security Console of the old Primary , go to Administration > Export/Import Tokens and Users > Export Tokens and Users.
   4. For Encryption Key Location, browse to the encryption key you downloaded in step 4b.
   5. For Export Type, choose Users with Tokens.  Click Next.
   6. For Security Domain, choose SystemDomain and click the box to Include subdomains.  Select Export all users with tokens in domain.  Click Export.
   7. When completed, click on Download File.
   8. In the Security Console of the new Primary , go to Administration > Export/Import Tokens and Users > Import Tokens and Users.
   9. Click Choose File and select the package you downloaded in step 4g.
   10. On the Security Domain Selection page, select the target security domain for these users and tokens. You can only select one security domain.  Click Next.
   11. From the Identity Source Mapping page, select the identity source(s) on the target deployment where the system can find the associated user.  If you select internal database, the user is created in the internal database on the target deployment.  Click Next.
   12. On the Pre-Import Summary page, review the import operation details for accuracy.
   13. Click Import. You are directed to the Export/Import Status page. The import status is automatically refreshed.  When the import is complete, the users are in the security domain that you selected with their assigned tokens.
   14. Repeat steps 4c through 4g but this time choose Tokens Only.  This will allow you to import any unassigned tokens.

5. Define Administrative Roles and system administrators
   1. Logon to the Security Console of the old Primary and navigate to Administration > Administrative Roles > Manage Existing.
   2. Recreate any custom roles on the new Primary.
   3. For each role on the old Primary, find all users with that role assigned, and assign it to the same user on the new Primary.
   4. Under Administration > Manage OC Administrators, create the same OC administrator accounts on the new Primary to match those on the old Primary.

6. Build and attach replica(s) to the new Primary.
   1. From the Operations Console of the new Primary, navigate to Deployment Configuration > Instances > Generate Replica Package.
   2. Stage your new replica(s) by following the instructions in Step 1, but this time choose  Set Up a Replica Instance.
   3. Provide the replica package from step 5a when prompted.
   4. Apply the same patches to the replica(s) that you installed on the new Primary.
   5. Verify that REST API authentication is enabled on each replica, by logging on to its Security Console and navigating to Setup > System Settings > RSA SecurID Authentication API." Be sure to click Apply Settings.

7. Upgrade your Web Tiers.
   1. Download the web tier installer that matches the software patch on the new Primary.
   2. Log onto the Operations Console of the old Primary, and navigate to Deployment Configuration > Virtual Host and Load Balancing.
   3. Copy this configuration to the same page on the new Primary.
   4. Log onto the Operations Console of the old Primary, and navigate to Deployment Configuration > Web Tier Deployments > Manage Existing.
   5. Copy this configuration to the same page on the new Primary, and download the corresponding Web Tier packages.
   6. On each web tier, uninstall the existing version, then install the new package you downloaded in Step 7a.

8. Create agent records on the new Primary for all your existing agents
   1. MFA agents: 
      1. Create an MFA Agent record with the same exact name as used on the old Primary.
      2. Navigate to Access > Authentication Agents > Agent Credentials.  Make a note of the API Key on the new Primary.
      3. Download the RootCA.cer file from the Operations Console of the new Primary by navigating to Deployment Configuration > Certificates > Application Trust Certificates and downloading RootCA.cer.  Note that Linux agents will require this certificate to be converted to base64/x.509 format.
   2. RADIUS clients:
      1. Create RADIUS clients and their associated Authentication Agents.
      2. Create RADIUS profiles to match any that were created on the old Primary.
   3. UDP agents: 
      1. Create individual agent records for all UDP agents
      2. Generate a new sdconf.rec to install on the agents.

9. Recreate system settings on the new Primary to match the old Primary (this is NOT an exhaustive list)
   1. Identity > Identity Attribute Definitions
   2. Authentication > Policies
   3. Reporting > Reports > Manage Existing
   4. Reporting > Reports > Scheduled Report Jobs
   5. Setup > Administration > Security Domains
   6. Setup > System Settings and verify all settings (there are many)

10. Update your authentication agents to authenticate to the new appliances:
    1. MFA agents:  Update the configuration to point to the new appliance URLs and upload the new RootCA.cer file from step 8a item iii.
    2. RADIUS clients:  Update the configuration to point to the new appliances
    3. UDP agents:  Generate a new sdconf.rec and install on the agents.  Note you must delete or rename the existing files:
       1. sdconf.rec (the old one still points to the old Primary deployment)
       2. sdstatus.12 (or sdstatus.1, any filename containing "status" in the same directory as sdconf.rec)
       3. securid (this is the node secret from the old Primary deployment and must be cleared to connect to the new Primary deployment)
    4. PrimeKit:  You will need to run PQS again to build the necessary environment on the new Primary.  Refer to the RSA SecurID Access PrimeKit Quick Install Guide for more details.

11. Use the Real-Time Authentication Activity monitor on both the old Primary and the new Primary to ensure users are authenticating to the new appliances.

12. Once all agents are authenticating to the new Primary, the old Primary can be decommissioned.

13. If you would like the new Primary's fully qualified name and IP address to be the name and IP of the now decommissioned server, follow the steps documented to change the primary instance's IPv4 network settings.