This article describes a basic understanding of how FortiGate SSL VPN authentication works; how FortiGate determines what groups to check a user against, and common issues and misunderstandings about the process.
FortiGate includes the option to set up an SSL VPN server to allow client machines to connect securely and access resources through the FortiGate.
This requires the following configuration:
In larger environments, SSL VPN setups can grow to be complex, including different user groups with the different portals in the SSL VPN settings, and many different policies for SSL VPN.
At this point, with multiple groups in use, the way FortiGate authenticates SSL VPN users can be a bit difficult to understand intuitively.
The actual authentication process:
When a user tries to connect and supplies appropriate credentials (username and password or certificate), the following occurs:
This is case-sensitive by default. If a user logs in with JSmith, for example, and there is a local user entry with ‘jsmith’, it will NOT match.
See https://community.fortinet.com/t5/FortiGate/Technical-Tip-Description-of-CVE-2020-12812-bypassing-tw... for more about local user authentication being bypassed due to a case mismatch. This can cause two-factor authentication to be skipped as well.
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: these are only queried if no response has been observed from primary servers at all. FortiGate will check the secondary servers once the remote authentication timeout has been reached ('remoteauthtimeout' under 'config system global' in CLI).
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).
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.
The above ignores SAML authentication options, as those rely on additional prompts from the VPN client. This means they may partially bypass the regular SSL VPN policy check and authentication process.
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.
This works as follows:
If certificates are required for some user groups, but not all, this can have unintended interactions with realms. See Technical Tip: Combining remote user authentication and client certificates in SSL VPN for details.
There is a setting for RADIUS servers called 'Include in all user groups' in the GUI, and 'all-usergroup' in the CLI. If this is enabled, the RADIUS server will be IMPLICITLY included in all usergroups, including those that map to LDAP servers. ANY authentication request will also be checked against the RADIUS server.
In this case, ANY member of the RADIUS server will 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.