Forum Discussion

Larson27's avatar
Larson27
Icon for Nimbostratus rankNimbostratus
Nov 07, 2015

RSA Authentication and APM

Before I get to the question - let me give a short, quick overview of how this was designed to work by our architects.

 

Our APM is configured as a Shared Device in a MS environment. One of those services we offer is RSA and the APM.

 

We have one Virtual Server - One Access Policy pointing to that Virtual Server with all internal and external customer connections going through one access policy.

 

For customers and internal users - our Shared RSA and AD functions without an issue. The bulk of the customers take advantage of this…however.

 

We have 2 customers where we manage their RSA in their environment. We have both Production and Management IP’s to work with.

 

I have the RSA Agent Host configured to use the Floating IP with the Secondary IP’s as the APM Pairs (we have 4 sites). I have created the AAA server to point to that Floating IP associated with the Agent Host.

 

The AD is also managed in the customer environment - and will be used for nothing more than query for the various Network Tunnels that are to be assigned to their employees, but those are also setup.

 

Now for the APM - Each customer gets their own separate VLAN - bank of /29 IP’s. We use individual route domains/routes/floating and self IP’s.

 

My issue - and I have been banging my head on this for about 2 months…I can authenticate from inside the APM to the RSA - however when attempting via the URL for the customer - it shows as no traffic leaving the APM.

 

My argument back to the architects (for the last 2 months) is that each of our "external" customers will require their own Virtual Server/Policy Editor configuration with their own set of "private" (for lack of a better term) IP's in order for RSA to see the traffic from the APM.

 

Has anyone ever encountered this issue - Fire away with questions, I will answer as best I can, as I may have missed something in my wordy description.

 

Thanks!

 

DJL

 

1 Reply

  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Historic F5 Account
    Securid on APM requires the use of a user-space process called "ACED". This process is shared in the system. APMD or APD (depending on version of APM) load the sdconf.rec configuration into ACED and request authentications based on that destination address and/or DNS names. ACED is a black box to us (we get this library from RSA). ACED does not allow any sort of source address configuration at L4. Nor does it allow any destination address configuration at L4 or L7. The source address configuration in the AAA object of ACED allows for a source IP address to be set at L7. So basically the destination addresses or hostnames of the RSA servers are set inside of sdconf.rec, but only ACED can determine what they are going to be, and they are non-configurable. It must be able to route this authentication traffic in Linux user space. Most RSA servers support also RADIUS protocol, which from a feature perspective to RSA is mostly equivalent, with the exception of: RSA+RADIUS does not support Adaptive Authentication, and there is some trouble configuring this with secondary node addresses, so the authentication packet source IP at L4 and L7 must match with the source IP defined in the Agent Host record. RADIUS protocol's advantage is that it's not secret, it uses a standard documented protocol, and also it's possible to manually set the destination L4 address instead of RSA picking it for you and putting it in sdconf.rec automatically..