FortiGate SSL VPN login using SAML SSO against Azure AD

Note: The description in the article is based on FortiGate FG-300E with FortiOS version 6.4.6. It is configured as an FGCP cluster and uses VDOM. Supplemented with a few new features from FortiOS 7.0.5.

The configuration consists of setting up Azure AD, which means creating an Enterprise Application. And in FortiGate settings, where we create a SAML server, define groups and create or modify the SSL VPN configuration. Here we'll assume that we have SSL VPN set up (we discussed this in detail in previous articles) and we'll be creating a new SSL VPN Realm. So we'll keep the VPN with the original authentication and add a new connection where SAML SSO against Azure AD will be performed.

I first tried this setup on FortiOS 6.2.9, but it didn't work at all. The SAML debug was empty for all attempts. When I upgraded to FortiOS 6.4.6, everything started working right away. Useful new features were introduced with a further upgrade to FortiOS 7.0.5.

Some mentions state that full SAML support is in FortiClient from version 6.4.0. I primarily tested with FortiClient VPN 7.0.0.

Documentation

A number of things were described in the previous article.

• FortiGate Admin HTTPS login using SAML SSO against Azure AD

Microsoft has a nice article, but it doesn't address all the details for FortiGate.

• Tutorial: Azure Active Directory single sign-on (SSO) integration with FortiGate SSL VPN

If we didn't want to use SAML, there's also the option of a plugin for the RADIUS server (Microsoft NPS).

• Integrate your VPN infrastructure with Azure AD MFA by using the Network Policy Server extension for Azure

Fortinet official documentation.

• Configuring SAML SSO login for SSL VPN web mode with Azure AD acting as SAML IdP
• FortiOS 6.4.0 - SAML SP for VPN authentication

Some guides from the internet.

• FortiGate SSL VPN with Azure MFA using SAML
• Azure SAML authentification for FortiGate SSL VPN (with Azure MFA)

Configuration videos on YouTube

• YouTube - Configure Fortigate SSL VPN to use Azure AD as SAML IDP (MFA / Conditional Access)
• YouTube - Implementation Guide - FortiGate SSL VPN with Microsoft Azure SAML 2FA

Azure AD Configuration

The configuration is quite well described in the Microsoft article Tutorial: Azure Active Directory single sign-on (SSO) integration with FortiGate SSL VPN. Moreover, this part is very similar to the description in the previous article FortiGate Admin HTTPS login using SAML SSO against Azure AD.

Creating an Enterprise application from the gallery

• Azure Active Directory admin center - Enterprise applications
• New application - we create a new application
• in the gallery, we search for the application FortiGate SSL VPN and click on it
• we enter a name (we can leave the original) and click on Create

Assigning users

• under Manage we click on Users and groups
• we add Azure AD users or groups who will be able to log into this application (and thus into SSL VPN)

On FortiGate, we can include all users in one group and treat them the same. Or use groups in Azure AD, pass this information to FortiGate and create corresponding groups based on it.

When using groups, we need to know their Object Id. After adding a group, we click on it and copy the ID.

Setting up SAML SSO

• under Manage we click on Single sign-on
• as the SSO method we select SAML

We set up individual parts of the configuration by clicking on Edit.

1 Basic SAML Configuration

We create a new FQDN which we'll use for the SSL VPN Realm as a Virtual Host. We direct this DNS record to the public IP address where FortiGate listens for SSL VPN. In the examples, we'll use vpn-sso.company.com. We'll use this hostname in the paths below. Where possible, Default must be checked.

• Identifier (Entity ID): https://vpn-sso.company.com/remote/saml/metadata
• Reply URL (Assertion Consumer Service URL): https://vpn-sso.company.com/remote/saml/login
• Sign on URL: https://vpn-sso.company.com/remote/saml/login
• Logout Url: https://vpn-sso.company.com/remote/saml/logout

2 User Attributes & Claims

