Implementing Cloud Azure MFA for ASA VPN and Cisco AnyConnect

Why do we need to protect Cisco VPN?

Typically Cisco VPN client uses user ID and password to connect to corporate network. This is very insecure way of connecting, in order make the connectivity more secure we need to include second factor authentication method.

In this blog post we are showing you how to implement a multifactor authentication using Azure AD MFA.

What is MFA Authentication?

Multi-factor authentication is an authentication method in which a user is granted access to a network, website or application only after successfully presenting two or more pieces of evidence to an authentication mechanism (via UI, Web or Mobile Phone).

Typical corporate network scenario.

Azure MFA

Typically for a VPN setup companies will have a Cisco AnyConnect Client, ASA firewall and a RADIUS server. Customer use RADIUS for authenticating to access VPN network services, remote desktop to servers, or for managing network equipment, such as routers and switches

When organizations want to have more than just username and password they can use Azure MFA as an additional layer of security.  Customers can add an additional layer of security to the RADIUS scenarios by using Azure MFA extensions for the Windows Network Policy Server, also known as NPS. Since users can have different types of authentication methods, such as push notifications, phone calls or time based one-time passcodes, Azure MFA can be used to invoke the MFA challenge as part of the authentication flow.

Azure MFA

In the above illustration, we have a typical scenario where a customer has deployed their VPN network access services using RADIUS. And they have decided they want to provide additional security by using the Azure MFA feature of Azure Active Directory.

In this scenario, the user is wanting to connect to the corporate network via VPN. The user opens the VPN client, is presented with a dialog box requesting the user to enter their username and credential. Now that the user has provided their username and password to the VPN client to the VPN service, the VPN server now presents that credential pair to the NPS server as a RADIUS request to authenticate the user. And it waits for a response to determine if the user is authenticated to access the service or not.

The NPS server now uses the credentials in that request to validate the password against Active Directory. And if that is successful, it will then invoke MFA for the user.

To use MFA there are two steps to the authentication process for the user.  The primary authentication using NPS is against the on-premises Active Directory. And then once authenticated, the secondary step is to invoke the MFA challenge using the Azure MFA service before returning the response to the VPN server.

When the NPS server administrator installed the Azure MFA NPS extension on the server, the process registered itself in the associated Azure Active Directory, which issued a certificate identifying the specific instance. When the Azure MFA extension goes to invoke Azure MFA, it authenticates to Azure Active Directory using that certificate to authenticate and open a secure connection to send a request to invoke the default MFA authentication for that user.

The user has registered for Azure MFA. And if they have more than one authentication method, they can set one of them as their default method. In this scenario, the user has set their default method to one of the notification methods, such as Microsoft Authenticator or phone calls. So, when the Azure MFA service goes to invoke the MFA request from the NPS extensions, it looks up the user’s MFA details and invokes the MFA challenge using that method.

What happens when the user’s default method is a push notification or a phone call? How does the user receive the request?

The Azure MFA service interacts with the infrastructure, such as initiating a push notification to the user’s registered Microsoft Authenticator device or dialing the phone number that they have registered to receive the phone call. The user who receives the request can either choose to approve or deny the request, which sends that response back to the Azure MFA service. The Azure MFA service provides this response back to the NPS extension on the NPS server.

Now that the NPS has an authentication response, it will now pass the RADIUS response back to the VPN server. If the response was an accept, then the VPN server would complete the connection and respond back to the VPN client that they are now connected. Also, if they received a reject, MFA access would not be granted.

Since users may have other authentication methods set as their default, such as an OTP or one-time passcode, here is the differences in the authentication flow.

When the user’s method is a time based one-time passcode or TOTP, such as the verification code generated in the Microsoft Authenticator mobile application, it requires the user to provide that code as a response.

When using web browser scenarios, we can ask them to enter the code into the browser, but how does that work with RADIUS scenarios?

When the user’s default method is a TOTP verification code, We first do the primary authentication using their username and password credentials entered into the VPN client. But when we invoke the MFA service, it looks up the MFA details. And now, it responds with a session ID and challenge message and the request for an access challenge is sent back to the NPS server extension. The NPS server responds back to the VPN server with an access challenge with that session ID or the state and the challenge message, which passes this on back to the VPN client.

If the VPN client supports presenting a dialog box to ask the user for the access challenge by presenting the message and asking the user for the TOTP code in this scenario. It is important to know that not all RADIUS clients support asking for an access challenge, so it’s important to verify that it is supported with a network service using RADIUS.

So, the user would get the TOTP verification code from the Microsoft Authenticator application and enter it into the VPN client?

Yes. Then the VPN client responds to the VPN server with the enter TOTP code and the session ID as a RADIUS request to the NPS server. The NPS extension authenticates itself and it validates the TOTP and session ID with the Azure MFA service and returns the RADIUS response back to the VPN server as either an accept or reject.

The VPN server receives the response from the NPS server and provides this response back to the VPN client. The final response is returned to the VPN client and, if successful, the VPN connection could be established. Many network services also support modern authentication through more modern protocols like SAML or OAuth today, in the scenario above, RADIUS would not be considered modern authentication, since we are providing our credentials directly to the VPN application instead of Active Directory itself. This is another scenario where having MFA in addition to a username and password is a good idea.

Who can Implement a selected MFA for an organization? Is it easy for an internal IT administrator to implement an MFA for Cisco any Connect VPN Client?

Yes, and No. It is possible for an IT administrator diligently go through the steps and have the MFA implemented. Since there are many components, configurations, AD/Azure-AD sync, certificates, etc. it is recommended to use a security service provider like Sennovate to implement the solution seamlessly and methodically. Assume if you have a 500 employees using VPN in your organization, one hour of outage will cause 500 hours productivity wasted.