This site uses cookies to serve our services. By using our site, you acknowledge that you have read and understood our Cookie Policy and Privacy Policy.
Menu
Whilst it is not uncommon to use RADIUS authentication with a VPN appliance, SAML-based single sign-on authentication is a much cleaner and more versatile method of authentication.
Thankfully, IBM Security Verify integrates with Fortinet VPN via RADIUS or SAML authentication. In this article, we’re going to talk about both options but focus on SAML as the preferred option.
For a list of reasons why you should consider this, scroll down and continue reading. Otherwise, for a technical walkthrough on how to configure Single Sign-on, send your staff the GitHub repo link below.
Below is a list of things that they will need to configure SSO:
The best way to be alerted about our new news articles is to follow us on Twitter or LinkedIn. If you’d rather be notified by email, fill out the form below.
Scan the barcode below to open this article up on your mobile device and continue reading this on the go.
In almost all instances, your Identity Provider (IdP) will integrate with Active Directory. This means your VPN users will authenticate with the same password they use when signing into their corporate PCs. Whether your VPN users authenticate with SAML, RADIUS or LDAP, that experience will not change.
The main reason for using RADIUS or SAML over LDAP is increased security, more specifically, multi-factor authentication and conditional-access policies.
In short, you can, and you’ll be just fine. The main difference is user experience.
We’ll explain this a little better when deep-diving into conditional-access policies, but when using a RADIUS client your choice of which authentication factors you can use with your VPN is limited. More specifically, you are likely limited to only using push notifications on your mobile device.
Push notifications work great when you’re working from home but not so great when you’re travelling abroad. When travelling, your data roaming might be disabled or limited. Also, MDM policies can restrict your mobile phone from connecting to free, unsecured WiFi. That means you can potentially only have one internet-connected device, your PC. When you use SAML authentication that’s not a problem. You can still complete your two-factor authentication with OTP, SMS, Voice and other authentication factors you configure in your IBM Security Verify tenant.
Often overlooked, but the user experience is generally better when using SAML authentication.
I am going to assume you protect other services with IBM Security Verify. For example, a SaaS application like ServiceNow. Because ServiceNow is so important to your company’s day-to-day operations, signing into ServiceNow is likely one of the first things all of your employees do. In fact, the VPN user is likely trying to get into the office over VPN because of a ServiceNow ticket.
Since signing into ServiceNow involves authenticating with IBM Security Verify, that authentication with IBM Security Verify has already happened, and when the VPN user launches the FortiClient VPN Client, they do not need to enter their username and password again.
Hold your horses, Cowboy! No need to worry. No one is bypassing anything!
The VPN user still needs to complete your multifactor authentication policies set in Verify before being permitted to connect to the Fortinet VPN. The only thing you’ve saved them from doing is having to re-enter their username and password. The video above shows this beautifully.
This is more impactful than you think. It is good practice to automatically terminate VPN connections when idle for an extended period. Assuming you use RADIUS at the moment, the frustration is that VPN users need to then go back through the process of entering their username and password again. When using SAML authentication, they do not need to keep doing that. They only need to complete the MFA challenge your IBM Security Verify policy mandates.
SAML is considered a better approach for VPN authentication because it will give you more options for conditional access policies and authentication factors.
For the uninitiated, conditional-access policies allow you more flexibility and control over your security policies. For example, outright block access from adversary countries. Require Fingerprint/Face ID for access requests outside of your home state/country. Allow SMS as a second factor of authentication when within the same state. You can be stricter or more permissive with your security policies based on conditions like these and others.
Also, as mentioned earlier, relying too heavily on push authentications can hinder your remote users when they only have a single internet-connected device at a conference, airport, hotel or duration-limited WiFi hotspot. As shown in the video, when using SAML, your VPN users are taken to the IdP MFA challenge page and presented with a selection of options, allowing them to choose a different authentication factor like SMS or Voice, which at times, can be more reliable for travelling users.
When you use SAML authentication, you get access to these and other conditional-access policies that help you strike the right balance between security and user experience (UX).
RADIUS integrations with Active Directory (AD) often require an additional AD service account.
Generally, this is a low-privileged service account used to connect to AD and check authorisation. For example, checking if the authenticating user is a member of the Active Directory security group that authorises VPN access. SAML, on the other hand, does not require this. Authentication between the VPN appliance and your IdP occurs over an encrypted HTTPS which your browser happily proxies.
The more integrations you have using these service accounts, the larger your attack service. Corporations with strict security requirements will use a Privilege Access Management (PAM) service like IBM Security Verify Privilege Vault to rotate these service credentials, but these sorts of accounts are almost always overlooked since they post “low risk” to the network.
Let’s also not forget the API Client you likely created in your IdP to facilitate your RADIUS server communicating with your IDaaS. Those are basically the cloud equivalent of an AD service account.
In summary, there is no wrong answer for which option works best for your VPN authentication. It all boils down to which method you prefer or feel most comfortable with.
This article and technical how-to are meant to get you started. I’m sure as time progresses, there will be enhancements to Fortinet and SAML-based authentication you should follow, so remember to keep a heavy eye on the Fortinet Support articles for their latest advice on VPN single sign-on.
Subscribe for latest articles and resources
Sign up to receive updates, promotions, and sneak peaks of upcoming products. Plus 20% off your next order.
