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

[Ivan90]

Mate, one more question: is it "normal" logic by design that the FG works with MS_NPS expecting the whole list of VSA group attributes? Also from the https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configuring-FortiGate-and-Microsoft-NPS-Ra... there is a line "If the user is not a member of at least one group, authentication fails." But in the enterprise world it's more than ok when a user is member of just several groups from of a list. Or fortinet follows the logic like "it's a 3rd party radius and we work with just any answer that's received from the radius" ?  Can this list can be dynamic from the MS side?  It looks like it's 2 different logic when you work with LDAP and Radius. Is it possible that the NPS (radius) is used for Auth process only and the group list from AD is used via LDAP? Will the FG be able to match a radius authenticated user with LDAP's groups for ALCs ? 

[Debbie_FTNT]

Hey Ivan,

- on FortiGate, if you create a group and add a remote RADIUS, you can define a match

- if this is configured, FortiGate will only consider any authenticating user a member if the response from RADIUS server contains that same matching string in the group attribute (no matter if NPS or FortiAuthenticator or Duo or whatever)

- you can also leave the match blank

-> then FortiGate does not care what attributes the RADIUS server sends, only that authentication is successful; if successful, the user is considered a member of the group

- the FortiGate does not need to receive EVERY group membership as an attribute

- but it does need to receive the attributes to ensure the user matches into the groups configured on FortiGate

- what attributes (group info) you need NPS to send depends entirely on the groups you have configured on FortiGate and where and how you use them

- in general, it's sufficient for FortiGate is the user is member of ANY relevant group (any of the groups set in policy/VPN configuration/etc), and it's not required for a user to be member of ALL

--> essentially: if you want a user to match a specific policy that requires a specific group membership, make sure that group info is included in RADIUS response as well. Do this for EVERY policy you want the user to potentially match to know what group memberships the FortiGate needs to learn about

- regarding your question on using AD for group information instead: No, you can't mix them. FortiGate relies on the authentication server that verified the user credentials to also provide group information

(you could technically get around this by importing the user to FortiGate, that is, creating a local user of type 'remote RADIUS', and adding that local user to whatever groups on FortiGate, then group info from RADIUS is irrelevant, but that scales very badly in large environments)

Hope this helps!

Cheers,

Deborah