Fortigate MFA – Administration

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
edit "Admins"
set member "NPS"
next
end

User Configuration – Fortigate

config system admin
edit "twestby"
set remote-auth enable
set accprofile "super_admin"
set vdom "root"
set email-to "talan.westby@takeitfurther.co.uk"
set remote-group "Admins"
set password ENC SecretBackupKey
next
end

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.

Notes

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.