External RADIUS for authentication, but ISE for authorization

[scottsanderstof]

I've successfully configured client AnyConnect remote access VPN authentication with MFA via PingFederate+PingOne, but only partially. It seems that ISE is correctly handing off authentication to the PingFederate RADIUS service, but ISE does not seem to be handling authorization.

In my test authentication policy in ISE, I am using the external RADIUS server sequence in which I have configured PingFederate. This works fine. When testing AnyConnect, I am prompted for credentials, enter them and then I'm prompted for my Yubikey and then it successfully authenticates. But I'm just getting the default network access, despite me making attempts to configure an authorization rule in ISE to implement a DACL.

How can I properly configure ISE to hand off authentication to PingFederate but handle authorization in ISE?

[paul · Accepted solution]

There are two ways to do the external RADIUS integration.  If you are doing the true RADIUS proxy setup with the RADIUS sequence (it sounds like you are) then in the Advanced settings of the sequence you need to enable the authorization phase:

If you don't require attributes back from the RADIUS server you can also implement it as a RADIUS token server.  All you get back is a reject or accept from the server.  The token server is used like any other external identity store and will automatically go to the authorization phase.  

[scottsanderstof]

Thank you for pointing out that "On Access-Accept, continue to Authorization Policy" setting in the RADIUS Sequence settings. That did solve my issue of authorization policies not taking effect as expected after successful authentication.*

I believe I do have to use PingFederate as proxied external RADIUS server rather than just a token server. PingFederate sends RADIUS attributes back that prompt for your second factor authentication mechanism. Unless I'm mistaken, that definitely requires more than a simple accept or reject response. The vendor, Ping Identity, doesn't provide any guidance for using PingFederate as a proxied external RADIUS server or RADIUS token server. They want you to have the ASA point directly at it, bypassing ISE or any other intermediate RADIUS service.

* I did see some strange behavior, however. I had created a test Authorization Policy that used the built-in "Network_Access_Authorization_Passed" item as the only Condition, with "PermitAccess" as the Permission. For some reason, this AuthZ Policy wasn't matching and it was hitting my deny AuthZ Policy just below. It's as if the Authentication piece wasn't finalized with Access-Accept before the AuthZ Policies were evaluated, despite what the advanced setting says.

[paul]

The Network_Access_Authorization_Passed may not be set correctly when using a proxied RADIUS setup. The RADIUS prompting should still work with using a Token server setup I believe. The attributes I am talking about are other RADIUS attributes the RADIUS server is passing back that the NAD device is going to use or attributes you want to use in ISE in the authorization policy. You have it working with RADIUS proxy setup so I would keep using that.

[scottsanderstof]

Thanks, Paul!

[michaelzhq]

Hi Scott,

I am unsure if you will see my question here, in your integration with PingFederate, what Radius Attributes can PingFederate  return to ISE? what are the conditions to dACL? are you able to use AD User Group as condition? My understanding is, ISE doesn't authenticate VPN users against AD, it's ISE --- PingFederate --- AD. Would PingFederate   return AD User group info to ISE?

Thanks.