I have been working with a number of customer recently, and one question kept recurring "We have a tight integration with Azure/Azure AD for authentication, can we use that as our MFA platform with FortiGate SSL VPN?" - and while the answer is yes, it appears that the documentation on both sides is a little vague for how to make this happen. And while I'd love to get FortiAuthenticator deployed for simplicity's sake, I live in the real world and understand that many organizations have already invested considerable amounts of time and money into existing infrastructures, and if we can adhere to best practice and help customers realize additional value from existing infrastructure, we should try.
This article aims to fill in those gaps in documentation and provide guide on how to do a simple deployment.
Assumptions:
FortiOS Version: I am using FortiOS 6.4.2 - This should work on previous version of FortiOS (at least to 6.0.x) as the set up of FortiGate <-> NPS is a simple radius connection
Windows Network Policy Server (NPS) - I am running on Windows 2019 Standard with NPS role enabled
Active Directory - We're using Azure AD in the cloud and Active Directory with Windows Server 2016 Domain Functional Level which appears to be the highest possible
Azure AD Sync - We're assuming you have this installed and configured, and successfully synchronizing to Azure AD
This article assumes some degree of familiarity with Windows Server.
This article assumes that SSL VPN is currently configured and working, we're adding a new way of authenticating and assigning access to the FortiGate
Quick note:
While Azure Active Directory and Active Directory are similar in name, that's pretty much where the similarities end as far as we're concerned. Especially in how you consume those services. Active Directory (AD) uses Kerberos and NTLM for Authentication, whereas Azure AD uses SAML, OAuth and other Web base services.
With that being said, enough of the boring stuff, let's get to it!
For the context of this article, we'll be deploying the FortiGate and NPS first, once we've verified that the traditional RADIUS authentication is working, we'll move on to the Azure MFA extension.
Deploying Microsoft NPS:
Deploying NPS is relatively simple, once you've installed Windows Server and install the latest updates you enable the Network Policy and Access Server role in server manager.
Once the NPAS role is enabled, you will need to register the NPS server to AD:
Once the server has been registered in AD, you're ready to move on to adding clients and configuring the appropriate access policies.
Adding RADIUS Clients to NPS:
In NPS go to Radius Clients and Servers > Right Click on Clients > New
In the 'New RADIUS Client' Dialog configure the following: Friendly Name: A meaningful name so you know which device is what Address (IP or DNS): The IP/FQDN address of the FortiGate we're configuring for RADIUS authentication Shared Secret: You can choose to input a manual secret or generate. For this article I am going to choose 'Generate'.
Click apply
Adding NPS as a RADIUS Server to FortiGate:
On your FortiGate go to User & Authentication > RADIUS Servers and click 'Create New'
In the 'New RADIUS Server' dialog fill in the appropriate fields.
Note that while NPS and FortiGate support PAP, CHAP, MS-CHAP, and MS-CHAPv2, we're specifying 'MS-CHAPv2' as it's the most secure option available. For your needs, review the encryption requirements on Microsoft's site to choose the option best for you
Click 'OK'
Select the server you just created and click edit.
Validate connectivity to the RADIUS server by clicking 'Test Connectivity' - and you should see 'Successful'
Creating Connection Request Policies:
We will create Connection a Connection Request policy to limit the devices that can authenticate to the NPS. This step can be skipped - call this a bit of extra paranoia.
On the NPS go to Policies > Right Click on Connection Request Policies > New
Specify the policy name and click next
In the 'Conditions' dialog click 'Add'
In the 'Specify Conditions' dialog scroll to Access Client IPv4 Address and click 'Add'
In the 'Access Client IPv4 Address' dialog box input the IP address of the FortiGate that we configured in the steps above
In the 'Specify Connection Request Forwarding' leave the defaults - click next
Click next on 'Specify Authentication Methods' we'll handle these with the Network Policies
In 'Configure Settings' click on 'Vendor Specific' and click 'Add'
Scroll down to the bottom and select 'Vendor-Specific' and click 'Add...'
In 'Attribute Information' Click 'Add...'
In the 'Vendor-Specific Attribute Information Window' set the following: Select from list: RADIUS Standard Specify whether the attribute conforms to the RADIUS RFC specification for vendor specific attributes: Yes. It conforms - and then click 'Configure Attribute...'
In Configure VSA (RFC Compliant) set the Attribute format to 'String' and Attribute value to 12356 (there is no 4 in that string, a mistake I made)
Click OK
Click OK in 'Attribute Information'
Click Close in 'Add Vendor Specific Attribute'
You should now have the Vendor-Specific attribute with the value of 12356 in the 'Configure Settings' dialog
Click finish in 'Completing Connection Request Policy Wizard'
Now that we've created the Connection Request Policy we can create the Network Policy
Creating Network Policies for User Access:
Network policies are created to grant or deny access to users based on conditions you set. In these steps, we'll grant access to the group named 'UV-VPN-SSL'.
In NPS right click on Policies > Network Policies > and Click New
Give the policy a meaningful name, leave the type of network access server to 'Unspecified' and click 'Net'
In 'Specify Conditions' click Add..
Select the 'User Groups' condition and click Add
In the 'Select Group' dialog, input the group name you wish to grant access to and click OK
Click OK in the 'User Groups' window
Click Next on the 'Specify Conditions' Dialog
Select 'Access Granted' on the 'Specify Access Permission' window
For Authentication Methods, we'll select MS-CHAP-v2 - and click next
Accept the defaults in 'Configure Constraints' and click next
Click on 'Vendor Specific' in the 'Configure Settings' window, and click Add
Scroll down to the bottom and select 'Vendor-Specific' and click 'Add...'
In 'Attribute Information' Click 'Add...'
In the 'Vendor-Specific Attribute Information Window' set the following: Select from list: RADIUS Standard Specify whether the attribute conforms to the RADIUS RFC specification for vendor specific attributes: Yes. It conforms - and then click 'Configure Attribute...'
In Configure VSA (RFC Compliant) set the Attribute format to 'String' and Attribute value to 12356 (reminder: there is no 4 in that string)
Click OK
Click OK in 'Attribute Information'
Click Close in 'Add Vendor Specific Attribute'
You should now have the Vendor-Specific attribute with the value of 12356 in the 'Configure Settings' dialog
Click finish on the 'Completing New Network Policy' dialog
At this stage, if you just wanted to use NPS as a regular RADIUS server you'd be done, and it would work just fine. This is evident by going to the User & Authentication > RADIUS Servers > Double click on the RADIUS server we just configured and clicking on 'test user credentials'
But the whole point of going through all this trouble is to get Azure MFA working with FortiGate for SSL VPN. So now we have to make a few tweaks on the FortiGate to ensure a good user experience.
Creating User Groups and Setting Remote Authentication Timeout:
Due to Azure AD residing in the cloud, the amount of time required for successful authentication increases, especially since we're adding 2-Factor Authentication. By default FortiGate allows for 5 seconds for a remote authentication to take place, this may not be enough. You will want that to be anywhere between 30-60 seconds. For this article we'll set it to 60 seconds.
config system global
set remoteauthtimeout 60
endOnce that's configured navigate to Users & Authentication > User Groups and click on Create New, and we'll configure as follows:
Name: SSL-VPN-USERS
Type: Firewall
Members: Leave blank
Remote Groups: Click Add
In the Remote Server drop down, select the RADIUS server we created earlier
For this article we'll select 'Any' and click OK. You could configure NPS to send VSAs to define group name, and the FortiGate to look for those VSAs. That is outside of the scope of this article
Click OK in 'New User Group'
Now that we have a User Group Created, we can provision SSL VPN access.
Provisioning SSL VPN Access for the new user group
Assuming you already have SSL VPN configured for your users, you will need to configure the following to provision access to the new group:
In SSL VPN Settings we will map SSL-VPN-USERS to the 'full-access' SSL VPN portal, and All Other Users/Groups will only get 'web-access' and click Apply
Don't forget to create/edit the relevant policies, if you do you'll get a "permission denied" when you try to log in
We've done a lot of work up to this point, and we're still not quite there. Now, the moment we've all been waiting for; enabling Azure MFA on the NPS server.
Installing the Azure MFA NPS Extension
Before going through these steps, you'll want to review the appropriate documentation on Microsoft's website as it applies to your environment. To install the Azure MFA extension for NPS we'll do the following:
Run an Azure AD Sync to make sure everything is up to date in Azure AD
Download the NPS Extension from the Microsoft Download Center to the NPS we created earler
Run setup.exe and follow the installation prompts
Once it's been installed you will need to run the PowerShell configuration script located in "C:\Program Files\Microsoft\AzureMfa\Config\AzureMfaNpsExtnConfigSetup.ps1'
You will be prompted to sign into Azure AD as an administrator - make sure you use a Global Admin with the correct privileges
You will be prompted for your tenant ID to generate a certificate the extension will use to communicate with Azure AD, this can be found under your 'Overview' screen of your Azure AD:
And that's it! The Azure AD MFA extension is installed. You may not be done at this stage however, see additional considerations below.
Additional Considerations:
When I initially tested on the FortiGate I would get the 'Invalid Credentials' error. Upon further investigation on the NPS I found that it was being denied by the Azure MFA extension with the following error "An NPS extension dynamic link library (DLL) that is installed on the NPS server rejected the connection request.".
Well now, that's interesting, it was working before we added the MFA extension, so what changed? I remembered that when I deployed Azure AD Sync (a while back) I got some error stating that the userPrincipalName in Azure AD didn't match the userPrincipalName on prem (@domain.local vs @domain.com) so I chose to use the 'mail' attribute as the binding attribute between the two, could this be why?
When I started reading more closely (as we all do when things don't go our way) I found this page specifically the LDAP_ALTERNATE_LOGINID_ATTRIBUTE, which is explained as:
Since the NPS extension connects to both your on-premises and cloud directories, you might encounter an issue where your on-premises user principal names (UPNs) don't match the names in the cloud. To solve this problem, use alternate login IDs.
So I went to HKLM\SOFTWARE\Microsoft\AzureMfa and set the LDAP_ALTERNATE_LOGINID_ATTRIBUTE value to 'mail' and it worked!
As for registering your user for Multi-Factor, I recommend you take a look at 'Register users for MFA' as there are a number of ways you can register / require 2-Factor authentication.
Testing Access:
This is probably easier done with Video. I mirrored my iPhone to my Mac using QuickTime so you could see the notification come in.
I hope this is helpful to you, if it helps only ONE person, then this was worth it. Thanks for reading!
Comments