• we add a new Add new claim, name username and for the value Source attribute we select user.userprincipalname
• we edit the existing claim with the value user.groups and enter the name group

3 SAML Signing Certificate

• we download and save the certificate Certificate (Base64)

4 Set up FortiGate SSL VPN (the application name is used here)

• we'll need the values from here for setting up on FortiGate
• these are Azure AD SAML addresses

FortiGate Configuration

Uploading the certificate

• (Global/VDOM) > System > Certificates - Import - Remote Certificate

We upload the certificate that we downloaded from Azure AD. It gets an automatic name, which we can optionally change in the CLI.

FW (global) # config certificate remote 
FW (remote) # rename REMOTE_Cert_1 to Azure_SSO_VPN

Creating a SAML server record for the Azure AD application

• CLI Reference - config user saml

We're setting up the connection to Azure AD. It's the same as configuring an LDAP or RADIUS server (but we must do it in CLI, in FortiOS 7.0 it can also be done in GUI). We need various details from the previous steps, which we'll use in individual parameters. The values must exactly match the data in Azure AD. We name the record in some way (here Azure.AD) and we'll use the name when creating groups.

config user saml
    edit "Azure.AD"
        set entity-id "https://vpn-sso.company.com/remote/saml/metadata"
        set single-sign-on-url "https://vpn-sso.company.com/remote/saml/login"
        set single-logout-url "https://vpn-sso.company.com/remote/saml/logout"
        set idp-entity-id "https://sts.windows.net/bb9528c8-3d14-4888-91fd-baeeb2XXXXXX/"
        set idp-single-sign-on-url "https://login.microsoftonline.com/bb9528c8-3d14-4888-91fd-baeeb2XXXXXX/saml2"
        set idp-single-logout-url "https://login.microsoftonline.com/bb9528c8-3d14-4888-91fd-baeeb2XXXXXX/saml2"
        set idp-cert "Azure_SSO_VPN"
        set user-name "username"
        set group-name "group"
    next
end

Set values

• the first three values are FortiGate addresses (we entered them in the Azure AD application under Single sign-on step 1)
• the next three values Identity Provider (IdP) we copy from the Azure AD application Single sign-on step 4
• followed by the name of the certificate that we uploaded to FortiGate (Single sign-on step 3)
• the last two values correspond to the claim naming from the Azure AD application Single sign-on step 2

Optionally, we can also set a certificate that FortiGate will use when connecting to Azure AD.

        set cert "Fortinet_Factory"

Creating user groups mapped to groups from Azure AD

We must create groups in CLI. After creation, the group is displayed in GUI, but it doesn't show members.

We enter the corresponding group name and set the defined SAML server, which we created in the previous step, as members. If one group is enough for us, that's all. All users who authenticate within the Azure AD application will be members of this group.

When we want to create multiple groups corresponding to groups in Azure AD, we define a rule where we enter the Object Id of the group in Azure AD as the Group Name.

config user group
    edit "G VPN VIP Azure"
        set member "Azure.AD"
        config match
            edit 1
                set server-name "Azure.AD"
                set group-name "46a6ad2e-b977-4428-baa2-ff19e6fXXXXX"
            next
        end
    next
end

Note: If we want to add the option to log in (or switch to it) via Azure AD to an existing SSL VPN, it's easiest to add SAML users (and possibly the appropriate filter) to an existing group. We don't have to modify the SSL VPN settings and policies and everything works right away. The disadvantage is that we can't tell where users authenticated (if we have LDAP and SAML in the group, for example, we'll only see the group name). If we create a new group for the new authentication method, we can distinguish the authentication method by its name.

Creating a new SSL VPN Realm

We can use only the default (root) VPN Realm, then we don't need to worry. Here we'll create a special VPN Realm (URL address) for logging in using Azure AD.

• (VDOM) > VPN > SSL-VPN Realms

