Technical Tip: A guide to FortiGate Authentication

Debbie_FTNT · ‎11-06-2024

Description

This article aims to provide a basic guide to FortiGate/FortiProxy Authentication, including the most common use cases, methods, and some basic troubleshooting.

Scope

FortiGate, FortiProxy, FortiClient, FSSO.

Solution

FortiGate supports user authentication. Authentication can be used to identify the user, authorize the proper access, and keep track of the users' activity.

There are different features and methods available to achieve user authentication and enforce granular access based on user identity and group membership.

Once a user is authenticated through various means, against local or remote servers, FortiGate caches the user/group information until it times out, the user is disconnected in some way, or the information is forcibly purged.
The user/group information may be used to match traffic to appropriate policies and manage granular access to resources. User information is also added to logs to make user activity more visible.

Note: FortiProxy behaves mostly identical to FortiGate; the information in this article applies to it as well.

Further reading

Common authentication use cases.

Authentication sees wide-spread use in FortiGate. Most commonly, this includes:

VPN.

VPN (Virtual Private Networks) allow remote users to connect to corporate networks without being on-site directly.
They usually require authentication to ensure only authorized users connect to VPN and access the appropriate internal resources.

Further reading:

FSSO.

FSSO (Fortinet Single-Sign-On) is a proprietary method by which agents detect user logins (Windows AD, Syslog, RADIUS Accounting, ...) and share this information with FortiGate.
Users are not required to actively authenticate to FortiGate.

Further reading:

Technical Tip: Explaining FSSO - a primer

Captive Portal.

Captive Portal is a method by which FortiGate intercepts web traffic and either presents a login page itself, or redirects to an external captive portal.
This is commonly used for Guest Wifi and similar open network configuration.
This may also be triggered if unauthenticated traffic has no matching policy, see section '4. Authentication and Policy Matching'.

Further reading:

Explicit/Transparent Proxy, ZTNA.

FortiGate can act as a proxy server in various circumstances, such as Explicit/Transparent proxy configuration or ZTNA. Specific authentication rules may be configured to apply to proxied traffic.
The authentication rules match source, destination and protocol to specific authentication methods, like Kerberos, NTLM or FSSO.
FortiProxy also largely falls into this category.

Further reading:

Admin authentication.

FortiGate also uses authentication for admin logins.
This may be local authentication (password is stored on FortiGate) or remote authentication (password is stored on LDAP/TACACS+/RADIUS/SAML).

Further reading:

Common authentication protocols.

FortiGate is capable of various authentication protocols. The most common include:

LDAP.

LDAP (Lightweight Directory Access Protocol) is a common protocol in Windows AD environments.
It sees frequent use on FortiGate for VPN or admin authentication, but may also serve as backend to captive portal, and is involved in FSSO to determine a user's group memberships.
LDAP uses TCP/389 (unencrypted, sends passwords in cleartext!) or TCP/636 (TLS encryption, also called LDAPS) by default.

Further reading:

RADIUS.

RADIUS (Remote Authentication Dial-In User Service) is another common authentication protocol.
It sees wide-spread use in WiFi, and is also commonly used in captive portal, admin logins, for certificate-based authentication (802.1x), and IKEv2.
EAP (Extensible Authentication Protocol) essentially relies on underyling RADIUS.
RADIUS uses UDP 1812 by default, and has different methods to encrypt password information, consisting of PAP (unencrypted), CHAP (Challenge Hash) and MS-CHAPv2 (Challenge Hash, compatible with Windows AD authentication).

Further reading:

SAML.

SAML (Security Assertion Markup Language) is a newer authentication protocol compared to RADIUS or LDAP. It provides a framework to connect authentication servers with applications/devices/services that require a user to be authenticated.
For example, setting up SAML correctly allows a user to connect to a Microsoft account using their company credentials, instead of having separate credentials for a Microsoft account.
It is browser-based, and on FortiGate is used for VPN, admin authentication and ZTNA/Proxy/Captive Portal.
It uses HTTPS to transport relevant data.

Further reading:

FortiGate: Configung SAML SSO login for SSL VPN
Fortinet: What is SAML?

d. TACACS+

TACACS+ is mostly used for access controls for different network devices in the network.

It is seen widely used with admin account on Fortinet Products and is capable of returning admin profiles/groups for admin user authentication.

Further reading:

User and Group matching.

A user can be authenticated one of two ways in FortiGate:

Directly as user.

A user can be created locally on FortiGate, either as a local user (type password), with credentials stored on FortiGate, or remote (type LDAP/RADIUS), with credentials stored on a remote server.
If this user object is referenced in authentication (like VPN or captive portal) directly, then a resulting login session is associated with the user object directly.
This means FortiGate will NOT check a remote server for group information, but only rely on the locally configured groups that list the user object outright!
This in turn means only policies referencing the user object, or groups that include the user object, will be matched.
Other policies, even if the user is technically member of associated groups, will not be matched.
A user object may be required to assign a second authentication factor, such as FortiToken.

Via group membership.

FortiGate allows for creating user groups with a filter, meaning any user satisfying the filter is considered a member.
If the FortiGate has no local user object matching the user trying to connect, it will instead check against any relevant group.
Relevant groups are any that are refenced in relevant configuration, such as set in captive portal, set in IPsec configuration, or set in policies using SSL VPN or IPsec tunnel interfaces.
FortiGate sends the credentials to whatever remote server(s) are referenced in the user group(s), and will authenticate the user based on the first successful response.
During said authentication, FortiGate also collects group information about the user from the successful server.
This may take the form of an LDAP lookup (memberOf attribute), checking RADIUS attributes in the response (Fortinet-Group-Name attribute), or checking SAML assertions (whatever is defined as group).
Once the user is authenticated in this way, they will match into any policy containing a group they are a known member of.

