Anyconnect with Radius (Multifactor)

[YoinkZ]

Hi,

I'm stuck and I don't know if my configuration is wrong or if this is just a limitation of how the interaction between Radius/Meraki/Anyconnect works at the moment.

Currently I have my old Cisco ASA5500 series Firewall set up, with Anyconnect using DAP profiles and Multifactor Authentication (Entrust) running on a Radius server. It works perfect and is easy to use.

But my Firewalls are getting old and we have decided to move on and have chosen the Meraki as our new platform.

So far so good. I got Anyconnect up and running with my Radius server, and I can filter the logins with which group a user is a member of (from the AD) and then throw that back to the Meraki, so I make sure the right "Group Policy" is deployed (almost like DAP).

The problem start, when I introduce my "Entrust" solution, which is our Multifactor, running as a piece of software on the Radius server. The setup is exactly the same as when it runs with the ASA, but when I try to log in, the authentication prompt tells me "Login failed." after I have typed in my user credentials. But what really happens behind the scene is, the username and password was validated successful and now the Anyconnect client waits for the "Challenge/Response". If I then type in the OTP received (Text message), Anyconnect will tell me that "You have successfully connected to client VPN".

To me it looks like the Anyconnect and Meraki are having some issues doing the "Challenge/Response" part, which works fine on the ASA. Same configuration on the NPS more or less.

I've been in contact with Entrust, which ran through the logs and everything seems to be right on their end. It sees the Radius authentication, it then fires the Challenge/Response where I receive the text message and finally it accepts the response and verification is successful.

Do any of you have some similar setup, or perhaps know if this is a limitation of how Anyconnect is working on Meraki as if now?

Thank you.

[alemabrahao]

Take a look at this:  https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance/Authentication

[YoinkZ]

Yes, but looking at the integration it looks like this is being done in the Cloud and the integration with my Radius servers and policies will then no longer be in place?

But, if I move ahead with the SAML integration, how do I then get the SAML displayed on my MX?
I can only under "Anyconnect" see the following authentication types: RADIUS, Meraki Cloud Authentication and Active Directory". 

My appliance is running:

FIRMWARE

Up to date

Current version: MX 17.10.4

Do I miss something in the steps somewhere?

[alemabrahao]

As far as I know you need to ask Meraki support to enable it for you:

[rhbirkelund]

Have you set the RADIUS Timeout on the Anyconnect Page to something different than the default 3 seconds? Perhaps set it to 60 seconds?

[YoinkZ]

Hey,

Yes I have tried with 30 seconds and also 60 seconds, but no difference. I'm sure it must be me doing something wrong, but I just can't figure out what it is, neither could the Entrust technician 🙂

[rhbirkelund]

I can't say how it is with Entrust, but I've just got it working with Okta and their RADIUS Agent.

[YoinkZ]

But is OKTA also able to use RSA Tokens / SMS Tokens / Grid Cards and so on?

[rhbirkelund]

Okta can use SMS passcodes, Push Notification Apps etc, as well as a range of third party MFA vendors such as DUO. I don't know if they also support Entrust.

[AlexP]

I'd be willing to bet what you're describing might run into the compatibility issues described here: https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance/Authentication#Multi-F...

If the MFA request is coming in the form of an additional access-challenge packet that has an attribute-value pair prompting users to enter an OTP, that's not currently supported, and I don't know of a timeline in which it will be.

The only way MFA is supported right now is if the server sends out a prompt directly to your users (e.g. a push notification) and then sends an access-accept to the MX after the OTP has been entered by them.

[YoinkZ]

Ouch, you might be right :(. Wonder if this is a thing that will be worked on or just not supported.

[AlexP]

I can't comment on any sort of roadmaps as a whole unfortunately, but if you want to try and confirm this is the problem, take a pcap on your MX and look at the RADIUS traffic. If the last thing you see is an access-challenge packet containing the AVP I described above, yeah that's confirmation on the problem.