on Jul 24, 2019I was talking with a customer yesterday who is migrating all of their AM servers to Amazon Web Services. Their process involves adding new replicas in AWS, then promoting one of them to become the primary, and then shutting down the original (on-prem) AM servers.
They have a lot of Windows clients using the RSA Authentication Agent for Microsoft Windows (a.k.a. “Local Authentication Client”/LAC) agent to protect desktop logins, and had some questions about how those agents get updates regarding which AM servers exist.
- Should the LAC agent automatically pick up changes to the available AM servers, and if so, is this done as part of an authentication request processing, and/or at any other time (such as at Windows reboot time)?
- Does the LAC agent use Contact Lists (https://community.rsa.com/docs/DOC-77058), and/or a different mechanism?
- Is there an easy way to see if the new AM servers are being detected by the client (such as by looking at the client's files - perhaps failover.dat, sdconf.rec, sdstatus.12, or securid files?)
- Does the customer need to push out an updated sdconf.rec file to all clients during or after the server migration?
There are ways to control and force certain behavior (sdopts.rec file, contact lists on the Security Console) but in general the agent will automatically follow changes, as each authentication also involves the RSA Servers feeding information to the agents about any landscape changes when possible.
It varies, and can be manually controlled differently, but... in general:
Agent will be informed of changes to the environment automatically...unless you make major changes and cut all RSA Authentication Manager servers off from reaching the agent. Updates occur when an authentication needs to be processed.
It uses a few mechanisms. First uses the sdconf.rec file to find the primary and any replicas listed at the time the sdconf.rec was generated, then the agent will build a list (file named sdstatus.12) and maintain the available servers in this list, and also will add new replicas to this list if you add them. If you use sdopts.rec files, it will use that, and follow whatever directives are in it. It will respect contact lists if you apply one to the agent in the Security Console. The agent will also note the reachability of the servers in the sdstatus.12 file and prefer to use the fastest responding ones. The agent will only add servers to this file, it will not completely delist any, but will start to not-prefer slow or non-existent servers (but will still occasionally try them since a stale entry may still exist). So it is possible to have agents working fine but they are also occasionally trying any number of missing or old RSA servers that no longer exist. Deleting the sdstatus.12 and letting the agent build a new one will clear stale entries and make authentications quicker, since the agent will no longer make attempts to reach missing servers, and have to retry another one in the list until it finds a working one.
RSA Control Center/Server Environment will list what is in the sdconf.rec and (once it exists) sdstatus.12 file. Sdstatus.12 is not human readable, you need RSA Control Center to view the server list. Also it may not be completely updated in one authentication, it may take a few authentications for this list to build out fully (when using the test authentication button, and watching the list, don't be frustrated if the list is not complete after a single authentication).
Maybe. It is not a bad idea, but may not need to be done...again, it depends. If you are not moving the Primary RSA server, then the agent will 'figure things out'. However, if you are making a lot of changes, a fresh sdconf.rec and deletion of the sdstatus.12 file will ensure the best agent to server communication once the server changes are done. This will ensure no stale entries in the sdstatus.12 (agent will make a new one) and sdconf.rec file. As routine, 'new sdconf.rec and delete sdstatus.12' is normal housekeeping duties when making major RSA Server ip changes.
Also be aware if there is an sdopts.rec file in use, it may also need to be changed. A stale sdopts.rec file with old info can interfere with authentication reaching the correct servers.