IDR resiliancy, Cloud based IDRs and Authentication Manager considerations

[JayGuillette]

You may need your customer account Identity Specialist or a Sales Engineer, SE involved in any detailed planning, but you can start with the answers to the following questions to put some boundaries around your IDR planning. This specific customer preferred the Azure Cloud, but there is currently (Oct 2021) no Azure based IDR available, only Authentication Manager, AM is available for an Azure deployment.

Major points

Two kinds of IDR, Standalone and Embedded. Standalone is a complete IDR deployed as a virtual appliance either on;
1. A VMWare virtual machine (.ova)
2. Windows Hyper-V virtual machine
3. Amazon Web Services, AWS (.ami) - either in commerical or govcloud, please specify
Note: Currently no Standalone Azure deployment.

The Embedded IDR basically comes 'in' your Authentication Manager server console, which means you need to consider AM server deployment options. AM servers can be deployed as
1. A VMWare virtual machine (.ova)
2. Windows Hyper-V virtual machine
3. Amazon Web Services, AWS (.ami) - either in commericial or govCloud, please specify. ver. 8.3 to 8.6 available
4. Azure virtual Machine
5. Hardware Server, currently either Dell R640 or Dell R230

However, the embedded IDR does not have all of the functions that the standalone IDR does. The embedded IDR does not support the app portal, therefore if your company uses the app portal, you will either want to avoid the embedded IDR or possibly attempt to include it in your mix, being careful to isolate app portal SSO use case users from hitting it.

Another limitation of the embedded IDR is no direct RADIUS to IDR. You can authenticate RADIUS clients through AM, But click to approve or PIN plus approve authentication only works if you have your AM connected to the Cloud Authentication Service, CAS. So you lose out on the Access Policies configured in the IDR. Embedded IDR means authentication only, with some limits, through the AM to CAS connection.

What this indicates right now, is if your cloud solution is Azure, you can deploy an Azure AM replica today attached to your on-prem primary, and promote the Azure replica to be an Azure primary. Then deploy other Azure replicas that would replace your on-prem replicas. You could get your entire AM infrastructure into Azure if you wanted to, minus a stand-alone IDR. You likely need hybrid with some on-prem to maintain the stand-alone IDRs that you currently have.

I don't have any info on when Azure stand-alone IDR would become available (As of October 2021). However, you really need to reach out to your Sales contacts, possibly your identity specialist, to have a Sales Engineer discuss the finer details of how you want to build this. You need RSA to deliver a stand-alone Azure-based IDR if you plan to make a complete move to Azure Cloud, or you need a mix of some AWS nodes for a two cloud solution, with no on-prem. You also need to decide if you want to completely eliminate on-prem Authentication servers. It is possible now, but with at least some AWS. It might be possible for all Azure at some point, but not today. Thanks.

Other Resources
Cloud Authentication Service POC Quick Setup Guide
https://community.rsa.com/t5/securid-access-cloud/cloud-authentication-service-poc-quick-setup-guide/ta-p/591800

Cloud Authentication Service Quick Setup Guide for SSO
https://community.rsa.com/t5/securid-access-cloud/cloud-authentication-service-quick-setup-guide-for-sso/ta-p/631090

Cloud Authentication Service Quick Setup Guide for SAML Applications and Third-Party SSO Solutions
https://community.rsa.com/t5/securid-access-cloud/cloud-authentication-service-quick-setup-guide-for-saml/ta-p/569692

Cloud Authentication Service Quick Setup Guide for RADIUS Clients
https://community.rsa.com/t5/securid-access-cloud/cloud-authentication-service-quick-setup-guide-for-radius/ta-p/591801

Hat Tip to Rob Guillette, my favorite source to plagiarize from.

[SAULSCHWARTZ]

Maybe outside the scope of this conversation, and I was going to open a support ticket to ask this question, but this seems like the appropriate forum.

We have had 2 separate scenarios of the Cloud Authentication Service (CAS) become unavailable due to an outage, which broke our direct radius configurations (ASA to Radius IDR, Citrix Gateway radius to IDR. The first time, we did not have High Availability Tokencodes enabled, so we were out of luck. The 2nd time, we did have that enabled, but authentication still failed.

In the event of another outage, we are just out of luck with direct radius? 

[JayGuillette]

Saul, 

That's a good question, because you are asking about the resiliency of RSA's Cloud Authentication Service not your IDR availability.  There have been some discussions about how to make things work if and when there is an RSA Cloud outage, with High Availability Tokencodes part of that solution.  Let me see what else I can find out for you.

Regards,

[JayGuillette]

Rob, the other Guillette, said if your RADIUS clients are pointing to the IDR, then then High Availability Tokencodes won't help, they would only allow you to use Cloud based tokens against Authentication Manager based RADIUS clients, not IDR based RADIUS clients.  RADIUS clients are things that use RADIUS to authenticate, like Citrix NetScalers, Cisco ASA (can be configured for either RADIUS or Native Authentication Manager SDI protocol) and a host of VPN devices.

Authentication Manager is the on-prem part of SecurID Access, basically an appliance that runs on VM, Hyper-V, or Dell Hardware (R640 or R240) in your glass house, or on AWS (as an .ami) or Azure, where RSA shares our appliance image to your account for deployment on your cloud.

[RobertG]

Right, the "High Availability Tokencodes" feature would allow users to continue to use the Authenticate Tokencode on resources pointing to Authentication Manager if/when Authentication Manager is unable to communicate with the Cloud Authentication Service. As a reference: https://community.rsa.com/t5/securid-authentication-manager/configure-high-availability-tokencodes/ta-p/629542