cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1243
Views
3
Helpful
6
Replies

ISE 3.2 Azure AD and Secure Client RA VPN

packet2020
Level 1
Level 1

Hi All,

I have been testing ISE 3.2 EAP-TLS integration with Azure AD as per the following guide which works well.

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/218197-configure-ise-3-2-eap-tls-with-azure-act.html

Is it supported to extend this use case for Secure Client RA VPN cert only authentication? Currently our Intune managed devices use certificate only authentication when connecting to RA VPN with authorisation-ony against ISE. ISE sees the users UPN in the CN field of the certificate, however I'm not sure if ISE could then perform a lookup of the UPN against AAD (same as EAP-TLS) to return groups for granular application of VPN group policy. Is this supported?

 

1 Accepted Solution

Accepted Solutions

Greg Gibbs
Cisco Employee
Cisco Employee

I tested a similar scenario in my lab earlier this year and found that the ROPC group match did work with ISE 3.2 when ISE was only performing the Authorization.

The flow I tested was:

ASA <-> Azure AD [SAML + Azure MFA] <-> ISE [AuthZ Only]

View solution in original post

6 Replies 6

That's a great question.  If ISE knows the UPN, I don't see why the lookup wouldn't work.  Can you lab it up and let us know?

Greg Gibbs
Cisco Employee
Cisco Employee

I tested a similar scenario in my lab earlier this year and found that the ROPC group match did work with ISE 3.2 when ISE was only performing the Authorization.

The flow I tested was:

ASA <-> Azure AD [SAML + Azure MFA] <-> ISE [AuthZ Only]

We want to do Authentication via Azure AD SAML for our Remote Access VPN (FTD) via ISE.
The problem now is that ISE 3.1 doesn't seem to support Azure AD as External Source via SAML for other things than "Guest Portals".

What I was thinking the AAA setup should be:
- FTD RA VPN should use ISE and ISE should use Azure AD SAML for Authentication only.
- FTD RA VPN should use ISE and use other external sources needed for Authorization.

I can't seem to find if later versions of ISE (3.2/3.3) have full support for Azure AD as external sources.

The only workaround I can see is to directly configure Azure AD SAML on FTD for Authentication and use ISE only for Authorization.
For us there's a pretty big disadvantage doing this, using ISE as a single-point/junction for the AAA flows will not work.
So if we do it this way the AAA flow will be splitted and our log-handling and single-point for our Helpdesk to do enduser support via ISE will no longer be valid. But I can't see any other way to do it atm..?

 

The correct flow is to perform the SAML auth directly on the headend and use ISE as Authorize-only.

J. H.
Level 1
Level 1

I'm now using SAML and Azure AD. User gets MFA request, so far so good.
But it doesn't work. FTD/webvpn/SAML logs says this when user tries to connect:

[SAML] consume_assertion: The identifier of a provider is unknown to #LassoServer. To register a provider in a #LassoServer object, you must use the methods lasso_server_add_provider() or lasso_server_add_provider_from_buffer().
Jan 25 13:46:09

[SAML] consume_assertion:

[saml] webvpn_login_primary_username: SAML assertion validation failed


Anyconnect users get this message:
"Authentication failed due to problem retrieving the single sign-on cookie."

I've looked around but haven't found any solution. Seems to be a common problem with ASA though.

 

This is the error commonly seen when there is a mismatch between the SAML IdP configuration on the ASA/FTD and the SAML IdP metadata on the IdP side (Entra ID, in this case). I would suggest comparing the metadata from the Entra ID Enterprise Application (especially the EntityID value) with the configuration on the FMC/FTD to verify they are the same.

You might also compare your setup against this step-by-step guide - Cisco VPN: FTD and Microsoft Azure AD with MFA using SAML 

If you're still having issues, you will likely need to open a TAC case to investigate further.