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.
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:
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:
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).
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).
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!