FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Debbie_FTNT
Staff
Staff

Description

This article describes a basic understanding of how FortiGate SSLVPN authentication works; how FortiGate determines what groups to check a user against, and common issues and misunderstandings about the process.

 

Solution

FortiGate includes the option to set up an SSLVPN server to allow client machines to connect securely and access resources through the FortiGate.

 

This requires the following configuration:

  •  SSLVPN is set to listen on at least one interface
  • a default portal is configured (under ‘All other users/groups in the SSLVPN settings)
  • an SSLVPN policy exists (a policy with the SSLVPN tunnel interface as source interface); this will require a user or group to be included in the source options

 

In larger environments, SSLVPN setups can grow to be complex, including different user groups with the different portals in the SSLVPN settings, and many different policies for SSLVPN.

At this point, with multiple groups in use, the way FortiGate authenticates SSLVPN users can be a bit difficult to understand intuitively.

 

The actual authentication process:

 

A user tries to connect and supplies appropriate credentials (username and password or certificate). Then the following occurs:

 

  1. FortiGate checks all SSLVPN policies and compiles a list of users and user groups

 

  1. FortiGate checks if the user trying to log in matches a local user entry that is outright referenced in the SSLVPN policies, OR included explicitly in one of the user groups.
    This is case-sensitive by default! If for example a user logs in with JSmith, and there is a local user entry with ‘jsmith’, this will NOT match!
    Note: For local user authentication being bypassed due to mismatch in case, as this can cause two-factor authentication to be skipped as well, we have a separate KB: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Description-of-CVE-2020-12812-bypassing-tw...

 

  1. If no local user entry is found, FortiGate looks for any remote authentication servers that are included in the user groups – any LDAP or RADIUS authentication server in any user group in any SSLVPN policy. This can amount to several different servers.

 

  1. FortiGate tries to authenticate the user against all possible authentication servers at once. There is no priority list at present (FortiOS 7.0.3) to influence in what order FortiGate checks credentials against authentication servers.

Note: FortiGate checks against all possible authentication servers in parallel to allow the fastest possible response time and prevent undue wait times during login. It does NOT check against secondary server IPs; those are only queried if no response has been observed from primary servers at all, and FortiGate will check to the secondary servers once the remote authentication timeout has been reached ('remoteauthtimeout' under 'config system global' in CLI).

 

  1. The FortiGate will accept the first successful reply from ANY of the possible servers. If the user is checked against two LDAP servers and two RADIUS servers at the same time, and one LDAP returns a successful reply first, then FortiGate will accept this and abandon the other authentication requests.

Note: If FortiGate receives a failed reply from an authentication server, it will still wait for the others to respond in case one of them might return a successful result. The VPN authentication will only be considered failed in its entirety if all authentication servers returned a failed result or timed out (in the case of timeout, FortiGate would also query any secondary servers first before declaring the authentication failed).

 

  1. The user will be logged in via whatever group(s) the authentication server belongs to, and that line up with the user’s group memberships as fetched from the authentication server.
    -> if the successful authentication server is a member of VPN-group1 and VPN-group2 on the FortiGate, but only returned a membership in VPN-group2 for the user, the user is logged in via VPN-group2 and has no membership in VPN-group1

 

  1. The user will match any SSLVPN policies that include the group(s) they were authenticated via and will be assigned the SSLVPN portal as outlined in the Authentication/Portal mapping section of SSLVPN settings (authentication-rule in CLI), with according web-mode/tunnel-mode permissions, tunnel-IP, split-routing configuration, bookmarks, etc.
    Changing these mappings, removing groups from them or changing the order has NO effect on the actual authentication process! If no explicit portal mapping exists for a user group, any users of this group will simply use the default portal set.

 

Note: the above ignores SAML authentication options, as those rely on additional prompts from the VPN client and thus bypass the regular SSLVPN policy check and authentication process somewhat

 

Result of the above process:

 

As FortiGate checks a user against ALL possible authentication servers based on the SSLVPN policies, this frequently leads to a user being authenticated against an unintended server, such as a user authenticating via LDAP when they should authenticate via RADIUS and provide a second factor.

Two-factor authentication may be skipped unintentionally!

 

 

How to ensure the correct authentication server is used for a user request:

 

There are few options to force user authentication via a specific server, and only that server.

 

A) Ensure there is no overlap in users between different authentication servers
If all authentication servers have separate user databases, only one server can return a successful result. FortiGate will keep an authentication request active while waiting for the first successful reply, even if all other authentication servers return a failure.

This way, the user will be authenticated via the intended groups only, and if the authentication server requires a second factor, this will also be enforced.

 

B) Use a single authentication server that forwards requests to other authentication servers as appropriate.

If FortiGate only contacts a single authentication server, then ensuring the request goes to the correct server and all appropriate factors are applied is in the hands of this authentication server. This could be a FortiAuthenticator, forwarding authentication requests to other RADIUS servers or to LDAP servers based on its own configuration, or any third-party product that may act as a proxy to multiple different authentication servers.

 

C) Use SSLVPN realms on FortiGate

SSLVPN realms on FortiGate allow a narrower selection of what user groups a user is authenticated. In effect, with realms configured, FortiGate does NOT try to authenticate the user against any group used in any SSLVPN policy, but only authenticates the user against groups that are associated with the realm in question.

This works as follows:

- enable SSLVPN realms under System > Feature Select in the FortiGate GUI

- another option is available in the SSLVPN menu, called Realms. These are basically strings that are appended to the VPN URL (or prepended, depending on configuration). As an example, a realm ‘test’ might be created, with the URL ‘/test’

- this realm is associated with a specific group and portal in the SSLVPN authentication/portal mapping section

- if a user connects to https://<FortiGate-vpn:port>/<realm> (for example https://fgt-vpn.domain.org:4443/test or https://192.168.1.99:4443/test), the FortiGate will ONLY authenticate the user against any groups associated with ‘/test’ realm, and all other groups will be ignored. The request will only go to authentication servers associated with the specific group.

This may be used in web mode and tunnel mode.

Note: If certificates are required for some user groups, but not all, this can have unintended interactions with realms; please see https://community.fortinet.com/t5/FortiGate/Technical-Tip-Combining-remote-user-authentication-and-c... for details

 

 

Caution: There is a setting for RADIUS servers, ‘Include in all user groups’ in GUI, called ‘all-usergroup’ in CLI. If this is enabled, then the RADIUS server will be IMPLICITLY included in all usergroups, including those that map to LDAP servers, and ANY authentication request will also be checked against the RADIUS server.
ANY member of the RADIUS server would authenticate successfully, no matter what group membership they have, as the entire RADIUS server and its user database are included in every single user group on FortiGate!

Contributors