Do TCP Agent using API ver. 8.5 & 8.6 need a new sdconf.rec file after a new Primary is promoted?

[#1]

Article Number

000039615

Applies To

RSA Product Set: RSA SecurID
RSA Product/Service Type: Authentication Agent API for Java
RSA Version/Condition: 8.5.0, 8.6.0
Platform: Linux
Platform (Other): Windows
O/S Version: Red Hat Enterprise Linux 6.x

Issue

Authentication Agent API 8.5 (partner FoxT BokS server) - how does it learn new replicas.
Definition: TCP agents using API ver. 8.5 & 8.6 to TCP port 5500 (not ReST agents using TCP port 5555, not UDP legacy agents using UDP port 5500) e.g. partner FoxT Boks Server agent.

Task

1. Add a new replica to your Authentication Manager realm
2. Promote new replica to become the new primary 
3. Remove original primary, either because you promoted for Disaster Recovery, DR, or you promoted for maintenance but eventually decommissioned the original primary that became a replica

Resolution

If you add a replica to your realm and TCP Agents authenticate, that agent learns of this replica through the configuration service, and the replica is added to bootstrap.xml and config.xml. 

When you eventually promote this new replica, and as the last step remove the original primary, our Assumptions are as follows:

1. Provide newly downloaded copies of the sdconf.rec file to all;
   1. a. new Boks TCP agents, and
   2. b. existing TCP agents that did not know of this new primary because they had not authenticated after this new primary had been added as a replica, and therefore did not learn of it through the configuration service
2. Technically you would not need a new sdconf.rec file for existing TCP agents that knew of this new primary because they had authenticated after this new primary had been added as a replica.  However, a Best Practice would be to maintain consistency with all downloaded sdconf.rec file

Notes

Engineering says that the TCP API 8.5, 8.6 agent does not work like the UDP agents, in that TCP agent does not send time requests to keep track of Replicas, TCP keeps track of Authentication requests that are not responded to. The TCP agent does not get a server list like in UDP agents, but has a way to learn about new replica through the configuration service, as you observed in Production, it’s just different than the UDP agent.
Agent uses the Configuration Service to determine whether or not there is updated configuration information.