Hi, I can find the downloads of the Authentication Agent for Windows, and for Linux+AIX (using PAM), but I can't see anything about macOS/OS X, which also uses PAM and presumably would work identically to Linux/AIX - only I can't find the download. Surely you don't have more AIX than macOS customers!
- Auth Agent
- Authentication Agent
- Community Thread
- Forum Thread
- Mac OS X
- pam agent
- rsa authentication agent
- RSA SecurID
- RSA SecurID Access
The short answer is RSA SecurID Authentication Manager does not support MAC mini box server clients or MAC remote console SSH, it only supports an MFA MAC client for console authentication against the SecurID Cloud service.
My point in mentioning RADIUS is a lot of clients for various VPN appliances and PAM modules support RADIUS, and RADIUS is a way to provide 2 factor authentication with Authentication Manager. RADIUS connections are only supported if there is a Partner Guide, but in this case 'not supported' does not mean if won't work, it means if you find a bug, RSA Engineering will probably want you to reproduce the bug on a supported platform, so 'not supported' carries some risk.
so if I want to try the RADIUS 2FA for Mac Mini box, could you provide the RSA documentation which explains how and what configuration to make on the end point side(Mac mini box side). That would be greatful.
You would have to look at MAC documentation to see where Authentication is configured, and find where you can select RADIUS Authentication, then it would be a matter of configuring the IP address of a replica or two.
Have a look at this KB to get a quick understanding of how to configure a RADIUS client.
Hi Jay Guillette.
I just have one question regarding radius client authentication request flow, in the config file on the radius client side if I add 10 radius servers. For instance.
#Server Secret Timeout
XXXXXXX xxxxx 60
XXXXXXX XXXXX 30
.... similar 8 servers
based on what algorithm the request hits the radius server from radius client, I mean like first server does not respond then it goes to second server then if both first and second does not respond then it goes to the third server.. till 10th server. could you explain the authentication flow or else could you provide me any document that explains that.
The RADIUS protocol only has failover, not load balancing. This means the first RADIUS server that the client sends authentication request to has to fail or not respond, in order for the RADIUS client to try the second RADIUS server in the list. How long it takes to Fail-over is a product of both the Re-transmission Timer or Timeout and the Number of Re-transmission attempts or times. Both of these can be configured in a RADIUS Client.
For example, if you had 12 NTRadPing.exe RADIUS clients with the following configuration of a 6 second time out re-Transmission timer, with 2 Retries,
It would take 18 seconds before NTRadPing RADIUS client failed over to the second RADIUS server in the list, that is 1st attempt plus 2 retries = 3 total tries, times 6 second timeout, 3 * 6 = 18. These numbers a lean, but good. Anything less than 5 seconds for a time-out does not give the RADIUS server enough time to reply, and this can cause problems when the RADIUS Client re-transmits or re-sends an authentication request, which passes the RADIUS server authentication response on the Ethernet, and when re-transmission reaches the RADIUS Server, RADIUs server sees the same token Passcode used a second time and automatically flags it as a Re-Use Attack, and shuts down the user Authentication, changing the initial success to a re-use failure. !0 second re-transmission timeouts are considered the norm or average, and that single change from 6 seconds to 10 seconds would make the fail-over total time go from 18 seconds to 30 seconds (3 total transmits x 10 seconds time-outs).
I consider 5 retries high, usually a waste of time, because if the RADIUS server does not respond after 3 attempts, it probably is not going to respond after 2 more tries.
So with 12 RADIUS clients with my original lean numbers; 2 retries with 6 second timeout for 18 second failover, two things have to be true in order to ever send an authentication request to the 12th RADIUS Server in the fail-over list;
1. All 11 RADIUS servers before or in front of the 12th RADIUS Server have to be down or unreachable, and
2. The RADIUS client would take 198 seconds, or 3 minutes and 18 seconds, before the RADIUS Client would even send its first authentication request to the 12th server. Or 330 seconds with 10 second timeouts and 2 retires, 5.5 minutes.
Some products like NetScaler or an F5 Load Balancer can be configured to load balance across serveral RADIUS servers, but that is proprietary and not part of RADIUS protocol.
Other options include reversing the list or mixing it up, so different RADIUS clients go to different RADIUS servers first. That's a manual process, you'd need to document it.
Hello Jay Guillette
Thanks for your response.
Here we are using Pluggable Authentication Module (PAM) "pam_radius-release_1_4_0.tar.gz", so in this module let's assume we cannot write number of retries, we can only write timeout parameter