7.2.10 Breaks DUO Radius proxy

[gattac]

We have a few customers who use the DUO Radius proxy to provide 2fa for the VPN. After an automatic update to 7.2.10 the user receives the DUO prompt, but authentication never completes. There is a known bug int the release notes about radius not working in the UI, and the workaround is to use the CLI to test authentication, but not that it would break any actual functionality.

For now we have rolled back to 7.2.9 but just wanted to give a heads up.

[Toshi_Esumi]

@salehaThank you for confirming this, although the last doc you referred, which I already read through yesterday, doesn't sound so promising.

Toshi

[Scratchbuild1]

Just ran into this today after upgrading from 7.2.9 to 7.2.10, using Duo Auth Proxy as the RADIUS server. One effective workaround for this that I worked out is to switch from using ad_client as the authentication source for Duo, to using radius_client. Thanks Saleha for this link:

https://help.duo.com/s/article/9014?language=en_US

That put me on the right track to realize that if you pass through the Message Authenticator attribute to a patched MS NPS server, you'll get one back too, and it will satisfy the Fortinet requirement introduced in 7.2.10. If you don't already have NPS configured to serve RADIUS, you'll need to configure it. Then set up your Duo Auth Proxy like this:

**********************

[radius_client]
host=<ip address of your primary NPS server>
host_2=<ip address of your secondary NPS server>
secret_protected=<removed>
pass_through_all=true
retries=1

[radius_server_auto]
ikey=<removed>
skey_protected=<removed>
api_host=<removed>
radius_ip_1=<the IP or subnet of your devices that use Duo for RADIUS authentication>
radius_secret_protected_1=<removed>
failmode=secure
client=radius_client
port=1812
pass_through_all=true

*************************

You still need the [ad_client] section of the config file for synchronizing AD to the Duo cloud, but I didn't include it here because it doesn't change.

Note that pass_through_all is enabled for both the client and server section. I have my FortiGate configured to use MSCHAPv2 for the authentication type but I'm not sure that matters, as long as the NPS config is in agreement (note that if you do use MSCHAPv2 you also have to enable this registry setting on the NPS server and reboot):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy]
"Enable NTLMv2 Compatibility"=dword:00000001

Other than that, it's just a matter of setting up a RADIUS client on NPS that corresponds to your Duo Auth Proxy, and setting up a policy that allows access when the appropriate conditions are met (e.g. client friendly name, authentication type, Windows groups, etc).

[Toshi_Esumi]

I'm wondering if "ad_client" uses LDAP. Does anyone know?

Toshi

[Scratchbuild1]

Yes, ad_client uses LDAP. There are several choices for how to authenticate (mine is using SSPI) and you can choose to encrypt (LDAPS) or not, but it's definitely still AD over LDAP. I think that's actually at the heart of the issue: ad_client is an LDAP-based authentication source for Duo, so it can't generate a RADIUS Message-Authenticator attribute synthetically. The FortiGate sends the request back to Duo with Message-Authenticator because that half is RADIUS, but the back half is not RADIUS when it's ad_client, so it has no way to handle Message-Authenticator.

[FortiUsr]

Duo released version 6.4.2 to fix this:

Version 6.4.2 - October 21, 2024

• Adds the configuration option force_message_authenticator to radius_server modules.
  • Set force_message_authenticator to true to force the Authentication Proxy to include a message-authenticator attribute in reply packets.
• Ensures that reply packets containing a message-authenticator attribute send that as the first attribute.

[saleha]

Hi FortiUsr,

Thank you for the informative update. Here is the page from DUO reflecting what you mentioned about DUO version 6.4.2 or later supporting this change:
https://help.duo.com/s/article/9014?language=en_US

Thank you,

saleha