Description
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.
Scope
FortiGate.
Solution
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:
- SSL VPN is set to listen on at least one interface
- A default portal is configured (under 'All other users/groups' in the SSL VPN settings)
- An SSL VPN policy exists (a policy with the SSL VPN tunnel interface as the source interface); this will require a user or group to be included in the source options
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:
- FortiGate checks all SSL VPN policies and compiles a list of users and user groups.
- 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 a user logs in with JSmith, for example, and there is a local user entry with ‘jsmith’, it will NOT match.
Note:
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.
- 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.
- 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: 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).
- 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).
- The user will be logged in through 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 through VPN-group2 and has no membership in VPN-group1.
- The user will match any SSL VPN policies that include the group(s) they were authenticated through and will be assigned to the SSL VPN portal as outlined in the Authentication/Portal mapping section of SSL VPN 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. 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.
- 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.
- 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.
- Use SSL VPN realms on FortiGate. SSL VPN 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 SSL VPN 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. See Technical Tip: Combining remote user authentication and client certificates in SSL VPN for details.
Caution:
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.
Related article:
Troubleshooting Tip: Unable to see SSL VPN options under VPN settings
