Fortigate SSL VPN with Azure AD MFA from computers in the domain

Note: The description in the article is based on FortiGate FG-300E with FortiOS version 7.0.6, configured as an FGCP cluster and using VDOM.

Initial State

User and Computer Accounts in Azure Active Directory (AD)

We start from a situation where we operate an on-premises Active Directory domain and use cloud services Microsoft 365, so we also have an Azure AD Tenant. We have set up Azure AD Connect and account replication from On-Premises AD DS. Computers are joined to the AD domain and also registered in Azure AD using Hybrid Azure AD Join.

Azure AD Multi-Factor Authentication (MFA)

Within Azure AD, we can use multi-factor authentication for verification, Azure AD passwordless login and multi-factor authentication (MFA) (official documentation Azure AD Multi-Factor Authentication), thereby securing user accounts more effectively.

Azure AD MFA offers a range of authentication methods that we can use during sign-in. Using additional factors during sign-in can reduce user convenience, so there is an effort to maximize the use of Single Sign-On (SSO). We generally described the verification methods for SSPR in the article Azure AD modern authentication, self-service password reset (SSPR), for MFA the verification methods are more limited.

We always need some device, most often a mobile phone, or possibly a HW token. The available methods for MFA are very briefly:

• verification code - sent via SMS, from an app on the phone, or HW token (One-time Password - TOTP or OATH Verification Code)
• notification - approval of sign-in in the Microsoft Authenticator app
• voice call - automated call to the user's number
• passwordless sign-in - using the Microsoft Authenticator app (in my opinion, the most convenient option)

FortiGate SSL VPN

Fortinet FortiGate with FortiOS offers a range of options for creating and FortiGate SSL VPN configuration. Here we are talking about Remote Access VPN, for connecting remote users to the corporate LAN, operated in Tunnel Mode using the FortiClient client. Within the VPN, we can use various methods and sources of user authentication.

Extension with MFA and Conditional Access

Security Assertion Markup Language (SAML)

Azure AD supports modern authentication (Modern Authentication), which includes the open standard Security Assertion Markup Language (SAML) 2.0. It uses token-based assertions and is often used for SSO within web applications on the internet.

FortiGate (FortiOS) has also supported SAML 2.0 for some time. Support is gradually being expanded, here we are talking about at least version FortiOS 7.0.0 (official documentation FortiOS 7.2.1 - SAML).

SSL VPN Authentication against Azure AD using SAML

On FortiGate, we can configure a SAML SSO Server connected to Azure AD (acting as an identity provider). Create user groups mapped to Azure AD groups. If we use these groups in the VPN configuration, user authentication occurs when logging into the VPN against Azure AD. The user is redirected to the Microsoft website, and only upon successful sign-in (and possibly meeting defined conditions) is the sign-in information passed to FortiGate (authentication data is not passed). Subsequently, the user connects to the VPN.

To configure SAML, we must first create an Enterprise Application in Azure AD. The procedure is described in the article FortiGate SSL VPN sign-in using SAML SSO against Azure AD - Azure AD Configuration.

Then on the FortiGate side, create a SAML SSO Server, define groups, and adjust the SSL VPN configuration. The procedure is in the same article in FortiGate Configuration.

In FortiOS 7.0, we can now also perform the configuration in the GUI. We can create and edit the SAML SSO Server in

• (Global/VDOM) > User & Authentication > Single Sign-On

