1. Yubico
  2. Phishing-resistant MFA
  3. Microsoft Entra ID (formerly Azure AD)

Protecting Cisco VPN connections in a Microsoft Environment with Yubico

Avatar
Daniel Bucy
Created - Updated

Cisco Adaptive Security Appliance (ASA) VPN deployments can take advantage of the strong authentication that YubiKey provides. There are many different approaches to implementing YubiKeys with Cisco VPN based on the ASA configuration.

 

This document outlines each approach and discusses each approach's advantages. This document focuses on a Microsoft Active Directory and Azure Active Directory centric implementation but the basic patterns can be applied to other vendor solutions.

 

To decide on the approach that’s right for you, you must consider the environment you are deploying to, and your requirements for phishing resistance:

 

  • Approaches 1 & 2 use a SAML integration with FIDO2, utilize phishing-resistant authentication that is compatible with our entire current product range: The Security Key series, the YubiKey 5 Series, and the YubiKey Bio.
  • Approach 3 utilizes an organization's existing PKI infrastructure to support phishing-resistant smart card (PIV) authentication with YubiKey 5 Series and YubiKey 4 Series devices, as well as legacy devices that support the PIV protocol.
  • Approach 4 uses a SAML integration with TOTP, and is only supported on the YubiKey 5 series and YubiKey 4 Series devices.
  • Approach 5 uses the Microsoft Network Policy Server (NPS) extensions and RADIUS to authenticate users via TOTP, and is only supported on the YubiKey 5 series and YubiKey 4 Series devices.

Approach 1: YubiKey FIDO2 with AnyConnect and AzureAD via SAML

This approach is based on the functionalities in Azure AD to provide FIDO2 authentication and to provide SAML based SSO with Cisco VPN. In this approach Azure AD acts as a SAML Identity Provider (IdP) and the Cisco VPN server ASA acts as a Service Provider (SP) which validates the SAML assertions created by Azure AD upon successful authentication of the user. As part of the authentication process Azure AD provides multi-factor authentication using the FIDO2 protocol with User Verification.

 

This approach can be used with both the AnyConnect client and Cisco’s clientless VPN flow (see Approach 2 below for the clientless scenario). A FIDO2 compliant browser (like Microsoft Edge 85+, Chrome 85+, Safari, or Firefox 81+) is required for this functionality to work.

 

The user opens the AnyConnect client and selects a VPN connection profile and clicks Connect. AnyConnect will launch the system default browser with a redirect to Azure AD to authenticate. The user is prompted to authenticate using the YubiKey as a FIDO2 security key, and is asked to enter the YubiKey PIN, and tap the YubiKey. Upon successful authentication in Azure AD and validation by the Cisco ASA, the VPN connection is established between the AnyConnect client and the Cisco ASA. Note that the VPN connection profile must be configured to use the default OS browser rather than the AnyConnect embedded browser in this scenario since the embedded browser does not support the FIDO2 protocol. The following diagram illustrates the components in this approach.

 

cisco-vpn.jpeg

 

The following diagram illustrates the SAML workflow in this approach.

 

cisco-vpn-2.jpeg

 

This approach has the following requirements:

 

  • Cisco ASA 9.17.1 and higher or FTD 7.1.0-90 and higher
  • AnyConnect Client 4.10.04065 and higher
  • AnyConnect external browser package for ASA or FTD
  • FIDO2 compliant browser (for example Microsoft Edge 85+ or Chrome 85+)
  • Configure SAML, with Azure AD as the IdP and Cisco ASA as the SP
  • Configure a Cisco Connection Profile for SAML and set the SAML Login Experience to “Default OS Browser.”
  • Enroll YubiKey for FIDO2 authentication in Azure AD

Approach 2: YubiKey FIDO2 with browser and AzureAD via SAML (Clientless)

This approach is based on the functionalities in Azure AD to provide FIDO2 authentication and to provide SAML based SSO with Cisco VPN. In this approach Azure AD acts as a SAML Identity Provider (IdP) and the Cisco VPN server ASA acts as a Service Provider (SP) which validates the SAML assertions created by Azure AD upon successful authentication of the user. As part of the authentication process Azure AD provides multi-factor authentication using the FIDO2 protocol with User Verification.

 

This approach uses Cisco’s clientless VPN flow. A FIDO2 compliant browser (like Microsoft Edge 85+, Chrome 85+, Safari, or Firefox 81+) is required for this functionality to work.

 

The user opens a browser window and navigates to the Cisco ASA portal, and is redirected to Azure AD to authenticate. The user is prompted to authenticate using the YubiKey as a FIDO2 security key, and is asked to enter the YubiKey PIN, and tap the YubiKey. Upon successful authentication, the browser is redirected to the Cisco ASA web portal and the VPN connection is established. The following diagram illustrates the components in this approach.

 

