3.3 Firewall Authentication & FSSO

Why Firewall Authentication Matters

IP addresses change and are shared, so policies based on addresses alone cannot enforce who is doing something. Firewall authentication lets FortiGate identify the user behind a session and apply identity-based policies — policies that match on a user or user group rather than just a source address. NSE 4 tests when FortiGate prompts for credentials and how user identity is learned.

Active vs. Passive Authentication

FortiGate learns user identity in two fundamentally different ways:

The critical exam point: with identity-based policies, FortiGate prompts for active authentication only when it cannot already identify the user. If FSSO (passive) has already mapped that user's IP, no prompt appears. If no identity is known, FortiGate falls back to prompting the user when their traffic matches a policy that requires a user or group.

Local vs. Remote User Authentication

FortiGate can validate credentials against a local database or against remote authentication servers.

Local Users

A local user is defined directly on the FortiGate, with the username and password stored in the device's configuration. Local accounts are simple and self-contained but do not scale and are not centrally managed.

Remote Authentication Servers

For centralized identity, FortiGate queries an external server. FortiOS 7.6 supports three remote protocols:

• LDAP (Lightweight Directory Access Protocol) — queries a directory such as Microsoft Active Directory; FortiGate can bind to verify the user's password and read group membership.
• RADIUS (Remote Authentication Dial-In User Service) — a widely used AAA protocol; RADIUS can also return group/VSA attributes used to place users in firewall user groups.
• TACACS+ (Terminal Access Controller Access-Control System Plus) — separates authentication, authorization, and accounting; common for administrative access control.

For remote users, FortiGate stores no password locally — it forwards the credentials to the server and trusts the server's accept/reject response.

User Groups and Identity-Based Policies

Firewall policies match on user groups, not individual users, so groups are the link between authentication and policy.

FortiOS 7.6 user group types include:

• Firewall group — contains local users and/or remote server references; used in identity-based firewall policies and SSL VPN.
• FSSO group — populated from Active Directory groups learned through FSSO; used for transparent identity-based policies.

When a policy references a user group, a session matches that policy only after the user is authenticated and confirmed to be a member of the group. An unauthenticated user either gets the active-authentication prompt or, if no identity can be established, falls through to the implicit deny.

The Authentication Portal and Disclaimer

When active authentication is required, FortiGate presents a captive portal — a web login page served by the FortiGate. Two related features:

• Authentication portal — the login page where users enter credentials. It can be served from the FortiGate or redirected to an external host.
• Disclaimer page — an optional acceptable-use notice the user must accept before access is granted. A disclaimer can also be shown without authentication purely as an acknowledgement gate.

Captive portal login works cleanly for HTTP/HTTPS traffic because FortiGate can redirect the browser to the portal. Non-web protocols cannot be redirected to a login page, so they generally rely on a session the user already authenticated through the browser, or on passive identification.

Fortinet Single Sign-On (FSSO)

Fortinet Single Sign-On (FSSO) is Fortinet's passive authentication solution. It lets users authenticate once to the network — typically by logging into the Windows domain — and then access resources through the FortiGate without a separate firewall login. FSSO works by mapping each Active Directory user logon to an IP address, so when traffic from that IP hits an identity-based policy, FortiGate already knows the user and group.

FSSO Deployment Modes

FSSO with Active Directory operates in two modes:

• DC Agent Mode — a DC agent (FSSO agent software) is installed on every domain controller. The agent detects logon events in real time and reports them to the Collector Agent. This mode is the most accurate and timely because it captures logons directly at the source.
• Polling Mode (Agentless) — no agent is installed on the domain controllers. Instead, the Collector Agent (or the FortiGate itself, in agentless polling) periodically polls the domain controllers' security event logs for logon events. Polling is easier to deploy because nothing is installed on the DCs, but logon detection is slightly delayed and depends on event-log polling.

The Collector Agent

The Collector Agent is the central FSSO component installed on a Windows server. Its job is to:

• Collect logon events from DC agents or from polling the domain controllers.
• Resolve workstation/user information and maintain the user-to-IP mapping table.
• Send the consolidated user logon information to one or more FortiGate devices.

The FortiGate receives FSSO logon updates from the Collector Agent on TCP port 8000 by default. In DC agent mode, the DC agents talk to the Collector Agent on UDP port 8002 by default. The exam expects you to know the Collector Agent is the component that feeds user identity to the FortiGate in both modes.