User groups, with the source SAML SSO Server (added as a Remote Group and we can enter the group's Object ID into Group Name), can be fully created and managed in

• (Global/VDOM) > User & Authentication > User Groups

In SAML terminology, Azure AD is referred to as the Identity Provider (IdP), FortiGate is the Service Provider (SP), and the web browser where the authentication occurs is the User Agent.

Requiring MFA using Conditional Access

Our goal is to use multi-factor authentication during sign-in. In Azure AD, MFA can be enabled for all users using Security Defaults, only for selected users, or detailed control using Conditional Access Policy (conditional access policies). More described in Azure AD passwordless login and multi-factor authentication (MFA).

It is recommended to use Conditional Access, which allows setting various conditions and access controls (including requiring MFA) for selected applications and users.

We will create a Conditional Access Policy, where we set Require multifactor authentication, and assign it to the Enterprise Application created for FortiGate SSL VPN. The procedure is described in Azure AD Conditional Access.

Limiting Authentication Sessions

In the Conditional Access Policy, it may be useful to also set the item Session - Sign-in frequency (official documentation Configure authentication session management with Conditional Access).

By default, a session is created during the first sign-in, and then automatic sign-in (SSO) occurs for a long time. There are various conditions that govern this behavior. Repeated VPN sign-ins then occur automatically and do not require user verification. This is convenient for users but not very secure for VPN connections unless we have super-secure computers, sign-ins, and physical security.

Therefore, we can set the sign-in frequency for our application, for example, in hours. If the user signs in to the VPN again (from the same browser) within a shorter time, automatic sign-in occurs. If the time is exceeded (e.g., the next day), MFA sign-in will be required.

Connecting Only from Domain-Joined Computers

In addition to requiring MFA, we also want to allow VPN connections only from computers that are Hybrid Azure AD Join. On the Azure AD side, this is set simply. We modify the Conditional Access Policy from the previous step and in the Grant section, also check Require Hybrid Azure AD joined device.

When the user signs in, device authentication (Device Authentication) also occurs, and Azure AD identifies the device (Device ID). User authentication is successful (Success) only if the defined conditions are met. Otherwise, it fails (Failure).

Determining device-specific details (Device-Specific Details) requires device authentication (Device Authentication). This is supported only on certain combinations of operating system and browser. Microsoft provides a list of Supported browsers. The browser must have Cookies enabled and must not run in private mode.

On Windows 10, the following are supported (more information at the end of the article)

• Microsoft Edge with a signed-in user
• Google Chrome after installing the extension Windows Accounts
• Mozilla Firefox from version 91 with the setting Privacy & Security - Allow Windows single sign-on

Note: The documentation states that device authentication should also work from macOS (and even iOS and Android). I was unable to get this working. Any advice or information is welcome.

Connecting to VPN using the FortiClient application

If in the VPN connection (VPN Connection) in the FortiClient application we set the use of SAML (Enable Single Sign On (SSO) for VPN Tunnel), an integrated browser will open for authentication against Azure AD. In it, the Microsoft page opens where the authentication takes place.

This browser identifies itself as Chrome, versions I have noted are 69.0.3497 and 87.0.4280 (the same from Windows, Linux, and MacOS, but it likely depends on the FortiClient version). Unfortunately, it does not contain the Windows Accounts extension and does not support device information retrieval. Therefore, in our enterprise application settings, where we require a domain-joined computer, the connection always fails.

FortiClient SAML Authentication in an External Browser

The solution is to use an external browser for authentication, which is set as the default in the operating system. This option was added in FortiOS 7.0.1 and FortiClient 7.0.1.

In the SSL VPN configuration of FortiGate, we set the local port for redirection to FortiClient after successful authentication. On this port, FortiClient temporarily listens and the Authentication ID is passed. The default TCP port value is 8020.

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

In FortiClient, we set the VPN connection by checking the options:

• Enable Single Sign On (SSO) for VPN Tunnel
• Use external browser as user-agent for saml user authentication

In the XML configuration file of FortiClient, this is set as:

<sso_enabled>1</sso_enabled>
<use_external_browser>1</use_external_browser>

Sign-In and VPN Connection Process

When connecting to the VPN, the username and password are not filled in, but there is a SAML Login button that triggers remote authentication with Microsoft.

The sign-in process is as follows

• in FortiClient, click on SAML Login
• FortiClient starts listening on the defined port (default TCP 8020)
• https://vpn-sso.firma.cz/remote/saml/start?redirect=1 - FortiClient opens the SAML VPN connection address in the (default) web browser in the system
• https://login.microsoftonline.com/<Tenant-ID>/saml2?SAMLRequest= - redirects to the SAML Login URL (set in both Azure AD Enterprise Application and FortiGate SAML configuration - idp-single-sign-on-url) to complete SAML authentication with the Identity Provider
• standard modern authentication with Microsoft occurs according to the set parameters and methods
• https://vpn-sso.firma.cz/remote/saml/login - upon successful sign-in, we are redirected to the Sign On URL on FortiGate (set in Azure AD Enterprise Application and FortiGate SAML configuration - single-sign-on-url)
• https://127.0.0.1:8020/?id=ece086fa2811e6a) - redirects to localhost and the defined port, passing the Authentication ID to FortiClient and FortiGate completes SAML authentication with this ID
• FortiClient continues establishing the VPN tunnel, stops listening on the port

If the sign-in in the web browser was successful, a message appears that the VPN is connecting and the browser window can be closed.

FortiClient continues establishing the VPN. Only now does the information Status: Connecting appear and after a while, the percentage.

If an error occurred, the browser displays error information and ends on the Microsoft page. FortiClient waits and receives no information.

We must terminate with the Cancel button.

Errors during Azure AD Authentication

During authentication within Azure AD, an error may occur and the authentication will not proceed. Microsoft modern authentication occurs in our Tenant. First, user verification must occur, which in our case requires MFA. It depends on the user's settings, what verification methods are available, but the dialog is otherwise standard. If an error occurs during verification, the information is usually sufficient to identify the problem.

It continues with checking the conditions set in the Conditional Access Policy. Here we have specified that it must be a sign-in from a Hybrid Azure AD Join computer. Azure AD must obtain information about which computer it is and verify that it is correctly registered. If one or the other fails, information is displayed. There are several ways it looks. It also depends on the browser used and MS adjusts the texts over time. It does not always provide us with the correct data on where the problem occurred.

If we authenticate in the integrated browser in FortiClient. We learn that we must connect from domain-joined devices and that our browser is not supported.

Example of authentication in Firefox. The first image is from a computer that is only registered in Azure AD. In the browser, Windows SSO is enabled, yet we get the information that the browser is not supported. The second image is from a domain-joined computer, but without Windows SSO enabled.

Example of authentication in Microsoft Edge. From a computer that is only registered in Azure AD, the work account is signed in.

Example of authentication in Google Chrome. The first image is from a computer registered in Azure AD, with the extension installed and a new Feature Update. The second image is from a domain-joined computer, with the extension installed, but an old version of Windows 10.

From the past, I have saved an image that informs that the computer must be domain-joined but does not state that an unsupported browser is used.

What to Check When Authentication Fails

We can check that we have a corporate Microsoft account added in Windows. In Settings - Accounts - Email & accounts in the section Accounts used by other apps.

In the command line, we can verify that the computer is connected to Azure AD.

C:\>dsregcmd /status
+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

     AzureAdJoined : YES
  EnterpriseJoined : NO
      DomainJoined : YES
        DomainName : COMPANY

We can also check this in the Azure Active Directory admin center - Devices.

Of course, also check that the given conditions (settings) are met in the browser used. We can also try another browser, preferably the latest version of Microsoft Edge.

Verify the Windows version, i.e., the installed Feature Update, to be at least 1703 (ideally the latest). This hint is provided by Chrome, where sign-in does not work on an older version. In practice, it does not work on an older version in Firefox either. After updating Windows, it started working in both browsers. Edge should work even on an older version according to the information.

It is also good to review the Azure AD logs. For tests, we do not always need to sign in to the VPN. It is enough to open a page in the browser where a corporate account is used for sign-in, such as https://www.office.com.

Then we look at the sign-in logs in the Azure Active Directory admin center. Best for the given user Users - user - Sign-in logs (logs appear here with a few minutes delay). We open the selected log and switch to the Device info tab. We should see the device ID and that it is domain-joined. Various possibilities:

Multiple VPN Connections on FortiGate with Different Authentication

FortiGate allows combining various authentication options within VPN connections (some users can authenticate against an LDAP server and others against Azure AD). We achieve this by creating a user group, to which we add various Remote Groups. Or by setting multiple group mappings in the VPN configuration.

The second option is to create multiple different VPNs or profiles (or however we name them), which we distinguish by different addresses (SSL-VPN Realm - Virtual Host). In each VPN, we can use different authentication or other parameters.

We can also create multiple Enterprise Applications in Azure AD and assign different Conditional Access Policies to each. In one application, we can require domain-joined computers, in another, we can restrict connections from certain locations (IP addresses), and in another, not require MFA. On FortiGate, we create a SAML SSO Server for each enterprise application and user groups (differently named) for each server. The group determines what authentication and conditions the signed-in user had to meet. We use the groups in Firewall policies and can control access in various ways.

Browser Settings for Device Authentication and SSO Use

To use a Microsoft or work or school account with credentials stored in the Windows 10 or 11 system in the browser, certain settings must be made. This is also necessary to use some conditions from the Conditional Access Policy.

Mozilla Firefox

In Firefox version 91 on Windows 10 or 11, a new feature Windows single sign-on (SSO) was added. It is enabled in the settings (How to enable Windows SSO login in Firefox)

• click on the menu (three lines button) - Settings
• tab Privacy & Security
• in the Logins and Passwords section, check Allow Windows single sign-on for Microsoft, work, and school accounts

Google Chrome

We need to install the official Microsoft extension from the Chrome Web Store, called Windows Accounts (Microsoft states that alternatively, the Office extension can be used). It requires at least Windows 10 version 1703.

Settings via Group Policy

For Firefox, we can download administrative templates ADMX (Customizing Firefox Using Group Policy (Windows)) and use them for configuration via group policies.

Enabling Windows SSO is done in the User Configuration or Computer Configuration path /Policies/Administrative Templates/Mozilla/Firefox/ policy Windows SSO set to Enabled.

For Chrome, we can also download administrative templates ADMX (Set Chrome Browser policies on managed PCs) and use them to automatically install the extension Windows Accounts.

This is done in the User Configuration or Computer Configuration path /Policies/Administrative Templates/Google Chrome/Extensions/ policy Configure the list of force-installed apps and extensions set to Enabled and under Show enter the specified application

ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx)

For Microsoft Edge, we can set a number of parameters via group policies (Download and configure Microsoft Edge for business). For example, in the User Configuration or Computer Configuration path /Policies/Administrative Templates/ Microsoft Edge/ policies

• Browser sign-in settings
• Configure whether a user always has a default profile automatically signed in with their work or school account