At work, we have been customers of Fortinet for just under 10 years. During this time we haven’t really had anything wrong to say about their product, the Fortigate. That was until about a year ago when we pursued our Cyber Essentials Plus certification. Before we dived into the audit we went over the scope and believed the edge firewalls to be within the scope of audit purposes. This meant that we were going to need to show one of two things for our administration access. Multi-Factor Authentication or Lockout policies. As we were big users of Azure MFA we decided to go down this route as an easy win.
Upon investigation into setting this up, Fortinet had their own product the FortiToken to be able to take advantage of MFA for administration purposes. However, they did allow AzureMFA through SSL-VPNs so we decided to see if we could adopt their configuration guide to allow us to perform MFA on the logins for administration purposes. After a load of trail and error we managed to get it working.
RADIUS Server Configuration – Fortigate
config user radius edit "NPS" set server "10.0.0.100" set secret ENC SecretKey set timeout 60 set all-usergroup enable set password-renewal disable next end
User Group Configuration – Fortigate
config user group
set member "NPS"
User Configuration – Fortigate
config system admin
set remote-auth enable
set accprofile "super_admin"
set vdom "root"
set email-to "email@example.com"
set remote-group "Admins"
set password ENC SecretBackupKey
Network Policy Server
On your Network Policy Server (NPS) install the AzureMFA extension as per the Microsoft documentation: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension
Next, configure NPS to allow connection from your firewall by setting up a RADIUS Client. All this needs is the IP Address and the SecretKey configured in the Fotigate RADIUS Server Configuration above.
Next, we’ve had to set up both a Connection Request Policy and a Network Policy. In the Connection Request Policy, we’ve left everything at default apart from adding one condition which is the RADIUS Client IP so it always hits this policy and add a Vendor-Specific Attribute in the settings. This Attribute is a RADIUS Standard attribute and has a string value of 12356 and we’ve set the policy to conform.
Finally, we set the Network Policy to meet two conditions, the RADIUS Client IP and the group of users we wish to use for this administration. In our case, we used our IT Department. The constraints we use are to enable PEAP in the EAP types and MS-CHAP-v2 as an authentication method. We’ve then set the same Vendor-Specific attribute as in the Connection Request Policy.
One thing to note here is we attempted to configure this whilst keeping our old NPS setup active. Don’t do this. We weren’t getting the expected results and were seeing our RADIUS traffic hitting both our old and new NPS servers and as the old one didn’t need MFA it was responding with the Access-Accept message before the MFA was performed. This took me quite a while to figure out despite me setting our group to go via the new MFA NPS server in the Fortigate. The simple solution is to either remove the RADIUS Server from the configuration or just move the configuration across to the new NPS Server altogether.