Finally I had a chance to configured Radius_Challenge feature with Cisco Anyconnect (AC) and of course, it did not go as smoothly as I would expect it. Why would you need this option? For example, you have a user without a smartphone, or smartphone version is no longer supported by DUO app to provide the push. Another good reason will be Activated but never Authenticated users. Those who received enrollment email but never got to enroll and now if they try to login they will get nothing unless we enable Radius-Challenge.
So here is the way I got it configured and working.
You can check my previous post regarding the initial setup. To move forward with Radius-Challenge I had to modify DUO Proxy server configuration file. You simply copy [radius_server_auto] section, comment it out so it does not conflict and paste contents of it into [radius_server_challenge] section. Learn more about other options here.
; Your Duo integration key
; Your Duo secret key
; Your Duo API hostname (e.g. “api-XXXX.duosecurity.com”)
Challenge prompt is controlled with the following command. Prompt text cannot be modified and has 3 options that make it look as below:
Option “short” provides minimum characters. You can select number 1 or type push1 to proceed.
This option does not really play nice with AC so I skipped it without further testing.
This option seemed to be the most appropriate for me. It indicates to the user to type 1 and has a phone number displayed where the 2nd factor is going to contact.
The Answer field can also be used to enter DUO 6 digit pass-code displayed on DUO app. This is useful when you have no phone service, for example on the plane.
WebVPN version is below.
Once DUO configuration file is updated do not forget to restart the service.
Now we need to tweak AC XML profile. With push only option, I did not have any issues with timeouts but once I’ve introduced SMS and phone call options which took longer time for the users to respond I’ve noticed this error message on AC “Invalid authentication handle”.
This error popped up right around 12 sec after username/password authentication. Looking at AC XML profile on ASA there is authentication time out section that controls this value. We should set this value to 60 sec to give users enough time to respond.
Now, the tricky part is to make this profile work. If you make a change and it is not reflected on your device after you successfully VPN in then you may have to recreate it from scratch on ASA. It is better to create it manually rather than importing it in as a file.
Another requirement is to use FQDN name (not IP) on Primary Server list as described in this DUO article.
Also, let’s say you have asa2.company.com as a backup VPN head-end. You’ve applied the same profile from asa1 thinking since this is a backup I should duplicate all the settings. But when you connect to your asa2.company.com and download XML profile you will find out that it is not working. In order to fix it your XML profile Primary Server FQDN entry on asa2 HAS to match asa2 FQDN. So you would login to asa2 and make Primary Server FQDN field – asa2.company.com
After you’ve performed above configuration steps you should see a much longer timeout delay on Radius-Challenge screen which will give your users enough time to respond.