FortiClient to FortiGate SSL-VPN using SMS 2FA via Azure MFA - group match not supported

[Phil_Lofthouse]

Hi all.

I'm hoping someone will be able to advise me on a work around, or an alternative solution, to avoid the following limitations with Microsoft NPS Extension for Azure MFA (without having to implement a completely different solution!):

https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/36647266-mfa-nps-ext-sup...

For context, our customer originally had a FortiClient to FortiGate SSL VPN that utilized LDAP authentication, allowing different levels of network access depending on AD user group membership.

Our customer subsequently moved their AD into Azure cloud and introduced Azure MFA.

Our customer now wants to integrate the existing SSL VPN to with their Azure MFA for 2-factor authentication.

We followed the following Cookbook document to successfully implement this:

https://docs.fortinet.com/document/fortigate/6.2.0/azure-cookbook/517582/configuring-forticlient-vpn...

For the existing network access based on AD user group membership to work, the NPS server (RADIUS) had to send RADIUS attributes for group membership back to the FortiGate with the Access-Accept. This was achieved using Network Access Policies on the NPS server.

This works exactly how we want when using Push Notification or Phone Call 2FA methods (via Microsoft Authenticator App).

Unfortunately our customer has tried to use the SMS and passcode (MS Authenticator App) methods and reported it didn't work. After looking into it and doing much debugging/testing:

1) The user authentication with 2FA part works as the NPS server returns an Access-Challenge to the FortiGate, which opens a 2FA prompt in FortiClient, then an Access-Accept response when the 2FA authentication is successful.

2) Because the NPS server doesn't return any RADIUS attributes, the SSL VPN connection fails as there is no group matched to the one configured on the FortiGate.

As it stands we will need to go back to our customer and advise them to use only Push/Phone 2FA methods. However, it would be great if we could provide an acceptable workaround or alternative.

I have no experience using FortiAuthenticator, but was wondering if this can be integrated with Azure MFA as an alternative to using the NPS server/extension?

Sorry for the long post and many thanks in advance for any help.

Kind regards,

Phil.

[Phil_Lofthouse · Accepted solution]

Hi Ken.

Yes, we followed the cookbook recipe, as well as referring to the Microsoft documentation for Azure MFA, etc...

To clarify, I was responsible for the FortiClient/FortiGate configuration, while our customer's 3rd party Microsoft support company dealt with the Azure MFA and on-premises NPS server, so I don't know all the ins and outs of how the Microsoft side of things is configured.

The RADIUS attributes, specifically those that send the user's AD group membership, are part of the Network Access Policies on the NPS server.

These attributes get sent to the FortiGate with the Access-Accept, so the FortiGate then knows what AD groups the user is a member of and can match them against the firewall user groups defined on the FortiGate, and then against the firewall policies.

Obviously, the firewall user groups specify the RADIUS remote authentication server, in this case an NPS server, but more importantly the firewall user group also specifies an AD user group (rather than just "any").

This works fine when using Push Notification or Phone Call 2FA methods, as this part of the authentication process is not dealt with by the Fortinet components.

Once the primary and 2FA are validated, the NPS server sends the Access-Accept to the FortiGate, along with the RADIUS attributes for AD group membership.

SMS and App pass code 2FA methods fail when we specify AD groups in the firewall user groups, because the NPS server does not send the RADIUS attributes to the FortiGate, just the Access-Accept.

The NPS extension limitation is that it won't process any attributes in the Network Access Policies if a Challenge-Response is required and sent to the Fortinet components.

Once the user enters the SMS/App pass code in box presented by FortiClient, this gets sent back to Azure MFA and validated, then the NPS server sends the Access-Accept to the FortiGate.

However, the Fortigate receives the Access-Accept but no RADIUS attributes with AD groups to match against its firewall user groups, so the authentication fails.

The SMS/App pass code 2FA method DOES WORK, if the FortiGate firewall user group does not specify an AD group, just "any".

However, using "any" means we can't then differentiate the users by group and so give them different network access.

Ultimately I'm trying to work out if there is a way around this without introducing massive admin overhead and/or extra cost, or if I need to go back to our customer and advise they can't use those 2FA methods exactly how they want.

Sorry for another long post!

Kind regards,

Phil

[emnoc]

Many ORGs are using azure MFA and forticlient  fwiw. Did you follow the cookbook to a T?

2) Because the NPS server doesn't return any RADIUS attributes, the SSL VPN connection fails as there is no group matched to the one configured on the FortiGate.

You can set NPS to send attributes, but I don't know or understand what attribute are you expecting?

Ken Felix

[Phil_Lofthouse · Accepted solution]

Hi Ken.

Yes, we followed the cookbook recipe, as well as referring to the Microsoft documentation for Azure MFA, etc...

