Any other title ideas? Let me know, but that’s the best that I could come up with to encompass the idea. Here’s a quick breakdown of the reason for this:

Reference Post: https://community.cisco.com/t5/vpn/anyconnect-with-azure-saml-sso-cannot-add-multiple-tunnel-group/td-p/4140732/page/4

Remote Access VPNs are common in the industry, they’re everywhere. SAML authentication has been rising in popularity as well due to its flexibility, security, and SSO capabilities. Sometimes though, the products, platforms, and tools that we use are ready for some of our use cases, especially when it comes to the newer technologies or workflows.

Cisco RAVPN, whether on ASA, FTD, or Secure Access, allows for the ability to utilize multiple tunnel groups (connection profiles) to be able to differentiate access, provide unique aliases for different employee groups, and utilize different authentication mechanisms…as just a few examples of why you’d need multiple. With the configuration flow inside of these platforms, you can choose authentication methods like AAA/RADIUS, SAML, local, and others.

But the issue lies in how these work. Many organizations use Microsoft Entra ID as their IDP. To use this with Cisco’s RAVPN solutions, you typically need to utilize SAML. And to do so, you build an application inside of Entra ID. To enable SAML authentication inside of the RAVPN headends for example, you need a few things from the Entra ID application: A certificate trustpoint from the Entra ID app, mapped to the Cisco RAVPN tunnel group’s SAML configuration.

When configuring this, you need a unique tunnel group name inside of each Entra ID app that will be used. So what I’m saying essentially is this: for each unique tunnel group that you want, you need a unique Entra ID app to pair with it. So what’s the problem then?

---

The issue with this workflow was that Entra ID applications share the same Entra ID tenant ID…and this is tied to a certificate trustpoint inside of the RAVPN object configuration for the SAML authentication. And, there was no way to “bypass” the certificate trust to allow for multiple Entra ID apps to be used as SAML configurations. To sum it up: you were only able to use 1 tunnel group name and 1 Entra ID app if you wanted the SAML authentication to work. Here’s a few quick bullets about it:

Original Issue:

• AnyConnect RAVPN with Entra ID SAML Authentication
  • Only allows for one tunnel group association. Each Entra ID application requires a unique tunnel group name.
  • If multiple tunnel groups are needed, multiple Entra ID applications must be used.
• ASA/FTD Configuration Limitations
  • Does not support multiple SAML trustpoint certificates. Each Entra ID application has its own certificate but shares the same tenant ID.
  • Only the certificate mapped to the SAML configuration can be used in the ASA/FTD tunnel group configuration.

Now the fix: As of ASA version 9.17, multiple SAML trustpoints can be added and each can be mapped to individual tunnel groups on the ASA/FTD. Because of this, each tunnel group can now map to an Entra ID SAML application with its unique certificate trustpoint using the “override” feature.

---

Setup: In this setup, three different FTD tunnel groups were configured with SAML authentication to Entra ID.

To accomplish this:

• Create one SSO Server configuration for Entra ID inside of the VPN headend
• Create multiple certificate trustpoints on the VPN headend, one for each Entra ID app
• Create multiple tunnel groups inside of the VPN headend (example uses 3 different ones)
  • The key here is the “Override identity provider certificate” checkbox, and select the correct trustpoint certificate for the respective app. This will allow you to change the IDP certificate to the correct one, and pass the authentication from a specific tunnel group to the corresponding Entra ID app.

FTD Configurations

Entra ID configurations (Note same tenant, different apps)

Results: Successful authentications to each tunnel group/application using SAML with different certificates

So there you have it! Using configurations similar to this, we’re able to utilize multiple RAVPN tunnel groups with SAML authentication. And have that authentication work on a per-group basis!