radius MFA

[Ivan90]

Hello guys! Got a bit confused with FG's auth process for remote ssl-vpn users. For now we have a simple LDAP/AD (w/o agent) based authentication for remote users and ACL based on AD group names, everything just works and works fine. Now I got the case that I have to implement MFA via an MS NPS(plus azure MFA) as a radius server (please don't ask why). I don't understand how to implement this transparently. Do I have to add all existing groups by name in the same way how I do this with LDAP into each ACL(that's could be long, but ok)? And how the FG knows in which group a user in ? What if the user is in several groups? So can anyone elaborate these moments ? I read this article , but it's still unclear https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configuring-User-Groups-to-match-multiple-... AFAIK the FG gets the group name AVP from the radius server (MS-NPS) , but is it all groups for each client or like a first group per client ? Do we have to change settings on the client's side like for SAML or the 2FA string appears by default ?
Thanks for advices in advance!

the FOS is 7.4.7

[adambomb1219]

Have you considered using SAML instead? SAML is far more modern and a much better user experience than RADIUS/NPS.

[Ivan90]

I know, I know, unfortunately for some reasons it's not acceptable for this exact case , so we have a radius NPS server only 

[tbarua]

Hi, 

FortiGate checks against all possible authentication servers in parallel to allow the fastest possible response time and prevent undue wait times during login. It does NOT check against secondary server IPs: these are only queried if no response has been observed from primary servers. FortiGate will check the secondary servers once the remote authentication timeout has been reached ('remoteauthtimeout' under 'config system global' in CLI).

Please check this kb, which clarifies how FortiGate handles Radius requests: 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-A-quick-guide-to-FortiGate-SSL-VPN-authent...

[Ivan90]

yes, FG does request for all possible available servers and methods , that is behaviour that I can't understand why they implement this, why without priorities and steps ?  There are a lot of cases where people got confused. Could you explain how FG gets user's group participating in the case of Radius server? Especially if a user has more that 1 AD group?  Thanks for the KB, will read.

[Ivan90]

guys, it's still unclear should I select the option "any" in the creating group menu and exact group names will be delivered as a AVP value  or create all AD groups with "specify"  option ? 

[Debbie_FTNT · Accepted solution]

Hey Ivan90,

regarding VPN authentication in general: FortiGate checks all possible servers in parallel to ensure a speedy authentication. It it worked with priorities, it would have to wait for each individual server before trying the next.
FortiGate determines what servers to check based on the user groups set in the policies with SSL tunnel interface as source.

-> any server referenced in any group is fair game to check against

-> at this point FortiGate has no idea which server or group the user belongs to and doesn't filter

--> FortiGate can limit its authentication request to specific groups/servers if you configure SSLVPN realms, as outlined in the article linked above

Regarding the groups and matching conditions:

-> as long as you set 'Any' as match, then FortiGate only checks if the user is a member of the server (successful authentication), and does not check if the user is member of any specific group

-> if you set a specific string as match, then FortiGate expects to receive that string in the RADIUS server response (as Fortinet-Group-Name attribute by default)
-> you can find more details here: Technical Tip: How FortiGate determines group memberships from RADIUS responses

-> the NPS should return each group in an individual instance of the Fortinet-Group-Name (or Class or FilterID) attribute; so if a user is member of multiple groups, the NPS should send back an Access-Accept message with multiple occurrences of the Fortinet-Group-Name or Class or FilterID attribute
-> FortiGate can parse them, and match the user to multiple groups then
-> each group attribute sent by NPS needs an equivalent group object on FortiGate with the correct matching condition
--> if there is no corresponding group object on FortiGate, FortiGate simply ignores the attribute

Please let us know if you still have any questions!

[Ivan90]

god bless you mate! At last it's exact answer for my questions.

Thanks !

[Ivan90]

sorry, one more question: in the case with Radius\NPS + Azure MFA will we need to configure the client's side (like with SAML) or the 2FA field will pop up automatically ?

[Debbie_FTNT]

Hey Ivan,

if the NPS can send a challenge for the Azure MFA (I'm not sure tbh), then this can happen as part of RADIUS no problem; the possibility to challenge for token code in built into the RADIUS protocol and FGT can properly prompt the user for a token code if the RADIUS server demands one.

If you use push notification for your Azure MFA instead, then FortiGate isn't even involved; the NPS would only send back the Access-Accept message after push notification is completed, and the push/reply bypasses FortiGate entirely.

-> It basically depends on how the NPS loops in Azure MFA

-> please note that I've seen a few cases where NPS does NOT send group attributes if push notification/MFA is involved, which means FortiGate cannot match the user to groups based on the attributes

Cheers,

Debbie