Authentication and Policy Matching.

Once a user is authenticated and groups are known, any traffic generated by the user will be associated with their user and groups, and match into policies accordingly.
User/group information is a source criterion just like source IP, port, protocol, etc, and is equally used to match policies.
If the user login is removed, any ongoing traffic sessions of this user are immediately purged.
However, taffic may be generated BEFORE the user is authenticated.
If that is the case, such traffic may continue, but will not be authenticated. It will also not be purged if the user login is removed.
This can lead to authenticated and unauthenticated traffic coming from the same source at the same time.

This will be visible in traffic logs, showing traffic with and without user from the same source happening at the same time.

User is already authenticated.

Any traffic generated by an already authenticated user, and properly identifiable (coming from the correct source IP, source port or browser session), matches into policies on a top-down basis, and the first matching policy is applied.
If the first matching policy does NOT require a user/group, then the policy will still be applied.

User is not authenticated.

Any traffic generated by an unauthenticated user may trigger something called implicit fall-through.
If the following conditions are met:

Traffic comes from an unauthenticated source.
There is no matching policy, neither accept nor deny.
There is at least one potentially matching policy with (non-FSSO) user/group set.

Then FortiGate, instead of dropping the traffic due to implicit deny, will instead try to authenticate the user.
It triggers a captive portal, and after the user has provided their credentials, checks them against any possible group and remote server.
If the authentication is successful, the user will hit whichever top-most policy uses a matching user or group object and matches based on source/destination/protocol.

If the authentication is unsuccessful, the traffic is dropped by implicit deny.

This does NOT work if there are explicit deny policies the unauthenticated traffic matches into instead.
The unauthenticated traffic MUST hit implicit deny to trigger implicit fallthrough and attempted authentication.

There is a setting available in the CLI to modify the behavior:

config user setting

set auth-on-demand <always|implicit>

end

Implicit: Default behavior, authentication is only attempted if traffic hits the implicit deny.
Always: If traffic hits an otherwise matching policy that requires authentication, it is immediately forced and policies below are NOT checked.
Enabling this fundamentally changes policy-matching behavior!

Further reading:

Technical Tip: Implicit fall-through feature for user authentication policies in 5.2

Basic troubleshooting.

When trying to troubleshoot potential authentication issues, the first question should be whether the issue is actually an authentication issue.
To this end, the following may be checked:

Check whether user authentication actually happens.
Check whether there are any errors during authentication.
Check if the FortiGate have any authentication-relevant configuration.
- Checking the configuration file for 'config user [...]' elements can help verify this.

If any of the above is answered affirmatively, then there may be an authentication issue.
To identify it more closely, the following should be considered:

Check if the user is or should be authenticated
Verify if the user is member of correct the groups
Check if remote authentication server returns the correct groups
Check if the user authenticates via correct server
Verify if there are any error messages during authentication itself
Verify that all relevant configuration (users, groups, servers, policies) are in place
Verify that FortiGate can reach the required authentication servers
Verify if affected traffic started before or after user authentication

The following resources may be checked more closely:

FortiView -> Users & Devices -> Firewall User Monitor: It displays logins and associated groups. FSSO logins might need to be toggled on to be visible
dia firewall auth list: displays the same information as Firewall User Monitor
dia wad user list: displays Explicit and Transparent Proxy users, ZTNA users
dia sys session <filter|list>: displays current traffic sessions, which contain a username if user is authenticated
Log & Report > System Events > User Event Logs: Records user logins, including what server they authenticated with
Log & Report > Forward Traffic: Compare timestamps of affected traffic against User Event log timestamps to verify when traffic started and when user logged in; the 'duration' field in traffic log provides information on when a session started

In case of unauthenticated and authenticated traffic at the same time from the same source, an easy check is to do the following:

Check in User Event Logs to see when the user authenticated (filter on user name or source IP to find the logs)
Check in Traffic Logs: The start of a session can be calculated based on log timestamp and duration; the authenticated traffic should have started AFTER authentication, and the unauthenticated traffic BEFORE authentication

If this is not the case, please contact Fortinet Technical Support for further assistance.

Useful CLI commands:

List of authenticated users (including FSSO, excluding explicit/transparent proxy):

dia firewall auth list
dia firewall auth filter […]

Logoff user(s) – This can interrupt active traffic and disconnect users!

dia firewall auth clear

Test credentials against remote server (more tends to be more accurate than GUI test):

dia test authserver ldap <LDAP-server in conf> <username> <password>
dia test authserver radius <RADIUS-server in conf> <pap|chap|mschap2> <username> <password>

FSSO debug commands

dia de en (required to make the rest visible)
dia de auth fsso server-status
dia de auth fsso list#dia de auth fsso filter [...]

To debug authentication daemons:

dia de app fnbamd -1 (local, LDAP, RADIUS)
dia de app samld -1 (SAML)
dia de app authd -1 (FSSO)
dia de app fssod -1 (FSSO)
dia de app smbcd -1 (FSSO)
dia de app httpsd -1 (Captive Portal)
dia de console timestamp en (to see timestamps in the debug output)

Further reading: