Cisco ASA + LDAP + AnyConnect

[charlesedstrom]

I’m working with a vendor who manages the ASA firewall. I provided the instructions (Duo Two-Factor Authentication for Cisco ASA SSL VPN with Browser and AnyConnect | Duo Security) for them to use in configuring Duo with the proper keys and host info needed.

We tested it and found it would not take the credentials entered. I had the vendor go back over the instructions twice to validate they did not miss any details and they confirmed it.

When authenticating we can see the failures in the Duo panel so it appears it is configured to connect. But after some testing I found odd behavior when authentication with AnyConnect.

If we enter the user ID then the user password, and enter either the passcode or ‘push’ for the secondary, it will fail. I found through some trial and error, if we enter ‘push’ for both the password and secondary password, we get the push notification on the mobile device and we can successfully connect. Obviously not how it should behave.

Does anyone have any suggestions I can pass on to my vendor on where there could be an issue, or what they may have overlooked in the instructions?

And to the forum managers who will say to open a ticket; been there, done that, still waiting for the t-shirt.

[DuoKristina]

cedstrom:

If we enter the user ID then the user password, and enter either the passcode or ‘push’ for the secondary, it will fail. I found through some trial and error, if we enter ‘push’ for both the password and secondary password, we get the push notification on the mobile device and we can successfully connect. Obviously not how it should behave.

This sounds like an AAA auth misconfiguration in the tunnel group where it is not properly performing primary authentication against your pre-existing identity store before then performing Duo auth via LDAPS as secondary. It sounds like the vendor may have set Duo as the AAA server for both primary and secondary instead of only for secondary (this step).

If primary auth was correctly going to your user identity store then the name of a Duo factor (like push) submitted as the primary auth password should cause the auth to fail.

If I can add a brief opinion: this is the least feature-rich way to add Duo auth to an ASA for AnyConnect clients.

• There’s no interactive Duo prompt offered for AnyConnect auth, leaving users unable to use self-enrollment , device management, or device security, posture, or trust checks during AnyConnect connection attempts.
• Browser VPN access can show the Duo traditional prompt now, but this integration will not be updated to Duo Universal Prompt.
• There is no controllable fail-mode, so if your ASA were unable to contact Duo’s service all your users get denied VPN access.
• There is no client IP reporting, so authentication logs are missing location information and you can’t use any Duo policies that rely on IP like authorized networks.

The best experience for end-users of ASA with AnyConnect is to federate with Duo Single Sign-On, which does get almost all of the bullet points above. If you are at the beginning of your ASA + Duo deployment and haven’t considered Duo Single Sign-On yet, give it a look.

[charlesedstrom · Accepted solution]

Thanks for pointing us in the correct direction. Duo was set for primary and secondary and correcting the primary resolved this.

As much as I agree with your bullet points. the client is protecting multiple applications and wants a consistent experience for end users. When SSO is available for all apps, we will change over.

[DuoKristina]

Glad that helped get the issue resolved.

cedstrom:

As much as I agree with your bullet points. the client is protecting multiple applications and wants a consistent experience for end users. When SSO is available for all apps, we will change over.

Makes total sense!