In this blog I will demo a simple deployment for MFA & with fortigate SSLVPN service.
MFA means "Multi Factor Authentication"
The general fortinet community has been mislead to believe that you need a overprice forti-authenticator and a fortitokens solutions which does work & works good btw, but comes at a higher price from a CAPEX.
Pls refer to my previous post on fortitoken and Macosx and how the fortitoken works.
http://socpuppet.blogspot.com/2016/01/fortitoken-app-and-macosx-10111.html
$$$ Fortitoken are about on part with Duo cost per-seat and others. $$$ But the fortitoken approach can not be used to MFA other applications. Duo can be used from anything from Citrix , Mail, VPn, DropBox and other systems. They look at each "service" as securing an "application"
So within both
DuoSecurity and
JumpCloud, we will use MFA for simple
1st-factor &
2nd-factor authentication. The 1st factor is strictly
ALL JumpCloud, & by using the RADIUS-aaS service.
The 2nd factor is via the Duo Push notification services & to a registered end-user . They both rely on the Duo-RADIUS-PROXY application.
From the end-user he/she will need a mobile device and the Duo IOS/Android app installed on a mobile phone and actively enrolled.
I believe blackberry is not supported at this time
So the enrollment process is very simple, the Duo Admin will craft a user in the DuoPortal. You only need the
username and
email address of the end-users. They have the means for a bulk deployment if you have quite a few users to enroll at one give time.
A default or custom enrollment email will be sent to the user via email and after a few quick checks and picture of a QRcode you will be enrolled and active.
This follow inline with almost all other TOTP solution from Goog-Authenticator , YubiKey, EntrustIdGuard,Solidpass, Authy, etc..... So I'm not going to go into details on enrollment.
Once you have user(s) in Duo that's activated, each user could be tied to groups and policies based on that "application", this key since you can grant unique access requirements and policies.
userA
VPN & CITRIX access secured MFA
userB
VPN-only via MFA
userC
VPN & Citrix & DropBox & SystemAccess via MFA
userD
VPN & RDP acces via MFA
Think of securing each applications uniquely, and for that specific user or user-groups.
Now when you 1st setup Duo, your DUO admin access will be challenge every time and you can select the identification methods / Push / Text Call
e.g ( DUO admin access )
Within the portal you will toggle down and craft your Duo users as required and the system with send the default or custom enrollment email that explains that the user he is pending a enrollment in companyXYZ MFA solution.
e.g ( here's user:
socpuppets being setup for enrollment , take note of the SSLVPN group I've craft earlier, I will explain that later )
NOTE: I didn't want to go into many details on user enrollment that process is simple and mean video/kb exist from Duo and others on enrollment. If you can't manage a simple enrollment-process everything else here would be to complex for you ;)
Now that we have went briefly over enrollment process let's look at the key Duo items that we will need for configuration of the Duo-Radius-Proxy on our windows or linux host. I will demo the RADIUS cfg file for a DEBIAN based host running in GOOG CLOUD COMPUTE
1st let's review our topology;
in google at my GCPinstance I had port udp:1812 tied to another radius applicaton ( FREERADIUS ) so I choose a new port# just for the Duo-RADIUS-PROXY udp:1822
The fortliclient users will be authenticate, by the fortigate during the SSLVPN connection and based on the RADIUS-Accept/Reject will gain access.
So the deployment steps are simple
1: gather your Duo Portal API details ( available in your portal login for the admin )
2: configure the GCP debian host for Duo RADIUS PROXY
3: gather your jumpCloud RADIUS-aaS details ( ipv4 address, secret ,etc......)
4: hook all of it together
5: start the Duo RADIUS-PROXY and be happy ;)
So if you paid any attention in the Duo Admin setup you where presented a screen with these details
similar to the following;
These informational pieces are very critical you will the need the iKEY and SEC-KEY and target later on for any firewall rules. So save this information off somewhere you can always review it late via the admin access and the DuoPortal.
On the fortigate it's simple but you need a radius server configuration. The Server will be the actual device you have the RADIUS_PROXY configured on. It could be local or in the cloud , but the device must have a secret_define and RADIUS_PORT# . I ve covered this in previous recent post and fortinet has cookbooks out for how to configure radius-auth
http://socpuppet.blogspot.com/2015/10/fortigate-radius-observations.html
e.g
I'm using not-wellKnownPort # of udp:1822 for RADIUS-AUTH in this example. The secrete I defined here would be the same RADIUS secret we will use on the DuoRADIUS_PROXY_CFG
DO NOT CONFUSE THE RADIUS PROXY and the JumpCloud RADIUS-aaS configuration. Think of the DuoProxy as front-end and the JumpCloud is the backend. The fortigate device will TALK to the Duo on the front-end and Duo talks to JumpCloud on the backend.
Now we will setup the Duo-RADIUS-proxy server we will stroke this in the cloud.
The duo-proxy setup can be follow from a simple HOWTO that's available on Duo website
https://duo.com/docs/authproxy_reference
My cfg looked similar to the following on my debian instance
I redacted critical details from this screenshot
After you have the instance up, you can plumb firewall rules in GCP to allow traffic to the RADIUS_PROXY.
By using tcpdump , you can diagnose fortigates ( clients ) that are not able to AUTHENTICATE to RADIUS_PROXY.
sample fw_rule
GCP firewall with udp:1822 set
Okay now that you have all this configured, you can validate function by authenticating a user from the fortigate. If all was correctly configured & working;
FORTIGATE ( radius client )
DuoRADIUS_PROXY
JumpCloud_RADIUS-aaS
Than the end users that
's enrolled and part of the Duo SSLVPNGroup would get a challenge in the fashion of a push to his/her mobile device that they used to enroll.
Here you can Accept or Deny via a simple push notification ( no 6 digit passcode )
Duo allows you to craft "specific text for the push message" so you know what your accepting. Most other systems just blindly send you a notification but for what application, is never known. This is helpful if you use Duo to secure multiple application and what a custom notification message for each application.
Now groups,
Groups in Duo is the key to all things. For the SSLVPN fortigate you can have many groups allow users in just that group. These groups could be inherit into Duo for simplistic matching. So group at the company fortigate(s) could tie back to the same group in DuoSecurity.
In this demo, I have a group name sslvpn for the fortigate SSLVPN solution.
Let's explore some reporting & logs ;
locally the radiusproxy logs are stored at the directory on my linux instance;
/opt/duoauthproxy/log/
It provides MFA related messages for 1st and 2nd factor. Here's example of "chap" login failure from the radius_client and latter a pap login request that was successful.
From
fail_auth you can get lockout alerts and run reports from DuoSecurity portal. One cool thing on lockouts, you can lockout and require MFA-admins to re-active
Or
Set lockdown thresholds and holdout, and after the holdout timer has expired, the account will be re-activated automatically
e.g
Authentication logs within the DuoSecurity portal are very detail and helpful in determining if a request ever made it to Duo and by what applications.
e.g ( csv log-format )
e.g ( json format user enrollment )
So within the Duo portal you can determine with ease the success and failures , and enrollment status for a user. So that's all that it takes.
Enjoy Duo and JumpCloud for your SSLVPN fortigate solutions that need MFA.
Meep .........Meep, I got to run.
Ken Felix
Security Engineer
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
I did client add but you could also have done or add server_connect but in this case we wanted to see what traffic is coming in from where as in the client.
