Duo's incompatibility with OS/application based VPN services

Due to security concerns, a minority of our users do not want to install the Duo app on their phones. Although I tell them their fears are truly unfounded, I always tell them that they can always receive phone calls from Duo if they prefer. (We have SMS globally disabled.) Phone calls work for regular OWA and Outlook logins, but not for our VPN. Duo support has advised us that it does not work well with OS / application based VPN service such as ours because of their inability to code in their HTML code displaying the factor selection menu due to inability to program / code / hook into other 3rd party applications and operating systems.

This leaves some of our users – a number of whom currently work exclusively from home – completely unable to use our VPN.

Duo, what’s the estimated date of getting this fixed?

The VPN that can’t use Duo phone calls is a rare one indeed. What VPN are you using, and what Duo config do you use with it? If you are using RADIUS auto then users might be able to append ,phone to their password to receive a call. Find out more about append mode here.

With that said, we do encourage use of Duo Mobile to enjoy a first-class authentication experience.

Kristina, you wrote:

With that said, we do encourage use of Duo Mobile to enjoy a first-class authentication experience.

These users are willing to settle for a second-class authentication experience but Duo will not provide them with any authentication experience.

  1. We can’t use suffix / appending a selector due to MS EAP security method in use which is not supported for that scenario. (When we try appending ,phone or ,push to the password, the VPN login attempt fails with the error of incorrect user name or password.)
  2. We can’t reliably resort to phone calls because users don’t get them reliably when trying to connect.

I was hoping a YubiKey could help these users (as a workaround) but it seems there’s no way to make it the default device. So if they add a YubiKey:
     - when they log into OWA, they get both a Duo Push on their cellphone as well as the YubiKey simultaneously flashing
     - when they log into the VPN, they only get a Duo Push but the YubiKey doesn’t flash at all

And when users remove all other devices from their Duo account so the only remaining device is a YubiKey, logging into the VPN still does not flash the YubiKey.

Without any other options, we actually had to get some of these users devices specifically so they could connect over Wi-Fi and install the Duo app on it. It was the only way they could continue to do their job. So much for the workarounds… :-1::-1::-1::-1::-1:

Ah yes, MS-CHAPv2 is the scenario where append options aren’t supported because the proxy can’t split the encapsulated password value to parse out the password portion of the attribute vs. the passcode or appended factor name. Did you happen to try RADIUS Challenge mode? Again, what VPN are you using? We have some internal notes about VPNs where MS-CHAPv2 and RADIUS Challenge are known to work or not work.

when they log into OWA, they get both a Duo Push on their cellphone as well as the YubiKey simultaneously flashing

The user would only receive an automatic Duo Push at this point if they explicitly selected “Automatically send this device a Duo Push” as their default login action during enrollment. If you have enabled the self-service portal on the OWA application then any users who enabled the automatic Duo Push can turn that off there. This can’t be enabled/disabled on behalf of a user by the Duo admin.

logging into the VPN still does not flash the YubiKey

The behavior you describe is the YubiKey being utilized as a WebAuthN/U2F Security Key. This will NEVER work with a VPN RADIUS auto/challenge configuration. This is only supported in browser-based authentication when the interactive Duo web prompt is shown. This authentication standard is only available in web browsers and platforms. You can learn more about the FIDO2 standards here. When customers utilize Yubikeys with RADIUS auto/challenge configurations is it in OTP mode, to provide a passcode. As already mentioned though, this won’t work for RADIUS Auto and MS-CHAPv2 due to the limitation on appending factors to the password.

If you have a specific feature request (whether that is native EAP-TLS support or something else that fits your environment) please be sure to share it with your Duo account exec or customer success manager (if you have one). Otherwise you can contact Duo Support to submit your feature request. Community forum posts aren’t actionable feature requests. You can read more about the purpose of the Duo Community in this post.

Yes, without success.


Ah, ok. We do see many issues with append mode and RRAS, even when customers configure with PAP instead of MS-CHAPv2, because Windows can’t tell where the password ends and the delimiter plus factor begins, so it caches the entire password+factor string as the password in Credential Manager. Then, when someone tries to connect to a network resource (like a mapped drive) Windows uses that cached password, which is incorrect.

And what’s the solution for customers with such configurations?

The solution in that specific scenario is to not use append if they are not a customer who has already made policy decisions that limit available technical functionality.

If you have not already submitted your feature request (or requests) please don’t hesitate to do so.

…sorry, could you please rephrase that?

This means the scenario where the typically recommended workaround to a particular issue is not applicable to a customer’s environment for other reasons.