cisco-vpn-microsoft-yubico-i5.jpeg

 

The following diagram illustrates the SAML workflow in this approach.

 

cisco-vpn-3.jpeg

 

This approach has the following requirements:

 

  • Cisco ASA 9.7.1.24, 9.8.2.28, 9.9.2.1 or higher of each release train, or 9.10 and later
  • FIDO2 compliant browser (for example Microsoft Edge 85+ or Chrome 85+)
  • Configure SAML, with Azure AD as the IdP and Cisco ASA as the SP
  • Configure a Cisco Connection Profile for SAML
  • Enroll YubiKey for FIDO2 authentication in Azure AD

The user experience is different from the previous approaches in that the Cisco AnyConnect client is not used. Instead the user initiates the VPN connection using a browser. Another important difference is that this approach works with clientless VPN (also called WebVPN). It provides secure access to a broad range of web resources and both web-enabled and legacy applications from almost any device that can connect to the Internet via HTTP. Because of this, it provides different connection capabilities from the ones provided by the AnyConnect client. Advantages offered by this approach include not requiring the AnyConnect client, and the ease of use and strong authentication benefits provided by the FIDO2 authentication protocol.

 

Approach 3: YubiKey as a PIV smart card to authenticate to Cisco AnyConnect

This approach takes advantage of a company's PKI infrastructure to issue smartcards onto the YubiKey. Cisco AnyConnect natively supports smartcard integrations.

 

cisco-vpn-microsoft-yubico-i7.png

 

  1. The VPN server (Cisco VPN ASA) sends a request that is signed with the user's private key and also includes the certificate on the YubiKey.
  2. The ASA service first checks to see if the certificate has been revoked by checking with the Certificate Revocation List (CRL) service or the Online Certificate Status Protocol (OCSP) service. CRL checking is an optional setting within ASA and is disabled by default.
  3. If the certificate is not revoked, the certificate is validated within the ASA as the PKI certificate chain was imported during the initial configuration.
  4. If the certificate is validated, the user is granted access
  5. The ASA interfaces with Active Directory to get the appropriate permissions and grants access to the user.

The following diagram illustrates the smart card workflow in this approach.

 

cisco-vpn-microsoft-yubico-i8.png

 

This approach has the following requirements:

 

  • Cisco 5500 Series (ASA) that runs the software version 8.0(x) and later
  • AnyConnect client
  • A PKI environment such as Active Directory Certificate Services (ADCS) on Windows server 2012 or higher
  • Configure YubiKey for smart card (PIV) authentication

The user experience is different from the previous approaches due to the fact that a smart card flow is used. In this case, the user does not need to enter in a password but will be prompted to enter their smart card PIN to unlock the YubiKey PIV module. Leveraging YubiKeys as a smart card provides strong asymmetric authentication while eliminating the need for the user to type in a password or provide a separate 2nd factor authentication step. Smart cards inherently provide multifactor authentication by requiring a physical device as the first factor and the PIN as the second.

 

Approach 4: YubiKey TOTP with Cisco AnyConnect and Azure AD via SAML

This approach is based on the capabilities in Cisco ASA and the AnyConnect client to leverage Azure AD’s SAML SSO functionality. In this approach Azure AD acts as a SAML Identity Provided (IdP) and the Cisco ASA server acts as a Service Provider (SP) which validates the SAML assertions created by Azure AD upon successful authentication of the user. As part of the authentication process Azure AD provides multifactor authentication using the OATH TOTP protocol. The YubiKey can serve as an OATH TOTP hardware token and is used in conjunction with the Yubico Authenticator to generate TOTP codes.

 

This approach is similar to the one described in the previous section, but instead of using RADIUS it uses SAML. The Cisco AnyConnect client (version 4.6 and newer) works with an embedded browser that is directed to the ASA (defined in the VPN connection profile). The request is redirected to Azure AD (the identity provider) which prompts for authentication, including multi-factor authentication with OATH TOTP. The user opens Yubico Authenticator, plugs in the YubiKey and copies the generated TOTP code to the authentication prompt in AnyConnect. Azure AD validates the TOTP code and sends a SAML assertion to the ASA that then validates the SAML request. At this point, the VPN connection is established. The following diagram illustrates the components in this approach.

 

cisco-vpn-microsoft-yubico-i3.jpeg

 

  1. The VPN server (Cisco VPN ASA) receives an authentication request from a VPN user that includes a SAML based authentication requirement.
  2. If the user does not have a valid SAML token, the AnyConnect embedded browser redirects the user to authenticate against Azure.
  3. The username and password combination is verified in Azure.
  4. The user performs secondary authentication using the YubiKey and the Yubico Authenticator. When the MFA challenge is successful, a SAML access token is generated.
  5. The browser redirects back to the Cisco VPN ASA
  6. The Cisco VPN ASA validates the sample token
  7. The ASA interfaces with Active Directory to get the appropriate permissions and grants access to the user.

