Showing results for 
Search instead for 
Did you mean: 

Preface: I had a hard time locating documentation for configuring AnyConnect with Azure AD as a SAML IdP - So I took some notes and thought I'd share. I hope it helps someone.

Azure Setup

Login to Azure Portal (


Click Azure Active Directory


Click Enterprise Applications -> New Application -> Non-Gallery Application


Give it a Name (I'll use AnyConnect-SAML) and click Add at the bottom.




Click the Single sign-on menu Item.

Select SAML




Download the Certificate Base64 from section 3 (We'll install this later)


Make note of the following from Section 4:

Azure AD Identifier - This will be the saml idp in our VPN configuration.

Login URL - This will be the url sign-in

Logout URL - This will be the url sign-out


At this point you have the Data Required to begin configuring the VPN Appliance.

We will need to come back here after configuring the VPN Tunnel-Group and grabbing the metadata.


VPN Configuration - CLI


Alright, we're going to do this on the CLI first, I might come back through and do an ASDM walk-through at another time.


Connect to your VPN Appliance, we're going to be using an ASA running 9.8 code train, and our VPN clients will be 4.6+


Please note there are SAML 2.0 minimum requirements (I believe they are ASA 9.7+ and AC 4.5+ otherwise SAML 2.0 isn't supported or you need to use external browser config… this is outside the scope of this walk-through)


First we'll create a Trustpoint and import our SAML cert.


config t

crypto ca trustpoint AzureAD-AC-SAML
  revocation-check none
  no id-usage
  enrollment terminal
  no ca-check
crypto ca authenticate AzureAD-AC-SAML

PEM Certificate Text from download goes here



The following commands will provision your SAML IdP


  saml idp (This is your Azure AD Identifier from SSO Section 4 of Azure App)
  url sign-in (Login URL: SSO Section 4 of Azure App)
  url sign-out (Logout URL)
  trustpoint idp AzureAD-AC-SAML
  trustpoint sp (Trustpoint for SAML Requests - you can use your existing external cert here)
  no force re-authentication
  no signature

Now you can apply SAML Authentication to a VPN Tunnel Configuration.

(Configuration of a VPN Tunnel Group or Group Policy is beyond the scope of this document)


tunnel-group AC-SAML webvpn-attributes
  saml identity-provider
  authentication saml

write mem

*Note: There's a feature with the SAML IdP configuration - If you make changes to the IdP config you need to remove the saml identity-provider config from your Tunnel Group and re-apply it for the changes to become effective.


Finishing up with the Azure AD App


We're now ready to grab the meta-data for our tunnel config and finish the Azure application configuration.


You can use a URL similar to below to view the SP metadata. = the address at which my ASA is reachable

AC-SAML is the tunnel group name configured for SAML auth.


SP Metadata: (Also your Entity ID - Azure App Section 1)



In the metadata XML look for AssertionCustomerService, the Location field in this tag is the Reply URL for the Azure App In SSO Section 1.


Edit the Basic Configuration Section by clicking on the pencil in the top right.

Add the Entity ID & Reply URL


Click Save in the SAML Basic Configuration.


You should now have the basic communication between the ASA and Azure AD wired up.


You may need to add user permissions to the app  in Azure AD and conditional access policy for multi-factor, etc.

All beyond the scope of this walk-through, but highly recommended.

philip moore

great post, thanks!

Managed to get this working also. Was wondering if you have managed to achieve scenario where you can authenticate diffferent group policies against different Azure AD groups? Simple scenario could be to have one Azure AD group for SSL VPN, and a different AD group for Anyconnect client VPN tunnel-group X.


@philip moore Thanks for the feedback. I haven't looked at attempting that, as I don't have permissions for the Azure AD instance when I was testing - but you do have to assign access to the SAML application and you could do that by Azure AD Group.

My bigger issue was around scale. Our users hit a generic url, and then several bits occur.

Based on the user's geographic location (and service availability) we're going to give a dns response to resolve to the closest data center. This response will be the load balance IP for the ASAs in the data center. Cisco LB magic chooses the least loaded ASA and then the FQDN redirect occurs.

I can't remember if the FQDN redirect matches the SAML service request, if it does then you would just need an Azure App for each ASA. When I was proving this out, my goal was to test part of a Microsoft auto-pilot experience and trying to get already provided (multi-factored) credentials stitched in from the Azure AD session into the SAML auth for AnyConnect. For that part it was successful, and I set down the results to wait for the client engineering team to catch up with the different Azure options. Then I'll figure out how to scale it.

philip moore
as I recall you specify the redirect URL (post authentication) in the SAML
request in which case ASA would control this. There is also option on Azure
app for the same to override this, but as you say this would mean an app
per instance. some experimentation required! :)
VIP Advisor VIP Advisor
VIP Advisor
Thanks for the nice tutorial! Anybody in the meantime managed to do group-locking / assigning with AAD? I'm very soon going to test this out, but have never worked with Azure. Current setup is radius based. Bonus question, anything special required to enable this with 2-factor authentication? (besides the licenses in AAD and already provisioned clients)


I have a feeling you might need to specify different groups with different SAML Applications as the URL would change per group. There didn't seem to be a way to include any dynamic portion within the SAML app when it was defined on Azure. As far as Azure MFA, we had a policy to require it once per session. I believe the default behavior was to MFA re-authenticate every time and I had to make a configuration change to allow a previous MFA for the session to be accepted.


I believe that's where the

no force re-authentication

comes into play from above.

VIP Advisor VIP Advisor
VIP Advisor
Hmm not good, that would certainly be a loss of convenience for my users. I just discovered that there is an AAD plugin for Windows NPS Radius, which might also allow this, while the ASA still communicates through Radius.

That's an excellent guide. Thanks for creating it and sharing the knowledge.

Has anyone tested Azure AD SAML SSO + MFA? I am guessing the MFA will come by applying Conditional Access to the Enterprise Application settings.

VIP Advisor VIP Advisor
VIP Advisor

If MFA is enabled for the user, then he will automatically get asked to supply the additional factor while authenticating. At least in my quick testing.


Thanks for your reply @patoberli. MFA is enabled in Azure for our users by default. In that case, after we setup the mutual relationship between Azure and Cisco ASA how will the user experience be when they trying to use Cisco Anyconnect? Will the authentication happen via a Web browser or via the Anyconnect client?
Also, have you tried group-locking / assigning with AAD?

VIP Advisor VIP Advisor
VIP Advisor

I did not manage to do group locking, without using separate configurations on Azure side for each group (didn't test it, this was too much of a time requirement). Assigning is NOT working with AAD, at least I didn't see any transmitted attributes.


The authentication will happen in AnyConnect. It will pop-up a window, with the Azure AAD authentication website.


The ASA SAML/MFA Azure setup is working great.


However,  if Anyconnect XLM Profile is used with AlwaysOn (+Trusted/Untrusted Network Policy + ConnectFailurePolicy), that profile denied the SAML redirect from Anyconnect client toward Azure SAML IDP, because all traffic from AC client is "denied" until AC is logged in. 


Any clue, idea ?  We are very looking to keep the "always on" feature ON at the exeption of the communication toward Azure for SAML authentication. 


Incredibly helpful.  Following these instructions worked perfectly.  Works great with Azure MFA with no on-premise MFA servers.

If anyone is like me and wants every connection to the VPN to force the user to enter their username, password and MFA info or in Cisco's words "force re-authentication to cause the identity provider to authenticate directly rather than rely on a previous security context when a SAML authentication request occurs" then do not add the "no force re-authentication" command.  You want "force re-authentication" if you want users prompted every time.


Does anyone have any guidance on how to achieve something similar with a Firepower appliance using FDM?

Currently, for users on Azure AD, we are spinning up a VPN account on the appliance and integrating it with Duo via JSON script/Postman as per this document:


A few customers don't want 2 x 2FA solutions though and want to use their AAD credentials.




I feel like I have a very dumb question and my Google Fu is failing me today.


My manager is asking us to implement this, but I don't quite understand how this would benefit our company. 


What actually happens when this is implemented? 


Here is our typical login process/use-case scenario:

  • login to laptop - get connected to internet... all the usual stuffs
  • connect to VPN - login using AD creds
  • access to Outlook email and MS Office is all on the laptop itself, not in the cloud

What am I missing? Any clarification would be MUCH appreciated!




VIP Advisor VIP Advisor
VIP Advisor
Hi Lily

This is a very generic question in regards to safe office network access. In case you use Office365 (with Exchange in the cloud and Onedrive with all the documents in the cloud), you will not need VPN (typically). If you have on-premise storage servers, which you don't want to allow access directly from the internet (you don't want that, that would be very bad to do), then you should use VPN.

A typical setup has a redundant VPN gateway on-premise and your clients (users) connect via VPN encrypted to your office network. Then they can access the company internal documents.

That's what VPN is for. Here it's about on how to do the authentication through Azure AD instead of the typical Radius protocol.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Quick Links