To clarify, I was responsible for the FortiClient/FortiGate configuration, while our customer's 3rd party Microsoft support company dealt with the Azure MFA and on-premises NPS server, so I don't know all the ins and outs of how the Microsoft side of things is configured.

The RADIUS attributes, specifically those that send the user's AD group membership, are part of the Network Access Policies on the NPS server.

These attributes get sent to the FortiGate with the Access-Accept, so the FortiGate then knows what AD groups the user is a member of and can match them against the firewall user groups defined on the FortiGate, and then against the firewall policies.

Obviously, the firewall user groups specify the RADIUS remote authentication server, in this case an NPS server, but more importantly the firewall user group also specifies an AD user group (rather than just "any").

This works fine when using Push Notification or Phone Call 2FA methods, as this part of the authentication process is not dealt with by the Fortinet components.

Once the primary and 2FA are validated, the NPS server sends the Access-Accept to the FortiGate, along with the RADIUS attributes for AD group membership.

SMS and App pass code 2FA methods fail when we specify AD groups in the firewall user groups, because the NPS server does not send the RADIUS attributes to the FortiGate, just the Access-Accept.

The NPS extension limitation is that it won't process any attributes in the Network Access Policies if a Challenge-Response is required and sent to the Fortinet components.

Once the user enters the SMS/App pass code in box presented by FortiClient, this gets sent back to Azure MFA and validated, then the NPS server sends the Access-Accept to the FortiGate.

However, the Fortigate receives the Access-Accept but no RADIUS attributes with AD groups to match against its firewall user groups, so the authentication fails.

The SMS/App pass code 2FA method DOES WORK, if the FortiGate firewall user group does not specify an AD group, just "any".

However, using "any" means we can't then differentiate the users by group and so give them different network access.

Ultimately I'm trying to work out if there is a way around this without introducing massive admin overhead and/or extra cost, or if I need to go back to our customer and advise they can't use those 2FA methods exactly how they want.

Sorry for another long post!

Kind regards,

Phil

[TomaszJ]

Hey Phil,

We are Having same issue here.

Did you manage resolve your issue somehow?

[Phil_Lofthouse · Accepted solution]

Hi Tomasz.

Firstly, I should apologise for not updating my forum post.

I raised a support ticket with Fortinet, who ultimately confirmed what I'd discovered through research and testing, that the limitation is with the Microsoft NPS server.

In the end we agreed with our customer that any user who had to use the SMS or App pass code methods, would only be allowed the minimum access granted by an "any other user" SSL VPN firewall rule.

Users requiring more access, depending on their group membership, would have to use the Push Notification or Phone Call methods, with access granted by specific SSL VPN firewall rules placed above the "any other user" rule.

I haven't had time to investigate other possibilities that wouldn't require the customer to incur additional costs.

I hope this helps you in some way.

Phil

[grenona]

Thanks for this good resume, any news from MS on NPS group recognised ?

[emnoc]

yeah this is good bits of information that can save others a bunch of headaches

Ken Felix

[ccentala]

Hey, registered to post this answer since this is recent.   Please see this link, it is outlined very clearly on what is supported. https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension#deter...   Here is the snippet:

MS wrote:

Also, regardless of the authentication protocol that's used (PAP, CHAP, or EAP), if your MFA method is text-based (SMS, mobile app verification code, or OATH hardware token) and requires the user to enter a code or text in the VPN client UI input field, the authentication might succeed. But any RADIUS attributes that are configured in the Network Access Policy are not forwarded to the RADIUS client (the Network Access Device, like the VPN gateway). As a result, the VPN client might have more access than you want it to have, or less access or no access.

[RicardoBenq]

Hello! We managed to implement 2FA with Forticlient using NPS Extension + MS Authenticator. After initiating the connection from Forticlient, it "freezes" at 45% waiting the approval in the MS Auth smatphone app then, after the approval, everything works fine. This behavior is ok for experienced users but may confuse others. Is there a way to show a message or a pop-up in Forticlient remembering the user to look in the authenticator app? I think it would need NPS to send some attribute to Fortigate but I couldn´t find any information on it. Anybody?

[Debbie_FTNT]

Hey Ricardo;

With usual two-factor authentication such as typing in a code, the NPS would have to send a RADIUS Access-Challenge to FortiGate, which in turn would then forward the challenge to the client; this would trigger a message like 'please submit the token code' and the option to type in the code.

With pure push notification, there usually is no Access-Challenge sent to FortiGate which could then forward it to the client.

I'm not sure what options you have on NPS, but if you can get it to either accept a code or push notification, and ensure it prompts for a code, then you could probably have the message accompanying the token prompt include something like "Please submit the token code or accept the push notification you should have received.", and that would be displayed in FortiClient.