Fortinet NSE4_FGT_AD-7.6: Firewall User Authentication and FSSO
Identity-aware firewall policy answers a different question from administrator login security. An administrator authenticates to configure a FortiGate; a firewall user must be identified or authenticated so the device can decide which network resources that person may reach. Confusing those workflows can produce policies that look user-aware but actually match only source addresses or stale identity assumptions. FortiOS 7.6.0 offers active and passive identification methods, each with different dependencies and failure modes.
The NSE 4 FortiOS 7.6 Administrator objectives distinguish remote LDAP and RADIUS authentication, active and passive firewall authentication, user monitoring, and the Fortinet Single Sign-On (FSSO) domain-controller and collector-agent models. The useful learning outcome is not a list of identity protocols; it is being able to explain where the username, group and client address came from, how FortiGate associates them, and why a specific firewall policy permits or denies a session.
Plan identity integration in an authorized lab or change window, with test accounts whose group membership and workstation addresses are known. Directory configuration, privacy obligations, RADIUS attributes, and Fortinet connector capabilities vary between organizations. Do not transplant example privileged bind accounts or agent credentials into production. Establish a recoverable network rule before putting business-critical traffic behind a new identity requirement.
Separate firewall-user identities from administrator identities
FortiGate administrative access is governed by administrator accounts, profiles, management network restrictions and the authority to change the appliance. A firewall user, by contrast, is the identity associated with traffic crossing the firewall. The same organization can use Active Directory for both, but their authorization consequences must remain separate. Placing a directory group into an administrative login workflow is not equivalent to making that group eligible for a user-based forwarding policy, and a person with permission to browse an application should not automatically gain access to the FortiGate GUI.
FortiOS user groups can contain locally defined identities or accounts validated through a remote authentication server. Fortinet distinguishes Firewall, FSSO, RSSO and Guest groups because the evidence and matching mechanisms differ. Begin a design by asking whether the policy needs the user to supply credentials interactively, can rely on a trusted recent workstation login, or must handle devices with no human user. Each answer leads to different group objects, session expectations and recovery paths.
A concrete scenario makes the difference clear. An engineering workstation accesses a development service, while a contractor device should reach only a limited portal. The rule should identify which source and destination are controlled, which verified engineering or contractor group can qualify, and what happens when no user identity exists. A broad ‘allow internal’ rule would conceal identity failure; a narrowly written policy exposes it in testable logs. The aim is repeatable user authorization, not a login prompt for its own sake.
Choose active prompts or passive identity before building policy
Active firewall authentication requires the user to complete an authentication exchange that FortiGate can associate with the subsequent traffic. A captive portal is one possible approach: the device redirects an eligible client to an authentication page before granting the intended network access. This may be appropriate for controlled guest or BYOD access, but it introduces a user interaction, compatible browser assumptions, and an explicit session lifetime. Nonbrowser applications, embedded devices and automated service clients can behave badly if a rule unexpectedly requires an interactive login.
Passive identity methods work differently. In FSSO, a trusted upstream mechanism observes a network logon and reports the associated username, IP address and groups to FortiGate; the firewall then evaluates traffic using that identity rather than prompting again. This improves usability for managed workstations but creates dependencies on the collector, the directory, event availability, address freshness and the integrity of the mapping. A missing record is not proof the person is unauthorized, and a stale record is not proof the current device user is the person shown.
Before choosing a method, write down how identity becomes known, how it expires, and how a user recovers when the method fails. Interactive login can fail because of portal reachability, authentication-service outage or browser behavior. Passive login can fail because a domain-controller event was not collected, a group filter suppressed the membership, or an address changed. Test both an expected allow and an expected deny outcome. A system that only tests successful users can hide the security consequence of an unidentified session.
Use LDAP for directory-backed firewall groups with bounded privileges
LDAP integration allows FortiGate to verify credentials and, where configured, group membership against a directory such as Active Directory. For a FortiOS 7.6.0 design, determine the server address, directory naming context, user identifier, group selection, connection security, and credentials needed for the bind operation. Prefer an appropriately secured LDAPS connection, and use a least-privileged bind identity rather than an account with broad domain administration privileges. Confirm the server certificate and trust chain before relying on an encrypted connection as the basis for access-control decisions.
Create the remote LDAP server definition and the FortiOS user group that references the appropriate directory population. The server object alone grants no user access: the group still must be referenced by the intended firewall policy or authentication mechanism. If the organization has nested groups or different identity attributes across domains, test those cases explicitly. A user can authenticate successfully but fail an authorization test when the requested group is missing, stale or mismapped. Record a directory test account and its expected group before changing the forwarding rule.
Validate failure handling as well as connectivity. Temporarily using an invalid test password should be denied, and a user moved out of the permitted group should lose authorization according to the system’s intended refresh and session behavior. If credentials work in the directory but are rejected at FortiGate, inspect the selected account identifier, search base, bind rights, TLS trust and actual group mapping. Do not solve a group resolution error by widening the firewall policy to an all-users exception.
FortiOS 7.6.0 represents an LDAP identity source under User & Authentication > LDAP Servers. Define the server name/address, common-name identifier, base distinguished name and appropriate bind type, then validate directory reachability and the trust of the encrypted LDAP connection before adding the server as a remote member of a FortiOS Firewall user group. Creating the server object does not by itself make a group eligible for transit traffic; use that Firewall group in the actual policy and test with one permitted directory user and one person who authenticates but should not belong to the authorized group. Fortinet’s 7.6.0 diagnostics include diagnose test authserver ldap, but the CLI test exposes a password argument, so do not record real credentials in shared screenshots or unrestricted logs.
Use RADIUS when the network-access workflow belongs to a RADIUS server
RADIUS centralizes authentication decisions for many network and remote-access workflows. On FortiGate, configuring a RADIUS server definition, required shared security information, and a user group provides one way to reference authenticated identities in policies or supported access features. The expected server response and group attributes matter: a successful Access-Accept may prove the password or factor was valid without proving that the intended restricted Fortinet user group was returned. Test the exact user and policy relationship rather than treating every accepted RADIUS exchange as equivalent.
Security and availability are part of the design. Ensure FortiGate can reach the correct RADIUS endpoint and distinguish a timeout from an Access-Reject response. Fortinet recommends encrypted alternatives such as RADSEC over TLS where supported and appropriate; validate the actual version and server configuration before choosing transport. Shared secrets, certificate material and network ACLs must be handled as privileged access infrastructure. If multiple servers are configured, test failover and make sure the alternative server returns compatible identity and group information.
A practical RADIUS test pairs a permitted user with one who can authenticate but should not match the firewall’s authorized group. Observe the client address, RADIUS result, group membership, traffic policy and related log event for both. If access fails, isolate whether the request never reached the server, the server rejected it, the group attribute was not understood, or a higher-priority firewall policy handled the packet. That separation keeps identity troubleshooting from degenerating into unrelated route or inspection changes.
A FortiOS firewall-user RADIUS test begins by defining the selected server as a remote authentication object (the 7.6 family uses User & Authentication > RADIUS Servers or config user radius) with a server name, endpoint and protected shared secret. Bind the server to an appropriate Firewall user group, then use that group in the intended policy. Test a user known to qualify and one that should be denied even if the RADIUS server accepts the credentials; the Fortinet-Group-Name attribute or other supported group association must express the authorization boundary rather than leaving every Access-Accept as equivalent. FortiOS 7.6.0 documents the underlying RADIUS user and group model, while specific RADSEC transports and attribute behavior depend on the configured server and selected FortiOS release. Test with diagnose test authserver radius only in a protected console session because the command exposes the supplied password argument.
Trace FSSO from domain-controller events through the Collector
Fortinet Single Sign-On can map Windows logon activity to firewall identities without requiring a separate prompt for every application. In a DC-agent design, a domain-controller agent observes relevant logon events and sends them to an FSSO Collector agent. The Collector maintains and filters the observations, associates users with relevant groups, and makes them available to FortiGate. In a polling approach, the Collector or another supported connector obtains events from directory infrastructure without requiring the same agent on each domain controller. The supported approach depends on the environment and agent version; it should be verified against Fortinet’s relevant compatibility guidance.
The Collector is not merely a pass-through cable. It may perform user-to-address mapping, group verification, event aggregation and workstation checks. Group filters restrict which identities and memberships are communicated to FortiGate. Poor filter design can make a legitimate user invisible; unnecessarily broad filtering can bring irrelevant groups into the firewall and complicate policy review. Separate the service account used to gather directory evidence from administrator access on the FortiGate. Use least privilege, protect connector communications, and document which systems are allowed to submit authoritative logon information.
On FortiGate, bind the appropriate FSSO connector and groups to the policy that needs them. The visible result should be a current authenticated user or group association, not just a connector status showing connected. Fortinet’s FortiOS 7.6.0 FSSO identity mapping illustrates how group and source-address information can be used by policy. Confirm which integration mechanism the example uses before applying it to a separate Collector-agent deployment. The authoritative test is whether the user, address, group, and traffic rule agree for the intended session.
For exact FortiOS 7.6.0 compatibility, Fortinet’s FortiOS 7.6.0 release-note support table lists FSSO 5.0 build 0316 or later (including OU-aware group filtering) with Windows Server 2022 Standard/Datacenter, Windows Server 2019 Standard/Datacenter/Core, Windows Server 2016 Standard/Datacenter/Core, and Windows Server 2012 Standard/R2/Core. Windows Server 2025 is not in that edition’s list. The DC agent is needed on each participating domain controller in DC-agent mode, while polling mode does not require those local agents. Select the actual FSSO setup and DC Agent package from authenticated Fortinet Support, verify its packaged operating-system installer notes and Collector address/port, and plan the controller restart or change window before installation. Version compatibility is documented here; no Windows installation, domain logon simulation, Collector deployment, or FortiGate lab validation was performed for this article.
Agent-based FSSO and polling mode must not be presented as identical 7.6.0 deployments. In DC-agent mode, a DC agent on the participating domain controllers observes logon activity and sends events to a Collector agent; the Collector associates users, workstation addresses and directory groups before FortiGate applies the FSSO group in its policy. In polling mode a Fortinet connector instead collects the relevant directory events without the same per-DC-agent installation. Before planning a 7.6.0 DC-agent rollout, confirm the Collector/DC agent package’s supported Windows server versions, service-account permissions, event-access method, monitored domains and logoff behavior against the chosen agent build. Those agent-installation parameters are edition-dependent and have NOT been live-tested here; the reliable educational distinction is the event flow and source of the identity mapping.
The FSSO Collector is the intermediary that gathers logon events, correlates the user’s IP and group, and publishes the eligible identity state to FortiGate. For a deployment, identify the intended Collector address, connection trust or credential, group filter, agent-to-collector connectivity and FortiGate connector scope before enabling user-based policy. Confirm the current Collector receives an event from the expected workstation and that FortiGate sees the correct user/group/address—not just a healthy connector status. If the Collector link fails, test the organization’s desired handling of cached user mappings and expired sessions rather than assuming a permanent trusted state. The Collector software build and Windows installation compatibility require the chosen agent release documentation; FortiOS 7.6.0 itself documents the Collector-disconnect logon timeout and verification workflow. Nothing in this description asserts that a DC or Collector installer was actually run.
Fortinet documents the collector-disconnect control specifically for FortiOS 7.6.0 under config user fsso: the logon-timeout setting retains previously authenticated FSSO user mappings for a configured interval after the Collector connection is lost. Its documented range is 1–2880 minutes, with a default of five minutes. A controlled incident test can set the intended value for the named FSSO server, observe authd/fssod disconnect information in a bounded debug session, and use diagnose firewall auth list to compare the user and group mappings before and after timeout. When Collector connectivity is restored, verify the mappings resynchronize and the policy again uses current identity information. The supported FortiOS-side operational behavior is edition-specific; selecting an appropriate Windows DC/Collector agent installer for a particular OS is a separate compatibility review.
Bind verified identity to the actual firewall policy
Identity information becomes an access decision only when the relevant firewall or authentication policy uses it. Define a clear relationship among the source interface, permitted user group, destination, service, and expected action. A broad rule earlier in the table may already accept the traffic, making a later identity-restricted rule appear ineffective. Likewise, a rule using an address-only match might allow packets even when the displayed user group is missing. Review FortiGate firewall policy logic alongside the identity integration so that a policy match can be traced end to end.
Create a negative test deliberately: a workstation with no usable FSSO identity, an account outside the approved group, or a client whose portal login fails should not inherit unrestricted access. If an emergency exception is necessary, constrain it to a documented device or service and set an owner and review date. An ‘unknown user’ policy that permits every destination can turn an FSSO outage into a silent access-control bypass. A fail-closed rule is not always suitable for every business service, but its exception behavior must be understood rather than accidental.
Where identity is shared across VPN or branch networks, check whether the client source address observed by the Collector is the same one FortiGate sees after any NAT or remote-access encapsulation. One machine can have several addresses over time; shared-terminal systems can also place different users behind one address. Those environments may need purpose-specific integration rather than the simplest workstation-to-IP model. Authentication design is therefore part of network architecture, not a separate directory administration task.
Diagnose missing, stale and mismatched FSSO logins
Begin with a known user who has just signed in to a managed workstation. Confirm that the domain-controller or polling mechanism generated an event, the Collector learned it, and FortiGate received the expected username, IP address and groups. Then look for that user in the firewall’s user-monitoring view or the supported diagnostic display. FortiOS can show current FSSO user mappings, which is more useful than a general connector health indicator. If the mapping is absent, investigate the event source, collector authorization, connection, group filtering and clock correlation before editing the firewall rule.
Stale identities deserve separate attention. DHCP renewals, VPN reconnections, laptops changing networks, users signing out, and address reuse can all invalidate a simple username-to-source-IP assumption. An old mapping may remain visible temporarily even while the current user has changed. Review timeouts, logoff handling and reconciliation behavior in the actual FSSO mode. If the Collector goes offline, the system should have a documented rule for how long cached information remains valid and which traffic will be denied or allowed in the meantime.
Finally, use traffic evidence to distinguish a working identity mapping from policy enforcement. One user can be present in the FSSO monitor but match the wrong group or be stopped by an unrelated higher-priority firewall rule. Correlate authentication data with FortiGate logging and troubleshooting: source and destination, policy identifier, user/group, session outcome and time. A clear chain from logon event to group and rule is the best defense against troubleshooting by random policy edits.
The FortiOS Firewall Users monitor is the user-facing place to validate authenticated firewall identities and source-address mapping. Examine the active user, group, source IP and session age before concluding that an identity-aware firewall policy is working. In the 7.6.0 CLI, diagnose firewall auth list provides a scoped list of authenticated IPv4 firewall users; use the supported filters when the deployment is busy. The GUI menu placement can differ by dashboard layout and 7.6 maintenance build, so follow the actual native Firewall Users view rather than a screenshot from a later FortiOS revision. Correlate that identity record with the Forward Traffic policy ID, and test an authorized user, a denied user and a client whose address changed; one successful login alone does not prove current group authorization.
Validate successful access, denial, and identity freshness
An acceptance plan should include at least three meaningful user journeys: a managed domain user authorized through FSSO, a user who must actively authenticate against a remote server, and a user who should fail to qualify for the restricted policy. For each, write down the known source address, expected username and group, intended destination, expected rule, and log evidence. Repeat after a controlled group change or address renewal to learn when the new authorization state becomes effective. A screenshot showing one authorized connection is not proof of correct identity lifecycle handling.
Operate the integration as a dependency with its own monitoring. Track domain-controller event health, Collector connectivity, LDAP/RADIUS server reachability, clock consistency, failed authentications, unknown-user rates, group mismatch events, and policy-denial spikes. Alerting should help operators distinguish missing directory evidence from an actual suspicious login. Avoid retaining more user identity information than the organization needs for security operations and authorized troubleshooting. Directory logs and firewall logs both have privacy and retention implications.
For NSE 4 study and real administration, the durable model is identity source, authenticated group, current source address, firewall policy, and verified traffic result. If any of those five stages is unexplained, the operator cannot be confident that the right user reached the right resource. The same principle applies whether credentials were checked actively by LDAP or RADIUS, inferred through a trusted FSSO observation, or rejected because the evidence was not reliable.
