However, it would be great if we could provide an acceptable workaround or alternative.

After looking into it and doing much debugging/testing:ġ) 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.Ģ) 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.Īs it stands we will need to go back to our customer and advise them to use only Push/Phone 2FA methods.

Unfortunately our customer has tried to use the SMS and passcode (MS Authenticator App) methods and reported it didn't work. This works exactly how we want when using Push Notification or Phone Call 2FA methods (via Microsoft Authenticator App). This was achieved using Network Access Policies on the NPS server. We followed the following Cookbook document to successfully implement this:įor 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. Our customer now wants to integrate the existing SSL VPN to with their Azure MFA for 2-factor authentication. Our customer subsequently moved their AD into Azure cloud and introduced Azure MFA. 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!):įor 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.

Fortinet vpn mfa