Blah, Cloud.

Adventures in architectures

  • Twitter
  • GitHub
  • Home
  • Blog
  • Kubernetes on vSphere
  • Multi-tenant IaaS Networking
  • Me
    • About
    • CV
    • Contact
Home » Blog » Security » Setting up Duo 2FA for Fortigate admin authentication

Setting up Duo 2FA for Fortigate admin authentication

31/08/2016 by Myles Gray 8 Comments

I protect any account I have with two factor auth, at least the ones that support it (this site for example has 2FA for admin logon), it’s not that inconvenient (especially not with Authy/Duo) and greatly increases security of your critical accounts.

Let’s start with the endgame:

Duo Logon

However, I haven’t protected my publicly accessible firewall with 2FA – mainly because there is no real built in method for using industry standard apps with it. (Who wants a hardware token or a paid for token nowadays? no thanks).

I have been using Duo recently for a lot of my 2FA accounts, mainly because I really like their “push” 2FA service, no need to type in any timed code, just tap approve on your phone/watch/whatever. They have an insane number of application integrations possible natively. However, there are a lot of services that don’t offer native integration, Fortigate as a case-in-point are a vendor that only allow their own tokens to be used – however you can have your VPN and firewall admin users auth against LDAP/RADIUS.

Helpfully, Duo have an auth proxy that will sit between the firewall and our actual auth source, check the credential against the primary auth source, then send a push to your mobile device before sending the auth approved message back to the firewall – essentially giving you two factor for any device that can use LDAP/RADIUS as a backend auth mechanism, like below:

Duo Auth Proxy

The beautiful part is it is completely application agnostic, the only requirement from the app is the ability to query a RADIUS or LDAP server.

You’ll need to sign up and add your mobile verification method. We’ll start by creating an application, navigate to the Protect an Application page, the number of apps is pretty overwhelming, but we are looking for RADIUS and then hit Protect this Application:

Authy RADIUS Proxy

Give it a meaningful name as multiple can be used across multiple sites – I’ve named mine MGIO-Lab-RADIUS-Proxy I find it helps to prepend a site name or domain to the start to make it more obvious in future. I also like to change the username normalisation to Simple as it will accept any of the given formats, which is fine by me.

Authy RADIUS Proxy Setup

Take note of the three credentials at the top; Integration Key, Secret Key and API Hostname.

Next we need to download the proxy, I typically install one on DC1 and another on DC2 with their primary auth methods pointed at themselves, with the other as a backup. This protects against app failure, VM failure and host failure (DRS anti-affinity rule).

As for any 2FA system, have backup keys as well as an unused admin user with a very long and complex password.

I’m using AD, so my auth proxy is going to live on Windows for handiness, you can of course run them on linux of you wish as well – either way you can get them here.

Install on your chosen machine (very Next -> Next -> Finish type deal) and now for the actual setup. Navigate to and open this file with wordpad as administrator (notepad messes with spacing and encoding):

C:\Program Files (x86)\Duo Security Authentication Proxy\conf\authproxy.cfg

I’ve created a new domain user as a Duo service account called _svc.duo and also have encrypted the plaintext password with the Authy password encryptor located here (you will need to generate a new hash for each proxy as they are machine specific):

C:\Program Files (x86)\Duo Security Authentication Proxy\bin\authproxy_passwd.exe

We also need to adjust the config from service_account_password to service_account_password_protected to let Duo know it’s encrypted, my config looks like this with all the info plugged in:

[ad_client]
host=dc1.lab.mylesgray.io
host_2=dc2.lab.mylesgray.io 
service_account_username=_svc.duo  
service_account_password_protected=<encrypted string>  
search_dn=dc=lab,dc=mylesgray,dc=io
security_group_dn=CN=Firewall_Admins,OU=Security Groups,OU=Groups,OU=Lab,DC=lab,DC=mylesgray,DC=io

Note from the above, host_2 is my second DC in case the first isn’t available – as stated before the same config will exist on the second proxy, just with host and host_2 swapped. security_group_dn is the security group I want to filter users on to allow users admin access to the Fortigate. Save the file, you will be prompted if you want to remove formatting (this is fine) go ahead and save.

Now we need to set up the RADIUS proxy so we can actually query it from the Fortigate, we need to add another section to the authproxy.cfg file and fill in the details from the console we recorded earlier:

[radius_server_auto]
client=ad_client
ikey=<your identity key here>  
skey=<your secret key here>
api_host=<your API hostname here>
radius_ip_1=<your firewall IP>
radius_secret_1=<add a password for RADIUS client auth here>
failmode=secure

The failmode=secure in the above section can be added if you’d like to make Duo reject all logins if backend auth fails – if you have an out of band admin account this should be an okay option to use. The field radius_secret_1 is just a password to allow the device radius_1 to query the new RADIUS proxy, just make sure you match this to the firewall config later on.

Now we are ready to start the Duo service:

net start DuoAuthProxy

If for whatever reason it fails to startup, go diving for logs in Event Viewer they are usually helpful and Google-able. Now your proxy is listening so it’s time to configure the Fortigate. I’m using FortiOS 5.4.1 in my lab so your UI will likely look a little different, but it can be found in the User & Device section – we are going to configure a RADIUS Server with the below settings (note the active/backup radius servers):

Fortigate RADIUS Server

I have created a group in AD Firewall_Admins as above to allow users access based on group membership – it’s a pain adding and removing users manually from firewalls so for me centralised RBAC = win.

We will now create a user group on the Fortigate and associate it with the Duo RADIUS proxy – Navigate to User & Device -> User Groups -> Create New – Name the group, Type should be Firewall and we will add a remote group – your RADIUS Proxy should show in the list under Remote Server and no group is needed as we have already filtered within the proxy – so Any is fine here.

