Fortinet Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Phil_Lofthouse
New Contributor III

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

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.

2 Solutions
Phil_Lofthouse
New Contributor III

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

View solution in original post

Phil_Lofthouse

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

View solution in original post

7 REPLIES 7
emnoc
Esteemed Contributor III

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

PCNSE 

NSE 

StrongSwan  

Phil_Lofthouse
New Contributor III

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

View solution in original post

TomaszJ

Hey Phil,

 

We are Having same issue here.

Did you manage resolve your issue somehow?

 

Phil_Lofthouse

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

View solution in original post

grenona

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

emnoc
Esteemed Contributor III

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

 

Ken Felix

PCNSE 

NSE 

StrongSwan  

ccentala
New Contributor

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.