We can create our own VPN Realm in the GUI (we must have this feature displayed - Feature Visibility). We enter its name (here sso) and we can modify the login screen for the web (for example, change the name for easier identification). Then we must go to the CLI and set the Hostname (Virtual Host).

config vpn ssl web realm
    edit "sso"
        set virtual-host "vpn-sso.company.com"
    next
end

SSL VPN Settings - Assigning Realm and Groups

• (VDOM) > VPN > SSL-VPN Settings

In Authentication/Portal Mapping, we create a new assignment of the group that contains users from Azure AD, the VPN Realm we created in the previous step, and the prepared VPN Portal (which determines specific properties of the VPN connection).

Modifying Firewall Policy - Policies for VPN Client Communication

• (VDOM) > Policy & Objects > Firewall Policy

To the existing policy for VPN client communication, we add the user group that contains users from Azure AD. Alternatively, we create a new policy. The policy must have the incoming interface set to SSL-VPN Tunnel Interface and we specify user groups and address ranges as the source. Until a user (group) is part of the appropriate policy, they cannot log in to the VPN.

Setting Login Timeout

When we use SAML Login in FortiClient, a login dialog from the external system (Azure AD) opens. By default, there's a 10-second timeout set. Many people can't enter their login credentials in that time, so it's necessary to increase this value.

config system global
   set remoteauthtimeout 60
end

Debug SSL VPN and SAML

To troubleshoot issues, it's best to enable debug mode for a specific area in the CLI. The basic one is debugging the SAML protocol itself.

diagnose debug application samld -1

We can add SSL VPN debugging to that.

diagnose debug application sslvpn -1

Optionally, we can also debug Remote user authentication (fnbamd is Fortinet non-blocking authentication daemon). This displays messages from all remote authentication methods (there are usually many).

diagnose debug application fnbamd -1 

We can enable time display for individual records and turn on debug overall.

diagnose debug console timestamp enable
diagnose debug enable

To turn off debug mode, we can use:

diagnose debug disable
diagnose debug reset

Logging into SSL VPN using SAML SSO

Web Interface

If we have only the SAML authentication method defined on the given SSL VPN Realm (assigned groups mapped to SAML), then after opening the page, it automatically redirects to SAML login. If we have groups from different authentication methods, a login dialog is displayed with an added Single Sign-On button.

FortiClient VPN

We create the connection in FortiClient by entering the address we defined for the VPN Realm (Remote Gateway), and check Enable Single Sign On (SSO) for VPN Tunnel.

When connecting, no username and password are entered, but there's a SAML Login button that initiates remote authentication with Microsoft.

It's important to note that for authentication, it doesn't open a browser installed in the OS, but an integrated browser in FortiClient. This identifies itself to Azure AD as Chrome 69.0.3497 (the same for Windows, Linux, and macOS).

Using Multi-Factor Authentication (MFA) with Conditional Access

One of the reasons for setting up VPN user authentication against Azure AD might be an effort to increase login security. Today, multi-factor authentication is increasingly required. We can solve this directly on FortiGate, as described in FortiGate two-factor authentication using OTP. But Azure AD offers more options.

We can have MFA (Multi-Factor Authentication) in Azure AD turned on for everything or control it using Conditional Access policies and enable it only for specific applications. General information can be found in the article Azure AD passwordless login and multi-factor authentication (MFA).

A good option is to create a Conditional Access policy that requires MFA (Require multi-factor authentication). Set this for our Enterprise application, which we've named FortiGate SSL VPN here. A more detailed procedure is provided in Azure AD Conditional Access.

Identifying Company Devices When Accessing VPN

I think it's a legitimate requirement (some standards require that we can only allow managed devices into the internal network) when we want to allow connection to (a certain type of) VPN only from company or approved computers. But how to identify them during connection?

Client-side Checks

• FortiGate SSL VPN Host Check - client checks on connection

One option could be to perform certain checks on the client (Host Check). However, for this, we need the paid version of FortiClient (not supported in the free version FortiClient VPN 6.2 and newer).