Fortigate RADIUS User Group

Let’s add the Firewall_Admins group to the Fortigate administrator users, this is found in Global (if using VDOMs) -> System -> Administrators -> Create New, give it a name and change the Type to Match all users in a remote server group (or choose Wildcard on FortiOS 5.2). Choose the Firewall_Admins group we created earlier – set the Administrator Profile to super_admin.

Fortigate Admin Auth

That’s should be it, given all has gone well – logout of the firewall and log back in with one of the users in the Firewall_Admins group in AD – the login screen will wait for you to confirm on your phone then continue once you have pressed accept.

It’s a good idea to extend the login timeout on the fortigates to give you time to get your phone/process the logon, SSH into the firewalls and put this in to the console:

#config global //if you're using VDOMs
#config system global
#set remoteauthtimeout 60
#end
#end //if you're using VDOMs

This Foritgate article helped out a lot in the end when I found myself spinning my wheels over providing admin auth to a group rather than individual users: http://kb.fortinet.com/kb/documentLink.do?externalID=FD36127

Why not follow @mylesagray on Twitter for more like this!

Show some love:

  • Reddit
  • Twitter
  • Pocket
  • LinkedIn
  • Email
  • Telegram

Similar things I've written

Filed Under: Networks, Security Tagged With: duo, fortigate, ldap, security

About Myles Gray

Hi! I'm Myles, and I'm a Dev Advocate at VMware. Focused primarily on content generation, product enablement and feedback from customers and field to engineering.

Comments

  1. JB says

    08/09/2016 at 19:13

    You said you installed on your DC? How does it work if AD listens on 389 and 636 by default. Service wont even start for me because of port conflicts.

    Reply
    • Myles Gray says

      08/09/2016 at 19:21

      Because we’re using radius_server_auto it does not use 389 or 636 so no port conflict.

      You can not install on a DC if you want it to service LDAP obviously.

      Reply
      • JB says

        08/09/2016 at 19:56

        Thx for this. I always hated having to use the FortiToken app.

        Reply
  2. Cat Mucius says

    13/09/2016 at 20:04

    The limitation I’ve encountered is that if you need to make authorization decisions on FortiGate according to users’ membership in multiple AD groups – you just don’t have a way to signal the memberships info to the FortiGate. Neither with ad_client, nor with radius_client (in the latter case, though, you can send name of a single group to FortiGate, in a Vendor-Specific Attribute).

    Reply
    • Myles Gray says

      13/09/2016 at 20:25

      I had a ticket open with Duo about this, we ended up doing Wireshark traces (as to why we could pass groups to Duo from FG as an LDAP proxy) – FG is passing the auth request in a different way than Duo expect and would need to fix it on there side.

      If that is fixed, what you want to do would then be possible. I also wanted to provide RBAC on the FG side as well, but, no dice.

      Reply
      • Cat Mucius says

        13/09/2016 at 21:09

        As I understand, it’s a problem pestering any RADIUS-based authentication solution for FortiGate – not just Duo. FortiGate can read group’s name from VSA field in RADIUS reply, but I don’t know any RADIUS server that can read user’s group list from AD and pack them into VSAs. And I don’t know if FortiGate can handle multiple VSAs of the same type.

        So the only mechanism FortiGate can get a list of groups from external source is LDAP.

        There may be two possible solutions, but each has severe drawbacks, and I haven’t checked them in action:

        1. Define local user accounts on FortiGate, but check their passwords via RADIUS (https://forum.fortinet.com/tm.aspx?m=116513). This way, you can add them to as many groups as you like, but the price is double-management of the accounts (or triple, or more, if you have multiple FortiGates).

        2. Duo can also run their own LDAP service, reachable via Internet and SSL-protected. They recommend it for applications other than FortiGate, such as Cisco (https://duo.com/docs/cisco#add-the-duo-ldap-server). They also can pull the groups membership data from AD, if you sync your AD with them (https://duo.com/docs/syncing_users_from_active_directory).
        So I guess you can configure FortiGate just to query their LDAP service for user’s credentials, but:
        – you can just check the one-time passcode this way, not the AD password,
        – you’re relying on Duo in your authorization decisions. So they have technical ability to manipulate them, by elevating or downgrading users’ access level. Maybe paranoid of me, but I wouldn’t trust them that much.

        Reply
  3. adeelahmad84 says

    23/02/2017 at 14:30

    Hi,

    how can I configure the RADIUS remoteauth timeout specifically for a VDOM? Our ISP has provided us with a VDOM and they’re not willing to make the changes globally as they have other customers on other VDOMs.

    Couldn’t find anything on the Fortinet website.

    Thanks

    Adeel

    Reply
  4. Anuja Jadhav says

    31/01/2019 at 11:17

    Hi,
    I have configured ldap authentication on fortigate firewall for web admin login.
    Now, duo is installed on DC server, but it is not working. Am i missing something here?
    Do we need to configure Radius server on DC?

    Reply

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Myles Gray

Hi! I'm Myles, and I'm a Dev Advocate at VMware. Focused primarily on content generation, product enablement and feedback from customers and field to engineering. Read More…

Categories

Tags

active directory authentication CBT cisco datastore dell design esxi fortigate iscsi jumbo frame kubernetes lab linux load-balancing lun md3000i mtu networking NginX nic nsx openSUSE osx pxe readynas san sdelete serial teaming ubuntu vcenter vcloud director vcsa vexpert video VIRL vmdk vmfs vmware vsan vsphere vsphere 6 vsphere beta windows

Subscribe to Blog via Email

Copyright © 2021 · News Pro Theme on Genesis Framework · WordPress · Log in

loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.