The following sequence diagram illustrates the SAML workflow in this approach.

 

cisc-vpn-microsoft-yubico-i4.jpeg

 

This approach has the following requirements:

 

  • Cisco ASA 9.7.1.24, 9.8.2.28, 9.9.2.1 or higher of each release train, or 9.10 and later
  • AnyConnect client 4.6 or higher (provides embedded browser)
  • Configure SAML, with Azure AD as the IdP and Cisco ASA as the SP
  • Configure a Cisco Connection Profile for SAML
  • Configure OATH TOTP for authentication in Azure AD
  • YubiKey and Yubico Authenticator installed in the client computer

The user experience is similar to the one in the previous approach. It provides the same advantage as the previous approach, as the secret used to generate the TOTP codes is safely stored in the YubiKey and is never exposed. The main difference in this approach uses SAML instead of RADIUS.

 

Approach 5: YubiKey TOTP with Azure AD and NPS Extension

A common approach to provide multifactor authentication (MFA) is to use OATH Time-based One Time Passcodes (TOTP) as a second factor. Leveraging the Remote Authentication Dial-In User Service (RADIUS) protocol, Identity Providers (IDPs) interface with Cisco’s ASA to validate TOTP codes. For Microsoft’s RADIUS implementation, the Network Policy Server (NPS) extension for Azure allows organizations to safeguard client authentication using cloud-based Azure Multi-Factor Authentication (MFA). In this approach, YubiKeys are deployed in Azure MFA as an OATH Token. The YubiKey, along with the Yubico Authenticator companion application, generates the OATH-TOTP passcode, which is presented to the MFA prompt within Cisco AnyConnect.

 

This approach requires installing Microsoft NPS Server along with the NPS Extension for Azure. NPS provides the RADIUS service which will be used by the RADIUS client on ASA. Additionally the Yubico Authenticator and the Cisco AnyConnect client needs to be installed on the client computers. The Yubico Authenticator is used to generate TOTP codes based on the secret that is securely stored in the YubiKey. Technically, the Yubico Authenticator does not need to be on the same device as the AnyConnect client. It can reside on another computer or a mobile device. However, having the Yubico Authenticator on the same computer does allow the user to easily copy and paste the TOTP code rather than having to manually type in the code.

 

To authenticate, the user needs to open Yubico Authenticator, insert the YubiKey and then copy, or type in, the TOTP code in the VPN login prompt. The overall experience is similar to other TOTP solutions, with the advantage that the TOTP secret is never exposed, as it remains safely stored in the YubiKey. Additionally, since the TOTP secret is stored in the YubiKey, the Yubico Authenticator can be loaded on many different devices to receive the code. This eliminates the problem of having TOTP codes in an authenticator app that are bound to a particular device. Another advantage is that management of user authentication is consolidated in Azure AD.

 

When the NPS extension for Azure is integrated with the NPS server, a successful authentication flow is as follows:

 

cisco-vpn-microsoft-cisco-i1.png

 

  1. The VPN server (Cisco VPN ASA) receives an authentication request from a VPN user that includes the username and password for connecting to a resource.
  2. Acting as a RADIUS client, the VPN server converts the request to a RADIUS Access-Request message and sends it (with an encrypted password) to the RADIUS server where the NPS extension is installed.
  3. The username and password combination is verified in Active Directory. If either the username or password is incorrect, the RADIUS Server sends an Access-Reject message.
  4. If all conditions, as specified in the NPS Connection Request and Network Policies, are met (for example, time of day or group membership restrictions), the NPS extension triggers a request for secondary authentication with Azure Multi-Factor Authentication. Azure AD Connect communicates with Azure Active Directory, retrieves the user's details, and triggers the request for secondary authentication by using the method that's configured by the user in Azure MFA.
  5. The request for secondary authentication is sent back to the RADIUS client (the VPN server in this case)
  6. The request for secondary authentication is presented to the user (RADIUS challenge)
    1. It is important to ensure the PAP authentication method, over a secure channel, is enabled to allow for hardware tokens to be supported.
  7. The user performs secondary authentication using the YubiKey and the Yubico Authenticator. When the MFA challenge is successful, Azure MFA communicates the result to the NPS extension, which in turn results in the VPN session being established.

The following sequence diagram illustrates the RADIUS workflow in this approach.

 

cisco-vpn-microsoft-yubico-i2.png

 

Yubico provides many ways to secure a company's Cisco VPN environment. The approaches mentioned above are focused on a Microsoft environment but the same patterns apply to other identity provider and VPN solutions. If you have specific questions about how to protect your environment, please contact us and we will be happy to assist you in finding the solution that meets your needs.