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
The file can be found inside the following packages: anyconnect-dart-win-x.x.xxxx-k9.msi Windows anyconnect-macosx-i386-x.x.xxxxx-k9.dmg MAC anyconnect-predeploy-linux-64-x.x.xxxxx-k9.tar.gz Linux. Or can be dynamically deployed to the user, configuring the module under the group -policy. Example: ASA(config)#Group-policy ABC. 110.1.1.2 is an outside interface of Cisco ASA firewall, as shown below. This client that is in a different network (140.1.1.0/24) tries to connect to it. In conclusion, as seen above, a remote client can connect to Local network using Cisco Anyconnect VPN application.
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.
![Cisco Cisco](/uploads/1/3/7/6/137626846/229638179.png)
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.
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
Ietoedge bho add on from microsoft. [SAML] consume_assertion: The profile cannot verify a signature on the message
Problem: Ie edge chrome. 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. Remote desktop manager windows 10. 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
See the previous blog post which documents the steps to setup AnyConnect SSL-VPN and ISE integration. This blog post expands on the AnyConnect SSL-VPN configuration, adding support for IKEv2/IPSec and using double authentication (Username/Password and Certificate).
ASA Configuration
Create a Crypto Keypair
Create a CA Trustpoint
Authenticate the Trustpoint
In this example the ASA will enrol with a Windows Certificate Authority.
- Open the CA’s Trusted Root certificate in notepad
- Copy the contents on the certificate
- On the ASA run the command crypto ca authenticate LAB_PKI
- When prompted paste the contents of the CA Trusted Root certificate
- Type quit at the end
- Enter yes to import the certificate
EnrolL ASA for Identity Certificate
The ASA will create a CSR, which will need to be signed by the Windows CA and the signed certificate imported.
Asa Cisco Anyconnect Download
- On the ASA run the command crypto ca enroll LAB_PKI
- When prompted copy the contents of the CSR
- Complete the Certificate Signing Request
- On the Window CA open the Web page to sign certificates, click Request a certificate
- Click advanced certificate request
- Paste the CSR generated on the ASA in the previous step above
- Select the Certificate Template Web Server
- Click Submit
- Select Base 64 encoded
- Click Download certificate, save the file to a file for use in the next step
- On the ASA, run the command crypto ca import LAB_PKI certificate. LAB_PKI equals the name of the trustpoint previously defined.
- When prompted paste the contents of the saved file (generated in the previous step)
- Type quit at the end
- Verify the Identity and Trusted Root Certificates imported successfully by running the command show crypto ca certificates
- In the screenshot below the first certificate is the Identity Certificate (note the Subject name of the ASA). The second certificate is the Trusted Root certificate (note the subject name = lab=PKI-CA).
Enable the Certificate Trustpoint on the OUTSIDE interface
Enable the Certificate Trustpoint for Remote Access
Define IKEv2 Policy
Define IPSec Transform Sets
Define Crypto Map
Reference the previously created IPSec Transform Sets. Enable Crypto Map on OUTSIDE interface
Modify Group Policy to enable IKEv2
Enable AAA and Certificate authentication
For additional security double authentication will be configured to require certificate and username/password. The certificate will be authenticated against the ASA, the UN/PW will be authenticated against the RADIUS server (defined in the previous post).
Enable AAA accounting (if not already enabled)
AAA accounting should be enabled to keep track of the connections.
ISE Configuration
The ISE Authorization Policy as defined in the previous post needs modifying to add a new rule for clients connecting with IPSec. Using this attribute is optional, but can be used to distinguish between different connections types if required.
- Create a new Authorization rule called AnyConnect IPSec VPN
- Define Conditions: Cisco-VPN3000:CVPN3000/ASA/PIX7x-Tunnel-Group-Name CONTAINS TG-1 AND Cisco-VPN3000:CVPN3000/ASA/PIX7x-Client-Type EQUALS AnyConnect-Client-IPSec-VPN
- Permissions: VPN_Permit_DACL
Testing & Verification
You will need to create a AnyConnect Profile, download the AnyConnect Profile Editor
- Open the VPN Profile Editor
- Navigate to the Server List and click Add
- Define a display name for the connection e.g ASA IKEv2/IPSec VPN
- Define the FQDN
- Define the User Group, this represents the Tunnel-Group on the ASA, in this instance the name is TG-1 (as defined in the previous post)
- Set the Primary Protocol to IPSec
- Click Save and ensure the file is saved to the folder location:
- C:ProgramDataCiscoCisco AnyConnect Secure Mobility ClientProfile
- C:ProgramDataCiscoCisco AnyConnect Secure Mobility ClientProfile
- Restart the Cisco AnyConnect services or reboot
- Open the Cisco AnyConnect Secure Mobility Client, this should display the new connection
Cisco Asa Anyconnect Certificate Authentication
The Windows computer has a User and Computer certificate issued by the same Windows CA that signed the certificate in use on the ASA, and therefore they should mutually trust each other and successfully authenticate.
- On the ASA run the command debug aaa authentication
- On the PC connect to the VPN and enter and username/password when prompted. Certificate authentication, if successful should be transparent
From the ASA debugs you can see the certificate authentication was successful
Authentication using Username/Password was also successful. You can see from the debug output aaa authentication was successful, a DACL was downloaded, aaa accounting was successful and the client was successfully assigned an IP address from the local pool.
- On the ASA run the command show vpn-session detail anyconnect
You will be able to confirm the Username, Assigned IP address, IKEv2 encryption algorithm used, authentication method, group-policy and tunnel-group etc.