Question about RSA Authentication Manager Server Failover Process

[Samuel1]

This is probably pretty basic, but I wanted that the failovers from the Primary Authentication Manager Server to the Replica occur while the primary is down? I wanted to make sure there would not need to be any manual process I would need to kickoff from the Security or Operations console in case it goes down. I also wanted to confirm it the replica would revert as soon as it is able to confirm the primay is up again or if that process has any manual steps? I see there's a promotion operation, but that looks more like for a long term change of roles.

[EricaChalfin · Accepted solution]

@Samuel1,

I moved your question to the SecurID discussions page, where it will be seen by our tech support engineers, members of our Professional Services team, engineers and other customers who use Authentication Manager.

To answer your question, your Authentication Manager servers are in an active-active state where they all accept authentication requests at all times (except if you manually add an sdopts.rec, but that is for another time). It is not true failover where auth requests go only to one server and if it goes down, another server in your deployment automatically takes over.

We have two options to promote one of your replicas to be a primary. The options are either to promote a replica for disaster recovery(DR) or to promote a replica for maintenance.

• In a DR scenario the primary is dead, or for some other reason will not come back online. You would select one of your replicas to be the new primary. In this scenario if the old primary does come back online at some point, is permanently cut off from working with the rest of the servers in the deployment ever again. It would need to be reinstalled as a new replica if you want it to be in use.  Review the Authentication Manager Administrator's Guide for your version for information on how to promote a replica instance using the Replica Instance Promotion for Disaster Recovery option.
• For maintenance purposes, you can promote a replica instance to a primary instance while the original primary
  instance is online and functioning. Review the Authentication Manager Administrator's Guide for your version for information on how to promote a replica instance using the Promotion for Maintenance option.

If your primary goes offline you will not be able to do any administrative tasks like running reports, creating new users and assigning tokens. As soon as a replica is promoted to primary, the replica will take over and you will again be able to administer the deployment. Your replicas will handle all authentication requests while the primary is down. Once a replica is promoted, all replicas will send any authentication information to the primary so all of the servers will be in synch.

In either of the scenarios above if the old primary comes back online, you can attach it to the new primary as a replica then use the promote for Maintenance option and promote it back to be the primary.

[msg9]

^^^ Nice.  Excellent info and thorough explanation, @EricaChalfin , especially this part:

@EricaChalfin  wrote:

To answer your question, your Authentication Manager servers are in an active-active state where they all accept authentication requests at all times (except if you manually add an sdopts.rec, but that is for another time). It is not true failover where auth requests go only to one server and if it goes down, another server in your deployment automatically takes over.

---

---

---

---

---

@Samuel1, additionally, you can test replica availability and servicing for yourself by disconnecting the NIC on your primary RSA AM instance, and testing an authentication request.

First, on one of your replica instances, kick off the Authentication Activity Monitor in the Security Console by going Reporting > Real-time Activity Monitors > Authentication Activity Monitor.  Change the Number of Results from the dropdown if desired (handy if your servers are especially busy), and then click Start Monitor.  If all RSA servers are servicing your "customers" currently, with your primary instance disconnected, you should see in the Monitor that replication succeeds and is logged by a replica instance.

If RSA is all private for you, you'll want to make sure that your replica instances are accessible by all systems that require RSA authentication, obviously.  In other words, network security, rules, ACLs, and routing in place to allow the cross-site authentication traffic if the environment requires it.

[EricaChalfin]

@msg9,

Great comment! Thank you for adding those additional recommendations. I wish I could give you more than one like for this!