ASA Remote Access VPN with Microsoft Azure as a SAML 2.0 Provider -

In this article, we’re going to go through the process of integrating Microsoft Azure Active Directory with the Cisco ASA to authenticate remote access VPN users.

You will be required to have administrative access to the Microsoft Azure tenant as well as the ASA.

Demonstration Devices/Software

ASA (9.17 (1) 7)
ASDM (7.17(1))
AnyConnect (4.9)
MacOS (Test Device)

Prerequisites

Public signed certificate for ASA VPN
Admin access to your Azure tenant
Admin access to ASA
DNS Record for ASA FQDN

Set up a new Azure Enterprise Application

With access to your Azure tenant, navigate to Enterprise Applications and click ‘New application’

In the search bar, type ‘Anyconnect’ and you should be presented with the Cisco AnyConnect client. Click on the application, optionally change the name to something more meaningful and press ‘create’

Assign Users and Groups

Now that the application has been created, the first thing we need to do is assign users and groups that will be authenticating to the ASA using AnyConnect. Select ‘Assign users and groups’ and assign the relevant users/groups to the newly created application. One user has been selected for this demonstration as shown below. Once you’ve selected your users/groups, press ‘Assign’ to continue.

Set up Single Sign On

The next step we need to complete is the setup of Single Sign On for the newly created application. You can now either select ‘Single sign-on’ from the left-hand pane in Azure or head back over to ‘Overview’ and select ‘Set up single sign on’ as shown below.

Now select ‘SAML’ as the single sign-on method.

Starting with step 1 as shown in the screenshot below, click ‘edit’.

We now need to populate two fields; the Entity ID and the Reply URL with the ASA’s FQDN and Tunnel Group that will be used with this application. Examples are provided on Azure underneath each field and I have also included an example below of what is used for this demonstration.

Demonstration FQDN: asaazuredemo.networkwizkid.com

Tunnel Group (Connection Profile): AzureSAML

Example Entity ID: https://asaazuredemo.networkwizkid.com/saml/sp/metadata/AzureSAML

Example Reply URL: https://asaazuredemo.networkwizkid.com/+CSCOE+/SAML/SP/ACS?tgname=AzureSAML

Once you’ve completed that section you can go ahead and press ‘Save’.

Now, unless you want to modify the attributes in step 2, continue to Step 3 and download the SAML Signing Certificate. This will be uploaded to the ASA.

Keep the Azure single sign-on screen available as we will need to copy some more fields from this a little later on in the demonstration but for now, access your ASA. In this demonstration, we will use ASDM to demonstrate the configuration of SAML for remote access VPN users.

Configure the ASA

With access to ASDM (or CLI) upload the certificate to the ASA that we just downloaded from Azure. In this demonstration, we will use the CLI to upload the certificate so that we can issue the following command no ca-check.

Note: After you’ve entered the certificate, you will need to press enter and type ‘quit’ on a separate line in order to finish off adding the certificate.

      crypto ca trustpoint Azure-SAML
        revocation-check none
        no id-usage
        enrollment terminal
        no ca-check
      crypto ca authenticate Azure-SAML
        <add you certificate here>
quit

You can now access ASDM and validate that the certificate has been uploaded by navigating to Remote Access VPN > Certificate Management > CA Certificates.

Configure a VPN Connection Profile

Note: Additional VPN settings are not covered in this demonstration.

This demonstration assumes that a new connection profile will be created for authentication with Azure. In ASDM navigate to Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles. Create a new profile ensuring that the authentication method is set to SAML and the SAML Identity Provider information is populated from your Azure tenant.

You also have to decide whether you wish to use the embedded VPN browser for SAML authentication or the default OS browser. If you choose to use the default OS browser, you will need to download the AnyConnect external browser package and upload that file to your ASA. This demonstration uses the default OS browser but the configuration steps are beyond the scope of this demonstration.

The following Azure URLs need to be mapped to the AnyConnect Connection Profile:

Azure: Azure AD Identifier > ASA: IDP Entity ID
Azure: Login URL > ASA: Sign In URL
Azure: Logout URL > ASA: Sign Out URL
ASA: Base URL (example: asaazuredemo.networkwizkid.com)

An example is provided below.

Testing

Now that we have the necessary configuration in place, we will test and validate that everything works as expected by using a separate test PC with AnyConnect installed.

Access AnyConnect Client

With access to your AnyConnect client, enter the ASA’s FQDN/IP address and press ‘Connect’.

You should have been redirected to Microsoft to log in as shown in the screenshot below. Log in with authorised user credentials.

Once successfully logged in, you will be redirected and notified that you’ve successfully authenticated. You can close the browser and return to the AnyConnect where you’ll be able to see a successfully established VPN.

When a user disconnects from the VPN, another screen will be presented to notify them that they’ve successfully logged out.

Administrators can also validate authentication attempts in their Azure tenant by navigating to Activity > Sign-in Logs under the application. Below is a screenshot of the type of information you can see from these logs.

Observations

While initially testing, I ran into a certificate issue whereby the ASA would present me with a CSRF attack attempt when trying to authenticate. The issue is documented here. It seems that when initially configuring the application within Azure, the certificate presented is not the correct one and so in order to rectify this issue, I re-downloaded the certificate at a later time which was then different as shown in the screenshots below. Once the correct certificate was downloaded, I updated the certificates on the ASA and then everything worked as expected. The main difference is the certificate issuer as shown below.