My company currently has a straight forward RSA Authentication Manager deployment at the moment. We have 1 x AM Primary and 1 x AM Replica on our internal network, and all of our clients (so far) are RSA Windows Agents installed on user laptops. The problem we have with this implementation is that users must use offline authentication, which can be very slow, while not on the internal network. We want remote users (not on our internal network, could be coming from any IP) to be able to authenticate against our AM servers using the Windows Agent client.
I've had a couple of calls with technical consultants from RSA and received different answers from "this is not possible" to "just put a replica in AWS and expose it to the remote workers". The latter is not as simple as it sounds if reading through other similar discussions on here (read: how to access self-service interface using public IP address) are any indication, if even possible.
First: is it even possible? Could I securely expose port 7004 on a replica in AWS, and configure FQDNs, DNS etc. in such a way that the replica is fully functional and accessible by remote workers?
Second: if not, is adding a web tier a viable solution to our problem? It's not self-service I'm interested in, it's authentication. The web tier documentation states that a web tier can handle RBA authentication - is this different from the authentication requests that my RSA Windows Agents would send?
We currently have a base license, but we're open to upgrading to get access to other features such as the risk engine if it would help us solve this problem.
Thanks,
Max
Bango
The reason the answers to this question range from the "not possible" to the "difficult" e.g. "just put a replica in AWS and expose it to the remote workers" is because the authentication is coming from the OS, not from a Web Interface. And the major problem here is not authentication but registration, making this agent known to the AM server, and Auto-registration to TCP port 5550 on an Internet facing server might be too complicated or too risky or both.
But if you want to try your own proof of concept, any cloud or Internet facing Authentication Manager Server would need to open UDP port 5500 on an Alternate - Public IP address for at least 1 replica, the replica in AWS. This AM replica would need a private primary IP to replicate between your Corp Network and your virtual AWS cloud, but this replica would also need an Alternate Public IP to which you could open on the AWS or cloud public facing FireWall.
To Avoid auto-registration you would need to stake out this users Home Router public IP address (which could change) and create an agent entry with this IP. This agent entry would probably also need its private IP address as an alternate IP. I'm not sure if changing the user's home private IP address space, e.g. 192.168.1.0 to the same Private IP address range as the AWS or cloud replica server's private IP range, e.g. 172.16.x.x or 10.x.x.x would help of complicate things, but the Home LAN would need to have a route to the Cloud replica public IP.
You would need to create/download an sdconf.rec that included this replica. You also probably need to create some NAT rule on your users home Firewall/Router, so that this agent 'thinks' the AWS replica has a private IP, but the home Router translates that to the public IP for the same replica. The AWS replica could then receive traffic on UDP port 5500, both time requests for discovery and Lock&Authentication requests when user wants to logon to Windows agent.
I'm not even thinking about the security ramifications of opening UDP 5500 to all the hackers on the Internet, but maybe, just maybe this might work. But it ties the user to a specific site, like his home. Auto-Registration would complicate this possible solution an order of magnitude. You kind of creating a site-to-site VPN between user's Home LAN and the Cloud based or Internet facing replica.
Before abandoning Offline Authentication with Windows agent, make sure you try the latest build, either 7.3.3[120] or 7.3.3[123] of the Windows agent. The past two years we have seen scores of Offline bug fixes, but the most significant have come this year, including AAWIN-2421 where agents trigger invalid proof error messages that repeat every 1-2 seconds.
000033697 - How to troubleshoot and fix most invalid proof and failed to send day data errors on the RSA Authentication Agent 7.x for Windows
You'll have to contact Support to get this build, it's not on RSA Link yet