On Apr 12, 2018, at 2:39 PM, Charles Butera via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

Has anyone been able to integrate DUO 2FA with Freeradius?

It looks like some Windows-only proprietary thing. So... no. Alan DeKok.

Charles Butera via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

Has anyone been able to integrate DUO 2FA with Freeradius?

We'll be working on this sometime... well "soon" may be an exaggeration.

I currently have a radius proxy provided by DUO in order to get this working but I would rather have this done solely by Freeradius if possible. https://duo.com/docs/authproxy_reference#installation

As we intend to use this for VPN 2FA, I am advocating that instead of using the Duo RADIUS proxy, we use Duo's API for website 2FA instead, and not integrate it with IKE, because it is hard enough to deal with users having strange IKE connection problems as is, without expecting every OS VPN client to be OK with keeping EAP/IKE just hanging there for perhaps even minutes of delay during the 2FA process. Instead, I hope we can let the IKE sessions establish, block them with an ipset so they have no actual connectivity, and shell out with rlm_exec to invoke the Duo API and remove the ipset block when that completes, or send a disconnect-request to the NAS if it does not. Website applications are also more flexible in the Duo account management system allowing for more customized behavior than RADIUS applications. A few things to note: this is not watertight 2FA. A hacked cable modem and advanced threat who knew the first factor could detect a connection attempt, block it, and connect themselves The hapless user would respond to the 2FA message, then sit around confused and calling the helpdesk while the attacker had their way. Or just try again and blow it off. Basically this is because unlike OTP or OAUTH type stuff, there is no information exchanged between the 2FA process and the client/supplicant to lock a 2FA response to a particular session ID. Second, Duo does not have a facility for keeping auth tickets open for a while so if your application does periodic reauths or if you want people to be able to redial after their crummy home WiFi kills their IPSec connection without constantly being asked to re-2FA, you have to handle that on your side.... which... makes the first problem even worse if you cannot discriminate between an attacker's session and the real one. Still, better than nothing. Too bad so few VPN clients can do multiple auth rounds without using XAuth over crummy old IKEv1.