According to information, it has been added back to the free version FortiClient VPN 7.0.3 - FortiGate-powered host check for free VPN client.

Computer Certificate Authentication

• FortiGate certificate authentication to SSL VPN

Another option is to issue a certificate to the given computers. The VPN connection is set to require it. In FortiClient, the certificate is selected and used at the beginning of the connection (followed by standard login with username and password).

However, the problem arises when we want to use SAML. As soon as we check Enable Single Sign On (SSO) for VPN Tunnel in FortiClient, the option to select a Client Certificate disappears. I tried to set everything through an XML configuration file, but FortiClient doesn't use the certificate when connecting to FortiGate.

Conditional Access and Azure AD Joined or Compliant Devices

I've newly described this area in the article FortiGate SSL VPN login using SAML SSO against Azure AD.

• How To: Require managed devices for cloud app access with Conditional Access
• Azure AD Conditional Access

Using the features of Azure AD seems the best to me. In the Conditional Access policy, we can allow access only from certain devices (Compliant Device Requirement).

There are two main options:

• Require Hybrid Azure AD joined device
• Require device to be marked as compliant

During login, device authentication (Device Authentication) also occurs, and the entire authentication passes if the user is successfully authenticated and the given conditions are met. In the policy, we can set that for logging into FortiGate SSL VPN, a device joined to the domain is required (Hybrid Azure AD Join). If we use Microsoft Edge and log into the web SSL VPN, we connect from a domain-joined device. If it's not in the domain, we get information and can't connect.

Update. If we have new versions of both FortiOS and FortiClient, this is indeed the best option. I've been adding information below and now have practical experience. For authentication, we use an external (default) browser. Edge, Chrome, and Firefox are supported (all on Windows, according to documentation something should work on macOS too, but I haven't got that working yet). In the Conditional Access policy, we allow access only from Hybrid Azure AD joined devices (requiring compliant devices through Intune would probably work the same). During login, Device Authentication occurs, and only if it passes, we are logged in. It might be useful to adjust the Session - Sign-in frequency item in the Conditional Access policy to a reasonable value (several hours). Because otherwise, in most cases, automatic login (SSO) occurs for many days. This might not be entirely safe for VPN (if we don't have super-secured computers and logins to them).

The problem arises when we try to connect using FortiClient. Even if we're connecting from the correct device, we can't connect. We get information that our browser is not supported.

Detecting device-specific details (Device-Specific Details) requires device authentication (Device Authentication). This is supported only on certain combinations of operating system and browser Supported browsers. On Windows 10, Microsoft Edge is supported (the user must be logged in), Internet Explorer and Google Chrome after installing the Windows 10 Accounts extension.

Updated - support has also been added to Firefox from version 91. It must first be enabled in the Privacy & Security settings - Allow Windows single sign-on ... (Windows SSO).

The problem is that FortiClient uses an integrated browser that does not support device information retrieval. Therefore, we cannot use these restrictions in Azure AD.

Updated 27.8.2021 - FortiClient SAML authentication in an external browser

I found out that FortiClient 7.0.1 added an option (checkbox in the VPN connection configuration) Use external browser as user-agent for saml user authentication. This is available if we enable Enable Single Sign On (SSO) for VPN Tunnel. Alternatively, it can be set in the XML configuration

<use_external_browser>1</use_external_browser>

I found a nice description in the article Using a browser as an external user-agent for SAML authentication in an SSL VPN connection. Unfortunately, configuration on FortiGate is also required, which is available only from FortiOS 7.0.1.

config vpn ssl settings
    set saml-redirect-port 8020
end

So I haven't practically tested it. If FortiClient 7.0.1 is set, no change occurs and the integrated browser still opens.

Updated 4.4.2022 - I upgraded to FortiOS 7.0.5 (which has a number of issues) and tested that using the default browser really works. FortiClient opens the address https://127.0.0.1:8020 in the browser (according to the defined port on FortiGate).