Technical Tip: A guide to FortiGate Authentication

Debbie_FTNT · ‎11-06-2024

Description

This article provides a basic guide to FortiGate/FortiProxy Authentication, including the most common use cases, methods, and some basic troubleshooting. It links to more in-depth articles where possible.

Scope

FortiGate, FortiProxy, FortiClient, FSSO.

Solution

Table of Contents:

Introduction.

Common authentication use cases.

VPN.
FSSO.
Captive Portal.
Explicit/Transparent Proxy, ZTNA.
Admin Authentication.

Common authentication protocols.

LDAP.
RADIUS.
SAML.
TACACS+.

User and Group matching.

Directly as a user.
Via group membership.

Authentication and Policy Matching.

User is already authenticated.
User is not authenticated.

Basic Troubleshooting.

Useful CLI commands.

Related articles.

Introduction.

FortiGate supports user authentication. Authentication can be used to identify the user, authorize the proper access, and keep track of the user's 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 identically to FortiGate; the information in this article applies to it as well.

Further reading:

Common authentication use cases.

Authentication sees widespread use in FortiGate. This can be split into active and passive authentication, as described in greater detail here:

Technical Tip: Active and passive authentication behavior

Most commonly, this includes:

VPN.

VPN (Virtual Private Networks) allows remote users to connect to corporate networks without being on-site directly.
They usually require authentication to ensure only authorized users connect to the 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 configurations.
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 a backend to the 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 widespread use in WiFi and is also commonly used in captive portals, admin logins, for certificate-based authentication (802.1x), and IKEv2.
EAP (Extensible Authentication Protocol) essentially relies on the underlying 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:

TACACS+.

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

It is widely used with an 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 in one of two ways in FortiGate:

Directly as a user.

A user can be created locally on FortiGate, either as a local user (type password), with credentials stored on FortiGate, or remote user (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 the 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 a 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 referenced 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 matched 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's login is removed, any ongoing traffic sessions of this user are immediately purged.

However, traffic 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's 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 a 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 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 accepting nor denying.
There is at least one potentially matching policy with a (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 that 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:

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 has 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 a member of the correct groups.
Check if the remote authentication server returns the correct groups.
Check if the user authenticates via the correct server.
Verify if there are any error messages during authentication itself.
Verify that all relevant configurations (users, groups, servers, policies) are in place.
Verify that FortiGate can reach the required authentication servers.
Verify if the 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:
diagnose firewall auth list: displays the same information as Firewall User Monitor.
diagnose wad user list: displays Explicit and Transparent Proxy users, ZTNA users.
diagnose sys session <filter|list>: displays current traffic sessions, which contain a username if a user is authenticated.
Log & Report -> System Events -> User Event Logs: Records user logins, including which 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 the user logged in; the 'duration' field in the 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):

diagnose firewall auth list

diagnose firewall auth filter […]

Logoff user(s): This can interrupt active traffic and disconnect users.

diagnose firewall auth clear

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

diagnose test authserver ldap <LDAP-server in conf> <username> <password>

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

FSSO debug commands:

diagnose debug enable (required to make the rest visible)