Most networking administrators have probably spent at least some time setting up a remote-access VPN for their company or for a customer. To authenticate end-users that connect to the VPN, it is very common to utilize an external database of users and to communicate with this external database you usually have to use the LDAP or RADIUS-protocol to talk either directly to an LDAP-catalog or to a RADIUS-server (like Cisco’s Identity Services Engine, ISE, for example).
However, if your VPN-solution consists of an Cisco ASA-firewall and the AnyConnect VPN software, there is a new option/protocol available to handle authentication: SAML, which stands for Security Assertion Markup Language. SAML has grown big in the last few years to provide authentication and single sign-on (SSO) experiences for applications like email, websites, ticket services and much more. The general idea of SAML is that once you have gone through a succesful authentication, you are handed a sort of cookie or “ticket” inside your web browser that will allow you to automatically be signed into the next service you want to use that also uses the same SAML-authentication. Today, there are many different products that use SAML-authentication from well-known companies like Microsoft, Okta, Ping Identity and even Cisco (through their Duo service).
Oct 15, 2017 ASA AnyConnect Configuration Steps Copy the AnyConnect client to flash. Enable SSL VPN on the ASA interface. Specify the AnyConnect image and enable AnyConnect connections. Ensure the sessions land on a proper tunnel-group: - Configure certificate to connection-profile mappings. Configure group-url at the tunnel-group level. On the ASA, use the show version command in order to check if the feature is enabled. The license name differs with the ASA release: €€ ASA Release 8.0.x: license name is AnyConnect for Linksys Phone. ASA Release 8.2.x and later: license name is AnyConnect for Cisco VPN Phone. €€ Here is an example for ASA Release 8.0.x: €€ ASA5505.
- Oct 09, 2013 Introduction This document describes how to understand debugs on the Cisco Adaptive Security Appliance (ASA) when Internet Key Exchange Version 2 (IKEv2) is used with a Cisco AnyConnect Secure Mobility Client. This document also provides information on how to translate certain debug lines in an ASA configuration.
- A Asa debug VPN anyconnect is created away establishing. A virtual private mesh is A technology that allows you to create a fail-safe connection over A less-secure material between your computer and the internet. It protects your privacy away allowing you to anonymously seem to be anywhere you choose.
As of this writing, successful SAML-authentications taking place for VPN does not “carry over” for use with other services because of how AnyConnect works… so keep that in mind for your own implementation.
I am not going to go into detail how SAML-authentication works but the main thing about the SAML-authentication flow is that when you initiate a VPN-session in AnyConnect (by typing in the URL/IP to your ASA and clicking “Connect”) instead of getting the normal AnyConnect login-prompt you will be redirected to a so called Identity Provider (IdP) which will present you with a login website that opens up inside AnyConnect (at least if you are using AnyConnect version 4.6 or newer). It is very common for companies and organizations to design their own login-page using their brand colors and logotypes to make users feel at home. Since the VPN login will look the same as for other applications used by the users, they will be very familiar with the interface. In SAML-terms the ASA will be acting as a Service Provider (SP).
This is not going to be a complete guide on how to setup SAML-authentication for VPN on the ASA, we will only cover the SAML-configuration on the ASA and not the configuration of basc VPN-settings like Group Policies etc. We will also not cover the configuration of the IdP, mainly because 1) you, the network administrator, will probably not be the one tasked to do that configuration and 2) there are way to many different IdP-services and I’ve barely seen any of them. This article is more about putting together a collection of good things to know that I’ve picked up from implementing SAML-authentication myself and from reading about other people’s experience on the Cisco Support forum. The main reason I felt the need to make this article is that Cisco’s own documentation regarding SAML is pretty barebone and it does not cover all the steps needed in a good enough manner, in my opinion.
General Setup
Below you see a simple diagram of the connections and communication that takes place in a SAML VPN-solution. The IdP could be either on your internal network, your DMZ or on the internet if you are using a cloud service.
Technical requirements
I’m just gonna get this out right away, there are some technical requirements that need to be met to use SAML-authentication for your VPN-connections:
Your ASA must have a trusted certificate installed, preferably from a third-party.
Your IdP must also have a trusted certificate installed, preferably from a third-party.
SAML-authentication differs quite a bit from the usual RADIUS or LDAP-authentication you are used to: the ASA doesn’t actually know the name of the user until the authentication is complete (either sucessful or failed) since the authentication takes place on the IdP. The IdP will inform the ASA of the username using the SAML-attribute NameID.
The Connection Profile (Tunnel Group) for your VPN that is going to use SAML as authentication method cannot contain any spaces. This it because the Connection Profile name is going to be used in the SAML-URL that the IdP will make use of. If you need to have multiple words in your Connection Profile, use dash or underscore between them.
If your SAML-authentication page is capable of reading user certificates from your computer, you must have AnyConnect version 4.7 or newer for this to work. Earlier version will not be able to fetch and present certificates stored on your computer to the IdP login page.
Your ASA must have DNS-servers configured that are able to do lookup the URL/IP of your Identity Provider servers.
Make sure your ASA and your IdP has NTP running and synchronized.
Basic VPN-configuration
Once again, this article assumes you have at least a decent amount of experience working with remote-access VPN configuration of an ASA and therefore I will not be covering the basics of Connection Profiles, Group Policies, IP-pools and so on. You know what’s best for your environment and the only thing this article will ask of you is to follow the technical requirement above (like the Connection Profile name) and that you set the Connection Profile’s User Authentication to SAML after you have configured the SAML (SSO) server futher down.
Adding the Identity Provider (IdP) certificate to the ASA
According to the documentation on Cisco’s website, you only need to add the root-certificate of the IdP’s certificate to the ASA buuut if you dig inside the Help pages inside the ASDM software you actually need to add the IdP’s certificate to the ASA.
As a best practice, I would recommend you install the root and intermediate certificates of the IdP’s certificate into the trusted certificate store of the ASA just in case. Head over to Configuration > Certificate Management > CA Certificates and click on Add to import the root certificate first and then do it again to import the intermediate certificate. You can add the certificates either as files (.der/.cer/.crt) or paste in the Base64 (text-version) of the certificates one by one.
However, for the “SAML-trust” to be setup between your ASA (SP) and the IdP, you also need to add the certificate of the IdP itself (the certificate that is used on the login website) as a trusted CA certificate.
Now comes the tricky part: I had trouble adding the IdP certificate itself in ASDM as a CA certificate because I kept getting an error stating the certificate could not be added because it needs to be added with the “no ca-check” command.
There is no way to issue the command “no ca-check” when importing the certificate using ASDM so you will need to add this certificate as a trustpoint using the command line instead.
<paste in the IdP-certificate in Base64-format>
And you’re done!
Configuring a SAML-server
Next up we need to add the SAML-server in ASDM, you can find the configuration for SAML-servers (or SSO-server as they are named here) under Configuration > Remote Access VPN > Clientless SSL VPN Access > Advanced > Single Signon Server. Don’t let the menu fool you, these servers are not only used for Clientless VPN.
The configuration of adding a SAML-server is pretty simple because there isn’t a lot of settings for you to play around with, but you will need to get some URLs from your IdP-administrator. Ask them for IDP Entity ID, Sign-in URL and Sign-out URL.
Please note that even the IDP Entity ID is a URL, it is not a “friendly name” that you can pick yourself so to speak.
Request Signature is something you must agree with your IdP-administrator about. Setting it to None is a very bad practice.
Request Timeout is something I would not touch unless told to by the IdP-administrator.
Make sure to remove “https://” before all URLs (except for the URL you set as IDP Entity ID) and all possibly added “/” from the end of the URLs, including the Base URL which is your ASA’s URL.
There is also a slight inconvenience with configuring SAML (SSO) servers and that is that everytime you make a change, you need to turn the SAML-configuration for that Connection Profile off and on again for the changes to take effect. Cisco is however aware of this oddity (it is tracked as en Enhancement under the bug-id CSCvi23605) and when you head into the SSO-server configuration you are greeted with this message:
To turn the SAML-configuration for a Connection Profile off and on again, either use the commands below or do it from ASDM on the Connection Profile > Basic > change SAML Identity Provider to “None” > click OK and Apply, then go back and reselect the SAML-server in the scroll list and click OK and Apply again.
Enter you Connection Profile/Tunnel Group:
Remove SAML-server from Connection Profile: Iriver driver.
Re-add SAML-server to Connection Profile:
What the IdP-administrator will need from you
Your ASA certificate which is used on the “outside” interface of your ASA and for VPN-connections, they will need it to complete the trust between the ASA and the IdP.
Your SAML metadata which can be found if you (on the outside of the ASA) browse to the URL of your ASA and access the SAML-resource portion of your Connection Profile (the so-called metadata). For example, if your VPN URL is https://vpn.mydomain.com and your Connection Profile is called VPN-SAML-AUTH then your metadata-URL would be: https://vpn.mydomain.com/saml/sp/metadata/VPN-SAML-AUTH. You know the URL is correct if you get something like the image below if you browse to the URL. You can also get this information via the CLI using the command show saml metadata <Connection Profile name> which in my case would be show saml metadata VPN-SAML-AUTH.
Make sure to tell the IdP-administrator that you want the SAML-attribute NameID included in the SAML-response from the IdP when it tells the ASA if an authentication attempt was successful or not. If you do seperate authorization (via ISE for example), this will be the username that is sent to the authorization server. The NameID will also be what you, in the ASA, will see at the username for a remote-access VPN-session.
Agree upon what Request Signature to use and (optionally) a Request Timeout. A tips is to start by setting no Request Timeout on the ASA’s side and just let the IdP deal with this however it wants to to see if it just works right out of the box.
Making changes to the SAML-configuration on the ASA could change your SAML-metadata and the IdP-administrator might need to change something on their side as well, so always ask the IdP-administrator to verify that they have the latest metadata from your ASA.
Debugging SAML-authentication attempts
Your first few attempts of connecting to the SAML VPN is probably gonna go bad and then I would recommend this debug command to see if there is anything wrong with the SAML-connection from your ASA (the SP) and the IdP.
Using the debug above you get to see the actual creation of SAML-requests being sent between the ASA and the IdP. The 255 at the end is the debug level, with 255 providing you with the most output.
In my experience, I have run into trouble where the IdP has been trying to send SAML-attributes to the ASA that the ASA is not able to interpret or understand which would show up in the debugging log as:
Here the SAML-attribute AuthnContextDeclRef is sent to the ASA from the IdP after authentication is successful, but the ASA does not know what this attribute is and therefore the VPN-authentication fails. If you run into this you pretty much have to ask your IdP administrator to make the IdP not send this attribute as there is no way to fix this on the ASA’s side due to the very limited SAML-configuration parameters of the ASA OS.
Another trouble you could run into is that the clock of the ASA and the IdP is not synchronized or that the timeout for the SAML-tickets/sessions are not in agreement between the ASA and the IdP. This could happen if you define a Request Timeout in the ASA configuration for the SAML-server and the ASA tries to override the timeout values set by the IdP. This is what you could see in the debug then:
Asa Debug Anyconnect Chrome
Drawbacks of using SAML
As of this writing (March 6th 2020) there is no easy way to apply different authorization rules for VPN users after they authenticate, like you would with Dynamic Access Policies (DAP) in ASA. The SAML-standard itself support many types of authorization parameters, but the ASA is unable to understand these. What you can do is let a separate authorization take place after the SAML-authentication, using either an LDAP-catalog or RADIUS-server, to get a second look at the user and then change authorization depending on group membership or account attributes, for example.
Good luck!
Introduction
This document describes how to configure Security Assertion Markup Language (SAML) with a focus on Adaptive Security Appliance (ASA) AnyConnect through Microsoft Azure MFA.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
- Basic knowledge of RA VPN configuration on ASA.
- Basic knowledge of SAML and Microsoft Azure.
- AnyConnect Licenses enabled (APEX or VPN-Only).
Components Used
The information in this document is based on these software and hardware versions:
- A Microsoft Azure AD subscription.
- Cisco ASA 9.7+ and Anyconnect 4.6+
- Working AnyConnect VPN profile
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Background Information
SAML is an XML-based framework for exchanging authentication and authorization data between security domains. It creates a circle of trust between the user, a Service Provider (SP), and an Identity Provider (IdP) which allows the user to sign in a single time for multiple services. Microsoft Azure MFA seamlessly integrates with Cisco ASA VPN appliance to provide additional security for the Cisco AnyConnect VPN logins.
SAML Components
Metadata: It is an XML based document that ensures a secure transaction between an IdP and an SP. It allows the IdP and SP to negotiate agreements.
Roles supported by the devices (IdP, SP)
A device may support more than one role and could contain values for both an SP and an IdP. Under the EntityDescriptor field is an IDPSSODescriptor if the information contained is for a Single Sign-On IdP or a SPSSODescriptor if the information contained is for a Single Sign-On SP. This is important since the correct values must be taken from the appropriate sections in order to set up SAML successfully.
Entity ID: This field is a unique identifier for an SP or an IdP. A single device might have several services and can use different Entity IDs to differentiate them. For example, ASA has different Entity IDs for different tunnel-groups that need to be authenticated. An IdP authenticating each tunnel-group has a separate Entity ID entries for each tunnel-group in order to accurately identify those services.
ASA can support multiple IdPs and has a separate entity ID for each IdP to differentiate them. If either side receives a message from a device that does not contain an entity ID that has been previously configured, the device likely drops this message, and SAML authentication fails. The Entity ID can be found within the EntityDescriptor field beside entityID.
Service URLs: These define the URL to a SAML service provided by the SP or IdP. For IdPs, this is most commonly the Single Logout Service and Single Sign-On Service. For SPs, this is commonly the Assertion Consumer Service and the Single Logout Service.
The Single Sign-On Service URL found in the IdP metadata is used by the SP to redirect the user to the IdP for authentication. If this value is incorrectly configured, the IdP does not receive or is unable to successfully process the Authentication request sent by the SP.
The Assertion Consumer Service URL found in the SP metadata is used by the IdP to redirect the user back to the SP and provide information about the user's authentication attempt. If this is configured incorrectly, the SP does not receive the assertion (the response) or is unable to successfully process it.
The Single Logout Service URL can be found on both the SP and the IdP. It is used to facilitate logging out of all SSO services from the SP and is optional on the ASA. When the SLO service URL from the IdP metadata is configured on the SP, when the user logs out of the service on the SP, the SP sends the request to the IdP. Once the IdP has successfully logged the user out of the services, it redirects the user back to the SP using the SLO service URL found within the SP’s metadata.
SAML Bindings for Service URLs: Bindings are the method the SP uses to uses to transfer information to the IdP and vice versa for services. This includes HTTP Redirect, HTTP POST, and Artifact. Each method has a different way of transferring data. The binding method supported by the service is included within the definition of that services. For example: SingleSignOnService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' Location='https://saml.example.com/simplesaml/saml2/idp/SSOService.php'/ >. The ASA does not support the Artifact binding. ASA always uses the HTTP Redirect method for SAML authentication requests, so it is important to choose the SSO Service URL that uses the HTTP Redirect binding so that the IdP expects this.
Certificates for Signature and Encryption Operations
To provide confidentiality and integrity for the messages sent between the SP and the IdP, SAML includes the ability to encrypt and sign the data. The certificate used to encrypt and/or sign the data can be included within the metadata so that the receiving end can verify the SAML message and ensure that it comes from the expected source. The certificates used for signing and encryption can be found within the metadata under KeyDescriptor use='signing' and KeyDescriptor use='encryption', respectfully, then X509Certificate. The ASA does not support encrypting SAML messages.
Network Diagram
Configure
Add Cisco AnyConnect from the Microsoft App Gallery
Step 1. Log in to Azure Portal and select Azure Active Directory.
Step 2. As shown in this image, select Enterprise Applications.
Step 3. Now select New Application, as shown in this image.
Step 4. In the Add from the gallery section, type AnyConnect in the search box, select Cisco AnyConnect from the results panel, and then add the app.
Step 5. Select the Single Sign-on menu item, as shown in this image.
Step 6. Select SAML, as shown in the image.
Step 7. Edit Section 1 with these details.
Step 8. In the SAML Signing Certificate section, select Download to download the certificate file and save it on your computer.
Step 9. Note this, it is required for ASA configuration.
- Azure AD Identifier - This is the saml idp in our VPN configuration.
- Login URL - This is the URL sign-in.
- Logout URL - This is the URL sign-out.
Assign Azure AD User to the App
In this section, Test1 is enabled to use Azure single sign-on, as you grant access to the Cisco AnyConnect app.
Step 1. In the app's overview page, select Users and groups and then Add user.
Step 2. Select Users and groups in the Add Assignment dialog.
Asa Debug Anyconnect User
Step 3. In the Add Assignment dialog, click the Assign button.
Configure ASA for SAML via CLI
Step 1. Create a Trustpoint and import our SAML cert.
Step 2. These commands provision your SAML IdP.
Step 3. Apply SAML Authentication to a VPN Tunnel Configuration.
Note: 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.
Verify
Test AnyConnect with SAML Auth
Step 1. Connect to your VPN URL and input your login Azure AD details.
Step 2. Approve sign-in request.
Step 3. AnyConnect is Connected.
Common Issues
Entity ID Mismatch
Debug Example:
[SAML] consume_assertion: The identifier of a provider is unknown to #LassoServer. In order to register a provider in a #LassoServer object, you must use the methods lasso_server_add_provider() or lasso_server_add_provider_from_buffer().
Problem: Generally means that saml idp [entityID] command under the ASA's webvpn configuration does not match the IdP Entity ID found in the IdP’s metadata.
Solution: Check the entity ID of the IdP’s metadata file and change the saml idp [entity id] command to match this.
Time Mismatch
Debug Example:
[SAML] NotBefore:2017-09-05T23:59:01.896Z NotOnOrAfter:2017-09-06T00:59:01.896Z timeout: 0
[SAML] consume_assertion: assertion is expired or not valid
Problem 1. ASA time not synced with IdP’s time.
Solution 1. Configure ASA with the same NTP server used by IdP.
Problem 2. The assertion is not valid between the specified time.
Solution 2. Modify the timeout value configured on the ASA.
Wrong IdP Signing Certificate Used
Debug Example:
[Lasso] func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=493:obj=rsa-sha1:subj=EVP_VerifyFinal:error=18:data do not match:signature do not match
[SAML] consume_assertion: The profile cannot verify a signature on the message
Problem: ASA not able to verify the message signed by the IdP or there is no signature for the ASA to verify.
Solution: Check the IdP signing certificate installed on the ASA to make sure it matches what is sent by the IdP. If this is confirmed, make sure that the signature is included in the SAML response.
Invalid Assertion Audience
Debug Example:
[SAML] consume_assertion: assertion audience is invalid
Problem: IdP is defining the incorrect audience.
Solution: Correct the Audience configuration on the IdP. It should match the ASA’s Entity ID.
Wrong URL for Assertion Consumer Service
Example Debug: Unable to receive any debugs after the initial authentication request is sent. The user is able to enter credentials at IdP but IdP does not redirect to ASA.
Problem: IdP is configured for the wrong Assertion Consumer Service URL.
Solution(s): Check base URL in configuration and make sure it is correct. Check ASA metadata with show to make sure that the Assertion Consumer Service URL is correct. In order to test it, browse it, If both are correct on the ASA, check the IdP to make sure that the URL is correct.
SAML Configuration Changes Not Taking Effect
Example: After a single sign-on URL is modified or changed, the SP certificate, SAML still does not work and sends previous configurations.
Problem: ASA needs to regenerate it's metadata when there is a configuration change that affects it. It does not do this automatically.
Solution: After making changes, under the affected tunnel-group remove and re-apply the saml idp [entity-id] command.
Troubleshoot
Most SAML troubleshoots involve a misconfiguration that can be found when the SAML configuration is checked or debugs are run. debug webvpn saml 255 can be used to troubleshoot most issues, however in scenarios where this debug does not provide useful information, additional debugs can be run:
Related Information