Double Authentication on ASA using ISE

[umahar]

Our customer uses double authentication for ASA VPN with ACS as primary authentication using AD and ISE as secondary authentication using Safenet and RSA (both in one single identity source).

They now want to move both primary and secondary authentications to ISE as they are getting rid of ACS.

I am reading below link

https://community.cisco.com/t5/identity-services-engine-ise/anyconnect-vpn-with-2-factor-authentication-on-ise/td-p/3464708

Was anyone able to find any attribute to distinguish between two radius requests ?

We have two datacenters with 4 PSNs. The idea to send different requests to different PSNs and making check on that also sounds feasible.

If none of the above works we will send AD authentications requests directly to AD from ASA.

Is there any other option anyone can think ? Maybe some kind of chaining

[hslai · Accepted solution]

I think it simpler to send the AD auth directly from ASA. If the 2 requests are sent to different sets of PSNs, then you may use "Network Access·ISE Host Name" as a condition.

[paul]

Hsing,

This is more of a product request, but one thing that would help in cases like this is if we were able to use the DestPort field in our rule set.  If you look at the RADIUS authentication details you can see the destination port of the RADIUS call (1645 or 1812).  If there were a Network Access:Destination Port value we could use it for several use cases:

1. This use case where I want different RADIUS calls from the same host and same scenario to be treated differently.
2. The RADIUS callback trick for portals in ISE.  We could do callbacks on different ports to differentiate which portal is making the call and allowing different AD groups to authenticate to the portal.

The data is already there.  It doesn't seem like it would be that hard to expose that data in the conditions. 

[hslai]

Many thanks for your input. However, such might not be as simple. If both requests for one RA-VPN session gone into the same PSN, anything sensitive to the state of the session might mess up. If the requests gone into different PSNs, then it's unclear which PSN is the true owner of the session, as the whole deployment shares one session directory.