are there any documents or KBs to introduce the RSA AM Primary and Replica authentication data flow and technical principle when the authentication agent are RSA Agent and radius client.
I want to know the AM instances cluster technology principle.
thank you.
I can give a 10,000 foot view...
First, a primary and any replica are stand-alone machines when processing an authentication. Whichever machine sees the incoming authentication request, that machine alone must resolve the userid, tokencode, and send a response. This means it uses its own internal database and its own ldap connections to do its job.*+*
Replication is only to keep all machines up to date with the current status of users and any administration done on the primary. And for replicas to send logs of what they are up to, to the primary.
For load balancing and for authentication requests hitting different RSA servers, it is up to the agent device to determine, 'if I get no response from the RSA server I just tried, I will pick another one to try before failing outright'. How this load balancing occurs is different depending on how the agent is coded.
Typically with RADIUS clients, you have a static list of RSA servers to pick, and one is a 'primary' and one is a 'failover' and you may or may not be able to add more RSA servers to this list. If the first RSA server does not respond, the agent picks the failover next.
If the agent is an RSA-branded one, or uses 'rsa nugget code' such as 3rd Party Partners like Cisco or Checkpoint, they may use native SecurID protocol instead of RADIUS, which is designed to load balance between all RSA servers and they automatically pick the servers. If you switch these same devices to use RADIUS, then it becomes more static and hand-written list of servers and 'primary' and 'failover' concept exists.
How RADIUS works on RSA Authentication Manager servers is: we have a RADIUS engine on each server, which is in fact, a SecurID agent that happens to live on the same machine as the Authentication Manager. RADIUS receives an incoming request, then it acts like any other SecurID agent and checks it's RSA server list, and tries one. It will try itself first since that is usually the fastest responding server, convert the RADIUS request to a SecurID request, pass this to the loopback interface where RSA server is listening on port 5500/udp for auths, and will process it and send a reply. If, for some reason, the RADIUS engine is up, but the authentication service is down, that RADIUS engine will actually try to authenticate against another RSA server in the realm, on the network like any other SecurID agent.
This is the only time an RSA server will ask another one to process an incoming authentication..."If RADIUS and If my own local authentication engine is not responding, try another RSA server using native SecurID." Otherwise, as said before, the RSA servers are stand-alone and will never ask another RSA server about an incoming authentication.*+*
Native SecurID protocol is designed to automatically learn of all RSA servers in the realm, and if you add one or change it's IP the agent will learn about it automatically and you don't really need to tend to the agent much after initial setup. RADIUS protocol has none of that automatic intelligence* so you need to hand-configure the list of RSA servers on the RADIUS agent if/when network changes occur.
*Some RADIUS clients do have a bit more intelligence to pick which RSA server to use, but typically RADIUS is unaware of 'RSA protocol' and RSA specific behavior.
*+*Special case: You can configure one set of RSA servers to connect to another set of RSA servers and perform Trusted Realm Authentication. This facilitates people using tokens on someone else agents if the trust between realms is established ahead of time. If you are set up for Trusted Realm/Cross Realm/XR...then an incoming auth request in which the user is not recognized locally in the internal database or the ldap connections, and if you have trusted realms configured, then that RSA server will ask the other RSA servers in the remote realm if they can resolve the user. This is designed mainly for large deployments where employees may travel globally to other sites that have different Primary, Replicas, and agents, and the user already carries a token, they do not need to have another token assigned to log into agents they normally don't use, but now need to use since they are accessing a different facility.
if there are one primary and many replica instances, and use RSA standard Agent( SecurID Protocol) to authenticate, how does the SecurID Agent send authentication request default? one by one according the AM IP list or simultaneously to all server instances and only accept the first arrival response?
Hi Jian,
When you installed RSA agent with sdconf.rec file, this file contain only information about primary. This RSA agent sends its first authentication request to primary. The primary server validates the request, the agent will request the latest replica list from that server. After the server sends its latest list to the agent, the agent stores the list information in its sdstatus file (for each replica in list he test a speed response to make a list). Is possible to create file sdopts.rec to let you make a choose.
got it, thank you all
I can give a 10,000 foot view...
First, a primary and any replica are stand-alone machines when processing an authentication. Whichever machine sees the incoming authentication request, that machine alone must resolve the userid, tokencode, and send a response. This means it uses its own internal database and its own ldap connections to do its job.*+*
Replication is only to keep all machines up to date with the current status of users and any administration done on the primary. And for replicas to send logs of what they are up to, to the primary.
For load balancing and for authentication requests hitting different RSA servers, it is up to the agent device to determine, 'if I get no response from the RSA server I just tried, I will pick another one to try before failing outright'. How this load balancing occurs is different depending on how the agent is coded.
Typically with RADIUS clients, you have a static list of RSA servers to pick, and one is a 'primary' and one is a 'failover' and you may or may not be able to add more RSA servers to this list. If the first RSA server does not respond, the agent picks the failover next.
If the agent is an RSA-branded one, or uses 'rsa nugget code' such as 3rd Party Partners like Cisco or Checkpoint, they may use native SecurID protocol instead of RADIUS, which is designed to load balance between all RSA servers and they automatically pick the servers. If you switch these same devices to use RADIUS, then it becomes more static and hand-written list of servers and 'primary' and 'failover' concept exists.
How RADIUS works on RSA Authentication Manager servers is: we have a RADIUS engine on each server, which is in fact, a SecurID agent that happens to live on the same machine as the Authentication Manager. RADIUS receives an incoming request, then it acts like any other SecurID agent and checks it's RSA server list, and tries one. It will try itself first since that is usually the fastest responding server, convert the RADIUS request to a SecurID request, pass this to the loopback interface where RSA server is listening on port 5500/udp for auths, and will process it and send a reply. If, for some reason, the RADIUS engine is up, but the authentication service is down, that RADIUS engine will actually try to authenticate against another RSA server in the realm, on the network like any other SecurID agent.
This is the only time an RSA server will ask another one to process an incoming authentication..."If RADIUS and If my own local authentication engine is not responding, try another RSA server using native SecurID." Otherwise, as said before, the RSA servers are stand-alone and will never ask another RSA server about an incoming authentication.*+*
Native SecurID protocol is designed to automatically learn of all RSA servers in the realm, and if you add one or change it's IP the agent will learn about it automatically and you don't really need to tend to the agent much after initial setup. RADIUS protocol has none of that automatic intelligence* so you need to hand-configure the list of RSA servers on the RADIUS agent if/when network changes occur.
*Some RADIUS clients do have a bit more intelligence to pick which RSA server to use, but typically RADIUS is unaware of 'RSA protocol' and RSA specific behavior.
*+*Special case: You can configure one set of RSA servers to connect to another set of RSA servers and perform Trusted Realm Authentication. This facilitates people using tokens on someone else agents if the trust between realms is established ahead of time. If you are set up for Trusted Realm/Cross Realm/XR...then an incoming auth request in which the user is not recognized locally in the internal database or the ldap connections, and if you have trusted realms configured, then that RSA server will ask the other RSA servers in the remote realm if they can resolve the user. This is designed mainly for large deployments where employees may travel globally to other sites that have different Primary, Replicas, and agents, and the user already carries a token, they do not need to have another token assigned to log into agents they normally don't use, but now need to use since they are accessing a different facility.