How to authenticate users to different AD groups based on a passed parameter

[derek.small]

We have Fortigate firewalls for SSL-VPN remote access. We have different portals, each with it’s own URL and access restrictions, which have been created to limit what parts of the internal network a given user has access. So Internal users from VendorA might only be able to access Vlan10 and users from VendorB might only be able to access Vlan11.

We do this by using a single Windows NPS server with mulitple policies. Fortigate allows you to specify a NAS-IP parameter in each Radius request. Normally this would be the IP of the Fortigate, but the NAS-IP can be anything (even a string which is not an IP address). Each vendor has a specific policy on the NPS server then which matches the NAS IP (which represents that vendor), and an AD group that maches that vendor, for a user to sucessfully authenticate.

Authentication requests for internal users, to our internal users portal, are authenticated via a Duo proxy. We now have a requirement to use MFA for vendor access as well. As far as I know each Duo proxy includes only one AD group or list of AD groups, and that Duo proxy will only check group membership in that group or list of groups.

I need a way to pass a parameter like NAS-IP, or some other Radius VSA to the Duo proxy, then have the Duo proxy check if the NAS-IP is say 1.1.1.1, then the user request must a member of AD group VendorA. While if the Radius request has NAS-IP 2.2.2.2, then the user request must be a member of AD group VendorB.

If I have to put all my vendor accounts into the same group and have the Duo proxy check for group membership in that common vendor group, then I no longer have a way to prevent VendorA from attempting to login to https://my.company.com/VendorB portal and vise-versa. We currently have about 12 vendor portals defined and that is expected to grow, so having a dedicated Duo proxy per vendor portal isn’t a scalable solution.

Is there some other way to solve this problem with Duo? I was wondering about having the user authenticate via Radius first to the NPS (to check for correct group membership, then doing a defer to Duo for MFA. I’ve set that up with Azure, but not with Duo and am not sure how/if that would work. If that is even possible, then Duo would only need to handle the MFA part of the authentication request and not be concerned with AD group membership.

[DuoKristina]

DerekSmall:

I need a way to pass a parameter like NAS-IP, or some other Radius VSA to the Duo proxy, then have the Duo proxy check if the NAS-IP is say 1.1.1.1, then the user request must a member of AD group VendorA. While if the Radius request has NAS-IP 2.2.2.2, then the user request must be a member of AD group VendorB.

While the Authentication Proxy can pass through RADIUS attributes from the downstream authenticating client (the Fortigate) to the upstream RADIUS identity store (NPS), and vice-versa, it cannot make the conditional logical evaluations you describe here.

DerekSmall:

I was wondering about having the user authenticate via Radius first to the NPS (to check for correct group membership, then doing a defer to Duo for MFA. I’ve set that up with Azure, but not with Duo and am not sure how/if that would work. If that is even possible, then Duo would only need to handle the MFA part of the authentication request and not be concerned with AD group membership.

Are you able to chain authenticators on Fortigate VPNs now? My Fortigate experience is a few years out of date but my recollection was that if you defined multiple RADIUS authentication servers then the Fortigate could fail over from one to the next one in the list, but could not require success from each one in the list. If it is possible to configure chained primary and secondary then yes, the Duo Authentication Proxy can support MFA-only over RADIUS with duo_only_client

Two other approaches described in this knowledge base article are

• sending the AD group information from NPS as a RADIUS VSA and passing it through the Duo proxy
• using LDAP instead of RADIUS for direct group membership lookup against AD

[tonetl]

Did you end up coming up with a resolution to this problem? We are in a 100% identical situation.
Fortunately, for us, it’s only an employee portal and an HVAC portal. I’m basically at the point of just setting up a second VM to act exclusively as a dedicated duo proxy manager for our HVAC portal.