David,

Thank you for the kind words! What a lovely way to start my day.

If you have questions or issues, please feel free to ask here or to open a case with support for additional assistance.

Now boldly go where no sane admin would go on a Friday afternoon.

@DavidWoods40975 (Customer)​ ,

Admitting the part about the sanity (or lack thereof) of the admins is the first step 😉

Caveat: In Authentication Manager 8.5 we used Steel Belted RADIUS and moved to FreeRADIUS with 8.6. Whether you use RADIUS or not, you must run the RADIUS Pre-Upgrade Check Tool on the primary (links to the RADIUS Pre-Upgrade Check Tool and readme). This creates the radius-pre-migration-check-report.html. The following warnings are safe to ignore but contact support if you see errors:

Feb 13, 2024 1:25:05 PM | Changing SBR attribute named state from string to octets

Feb 13, 2024 1:25:05 PM | Changing SBR attribute named EAP-Message from octets to octets concat

Q0:

At what version of Authentication Manager did your servers start? If they are still on 8.5, I'd think they are quite old. You can upgrade to a supported version and that is fine, but you may want to think about fully replacing them. By default, an upgraded VMware virtual appliance has 100 GB of disk space for storage and a 4 GB swap file. When you deploy a new Authentication Manager 8.9 VMware virtual appliance, the default size is 500 GB of disk space for storage and 4 GB for a swap file. You can deploy the 500 GB VMware appliance in a deployment with upgraded 100 GB VMware appliances. Make sure that you have sufficient disk space before restoring an Authentication Manager backup file from a new 500 GB appliance on a 100 GB appliance or promoting a 100 GB replica instance to replace a 500 GB primary instance.

Q1: Yes, you always upgrade the primary first then when done, upgrade your replicas one at a time. Plan on each server taking about 45 minutes to an hour to complete.

You will see in the Operations Console that replication may show as offline or out of sync. That is normal and expected. So much so that we have this handy article on how to manually reset the stuck flag in the database so you can then sync the servers. Then move on to 8.7 > 8.7 SP1 > 8.7 SP2 > 8.8 > 8.9 and finally 8.9 patch 2 (8.9 patch 3 should be out soon). Plan for about 30 to 60 minutes per server to complete..

Q2: If you are looking to promote a replica to primary, I'd consider doing that before you upgrade or after the upgrade is complete so you are not introducing more change than needed at once.

Q3: Customers do this process in one of two ways and either is perfectly valid (and goes back to admin sanity):

• Some prefer to lift their servers one level then test extensively before moving up again. I've seen customers wait months in this testing process.
• Other admins opt to upgrade as fast as possible to get a feature or security fix installed and would complete the upgrade of your three servers to 8.6 before lunch then install 8.7 in the afternoon, etc.

Both are acceptable, you just want to ensure the servers are up to the same version as soon as possible.

Q4: "It works" and "it is supported" are two different things. The RSA Authentication Agent 7.4.3 for Windows was end of lifed in June 2024. It will still work with Authentication Manager. The MFA Agent 2.5 for Microsoft Windows Installation and Administration Guide has steps on page 60 on how to migrate from Authentication Agent 7.4.x to MFA Agent 2.5. Also the MFA Agent has new GPO settings that are not included in Authentication Agent 7.4 or later. You must configure these required GPO settings to connect the MFA Agent to either the Authentication Manager or CAS.

For the agents,  be sure to enable the REST API via the Security Console on all instances well before 8.8. This ensures that TCP 5555 is listening for authentication traffic.

If you use Windows password integration on your agents, it does not work before 8.7 SP1, so hold off on installing the MFA agent until you are at Authentication Manager 8.8.

Follow the steps in the MFA Agent 2.5 for Microsoft Windows Installation and Administration Guide to import the trusted root certificate for Authentication Manager on all machines on which you plan to install the MFA agent. This just gets it ready to go when you cut over.

You can leave your current 7.4.3 agents in place until you prove the MFA 2.5 agent works, then start deleting the agent from Windows and the agent record from the Security Console.

I've thrown a lot of information at you. If you have additional questions, let us know here or feel free to open a support case to work more directly on completing your upgrade.