Anyconnect Ad Authentication

Two-factor authentication, or multifactor authentication, for VPN-access has been around for a long time to ensure only trusted devices, personal and consultants are able to access the corporate network from the outside. With the rise of smartphones in the past 10 years, there are now several authentication engines that leverage Push Notifications with simple Permit or Deny buttons that can be used to perform two-factor authentication without having the user to deal with One-Time Passwords (OTP) via SMS or code-generating apps.

If you are using SAML authentication with AnyConnect 4.4 or 4.5 and you deploy ASA version 9.7.1.24, 9.8.2.28, or 9.9.2.1 (Release Date: 18-APR-2018), the defaulted SAML behavior is the embedded browser, which is not supported on AnyConnect 4.4 and 4.5. 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. Download this app from Microsoft Store for Windows 10, Windows 10 Mobile, Windows 10 Team (Surface Hub), HoloLens, Xbox One. See screenshots, read the latest customer reviews, and compare ratings for AnyConnect. Any integration with Azure AD would be done via SAML IdP and ISE does not currently support using a SAML IdP for endpoint authentication. SAML IdP is only supported for authentication of the following portals: Guest portal (sponsored and self-registered).

Writer’s Update September 23rd 2020 - starting with AnyConnect 4.8.02045 - the default authentication timeout has been increased from 12 seconds to 30 seconds as per TAC information and documented in TAC-case CSCve01989

The Setup

This is the set of devices and services relevant to the point of this article:

The Problem

The first time I was tasked with implementing two-factor authentication using a Push Notification smartphone app I pretty quickly discovered that there was something wrong in my setup. I had an Cisco ASA-firewall (which users connect to over the internet) talking to a RADIUS-server which did lookups in an Active Directory using LDAP to validate users’ credentials. The RADIUS-server also issued Push Notifications to users’ smartphones. The idea was that users first must login using Active Directory credentials (username and password) and if those are correct then the RADIUS-server would send a Push Notification to the user’s smartphone, asking them to authenticate the session by pressing “Permit” on their smartphone app.

Sure thing I did get a push notification… and then another one… and another one. Before I even had the chance to “permit” the first Push Notification, I had already received another two of them.

It didn’t take to long to figure out that something was triggering multiple Push Notifications but nailing down where they came wrong wasn’t too obvious. Naturally I started working my way through the ASA and trying different Timeouts and Retry timers for my RADIUS-server and my RADIUS Group configuration. No matter how much I tinkered with this I was still getting sent too many Push Notifications sent to my smartphone every time I tried to logging into the VPN.

Following the stream of packets

Next up, I fired up the Packet Capture tool in ASDM and caught the packets which would tell the truth of what was going on. You can see below what the packet capture looked like when opened in Wireshark.

Frame #1 is the result of me pressing Enter after I have entered my credentials in the AnyConnect VPN-client software. The ASA sends a RADIUS-request packet to the RADIUS-server with my credentials in it. Frame #2 shows the ASA doing a Retry of this request after 10 seconds has past. This is because the Retry timeout of the RADIUS-server is configured to 10 seconds in ASA, which is the maximum number of seconds for Retry. It can only be configured for less, not more.

But then something else enters the flow of packets: another new RADIUS session. After approximately 12 seconds, another RADIUS-Request packet is sent from the ASA towards the RADIUS-server and it is using a different session-ID compared to the first RADIUS-sessions started in frame #1.

Another 8 seconds pass (for a total of 20 seconds since frame#1) and the ASA can be seen doing another Retry inside the first RADIUS-session.

At 22 seconds we see the ASA doing a Retry of the second RADIUS-session (12 + 10 seconds).

We see another 2 seconds pass and when the clock hits 24 seconds a third RADIUS session has appeared before us.

What is happening

Doing similar captures over and over again while changing timers on the ASA between every attempt, I could quickly narrow down that there was an interval of 12 seconds that kept showing up and creating new RADIUS sessions while others were still in progress. Throwing together “ASA VPN” and “12 seconds” on your favorite search engine will probably earn you the answer and that is that Cisco’s AnyConnect VPN-client software has an authentication timeout of 12 seconds (by default). That means that every 12 seconds, AnyConnect will re-send your credentials to the ASA, which in turn will send them to the RADIUS-server, creating a whole new RADIUS session. If you fire up the VPN Profile Editor you can see this default value at the bottom of the Preferences (Part 2) window:

Effectively, the user will only have 12 seconds on them to unlock their smartphone, launch the app and press “Permit” inside the app. Some two-factor authentication apps ever have passwords of their own, making it ever harder for users to keep up.

The Solution

So, how do we increase the 12 seconds authentication timeout of AnyConnect? For corporate computer managed by your organization, you can simply create a AnyConnect VPN Profile using the VPN Profile Editor. In my case I increased the Authentication Timeout to 120 seconds (which is the maximum value you can set according to the documentation) and after that I had no trouble releasing this solution into the production network.

An important note is that changing the authentication timeout doesn’t take effect unless you configure it together with a pre-defined VPN-server (the FQDN/DNS-name of the ASA VPN service). Please note that is has to be a FQDN that is defined in the VPN Profile, simply pre-filling the IP-address of the outside interface of your ASA will not work!! This is a very odd and specific configuration that I assume is a bug that has been along for the ride for a long time based on what I’ve been reading online.

This solutions isn’t all great though because VPN-solutions are often used to grant access to consultants outside of your organization and usually you don’t have control of their computer. What you can do is create a VPN Profile directly in your ASA and assign it to the Group Policy that is to be used by consultants but the issue here is that the profile is not downloaded and activated until the consultant has performed a successful authentication first. This means the first login is gonna be a bit tough and short on time but once they get through it they will be able to download the VPN profile which increases the AnyConnect authentication timeout to whatever value your set it to in the profile (preferably 60 seconds or more).

How are One-Time Passwords solutions different?

Many of these two-factor authentication apps are also capable of generating One-Time Passwords inside the app instead of relying on Push Notifications. There are also solutions that use SMS to send out the OTP-code to users. The OTP-code is then entered into AnyConnect by the user after they have completed their first authentication (which validates their credentials towards an LDAP or AD-server).

To demonstrate this I have setup another AAA-server that is only using OTP-SMS to perform 2FA-authentication. The setup is as follows:

And when 2FA takes place using OTP-SMS instead of push notifications, the packet capture looks like this:

The big difference here is that the ASA receives a RADIUS Challenge packet from the RADIUS-server after the user’s credentials have been verified. This packets makes the ASA tells AnyConnect that an additional piece of authentication needs to take place. Because of this, AnyConnect will know it has to wait for the user to input the OTP-code and as a result will not re-send user credentials every 12 seconds.

Final words

What Is Ad Authentication

Browsing the Cisco Support forums you can find quite a few discussions about how to deal with these kinds of 2FA/MFA solutions where timeouts are a pain in the butt and I thought it was worth taking a deep dive into the issue at hand and going through the steps of what is actually happening. Cisco has sort of acknowledged the weird issue with the Authentication Timeout in AnyConnect requiring an FQDN being present in the configuration, through the Knowledge Base article of their own 2FA/MFA product called Duo. You can see Duo’s statement on this issue on this link https://help.duo.com/s/article/1146?language=en_US