Identity-aware firewall control asks a different question from basic source-IP policy: which person or group is associated with the request, and is that association trustworthy at the moment a session is evaluated? The FortiOS 7.6 Administrator exam covers remote LDAP and RADIUS authentication, active and passive methods, and Fortinet Single Sign-On (FSSO). These functions overlap in user access outcomes but use different evidence and communications paths.
Do not treat an authenticated username, an observed Windows login and a firewall group match as synonyms. Each is a separate assertion that may be true or false. Troubleshooting improves when the administrator identifies which stage produced the wrong information.
Decide when firewall policy needs an identity
A traditional allow rule might permit a trusted application subnet to reach a database service. If employees within that subnet have different roles, source IP alone may not express the organization’s access intent. FortiGate identity-based conditions can tie permission to users or groups, using supported local, remote or single sign-on mechanisms.
Before enabling an identity condition, specify how a user should become known to the firewall and what should happen when that identity cannot be established. A rule that requires group membership will not simply revert to the desired group when an endpoint changes address or the identity provider becomes unavailable. That failure mode must be planned, logged and tested.
Fortinet’s FortiOS 7.6 user-group documentation explains how local, remote and FSSO groups can be used in firewall policies and other supported features. In a review, identify both the group object configured on the firewall and the identity source that populates its membership.
LDAP authentication: directory reachability and search context
LDAP allows FortiGate to query an external directory using configured server connectivity, bind details and directory search parameters. A successful TCP connection to the directory host does not guarantee that the chosen bind account can find the relevant user. The directory base DN, search filters, service account privileges, TLS configuration and target domain context may all affect the result.
Fortinet’s documentation for LDAP configuration in FortiOS 7.6 recommends a secure connection, such as LDAPS or STARTTLS as appropriate, and least-privilege directory bind credentials. An overly privileged domain account may make a test work but increases risk if the firewall configuration or secrets are compromised.
A common failure is to authenticate some users successfully while users from another organizational unit fail. This can reflect search base or group mapping rather than a general LDAP outage. Compare the users’ directory location, group attributes and the actual bind/search context before broadening directory permissions or disabling TLS checks.
For protocol context, LDAP and LDAPS transport choices matter because a directory may accept plaintext or StartTLS connections differently from a dedicated TLS endpoint. Port numbers alone do not establish security; confirm the active TLS mode and certificate trust.
RADIUS authentication: request, response, and group claims
RADIUS uses a request-response architecture in which FortiGate communicates with a configured authentication server. The server determines whether the supplied identity or factor satisfies its policy and can return attributes used by the client. Network reachability, shared-secret consistency, server policy and expected return attributes are distinct possible failure points.
The RADIUS protocol model is useful here: a rejected authentication is different from a silent timeout or a successful authentication that supplies an unexpected group. When a firewall group rule depends on a RADIUS attribute, a plain “Access-Accept” is not automatically proof that the correct access group was selected.
Fortinet also documents secure transport options for remote authentication. Its FortiOS identity guidance notes RADSEC over TLS and recommends protecting directory connectivity and administrative identities. Candidates should understand the relative roles of transport protection, authentication decision and authorization group mapping rather than making an unsupported assumption that RADIUS packets are secure simply because they involve a password exchange.
Suppose remote VPN users authenticate but cannot reach the intended internal service. Confirm whether the firewall received the correct group claim, whether that group is referenced by the relevant policy, and whether traffic reaches that policy after the tunnel is established. Deleting and recreating a whole RADIUS server definition is not the appropriate first step if the evidence already proves authentication succeeds.
Active and passive firewall authentication are not interchangeable
Active authentication usually involves a direct user interaction or challenge when FortiGate needs to establish identity. Passive techniques infer identity from trusted external events or mappings. Their operational impacts differ. Active flows can interrupt access with a login prompt; passive mechanisms require dependable events and timely user-to-address associations.
Choose a model that fits the endpoint population. A shared terminal or NAT boundary can complicate assumptions that a single source IP identifies one person. An environment with many domain-joined managed workstations may support event-driven identity association; unmanaged guest endpoints may require a different approach. The security design should not assume that every IP address uniquely identifies a user across all network segments.
Authentication errors must be separated from identity mapping errors. If a user can sign in but traffic matches no group-aware policy, review policy membership and freshness of user mappings. If the firewall cannot authenticate the user at all, examine the actual local or remote authentication path rather than tuning an unrelated forwarding rule.
FSSO: observe login events and maintain usable mappings
Fortinet Single Sign-On can associate Windows or other supported user logins with client addresses and groups so that FortiGate policies can evaluate user context. The official FSSO documentation describes the responsibilities of a Collector agent and Domain Controller agents, as well as supported polling arrangements. The DC agent reports relevant logon events to the collector in agent mode; the collector can forward mappings to FortiGate. Those components should not be described as one direct DC-to-firewall pipeline.
In polling mode, a collector may obtain logon events from domain controllers without installing a DC agent on every controller. The choice has compatibility, permissions and operational considerations. It also changes where a missing login event should be investigated. A collector that cannot query the relevant domain controller may produce stale or absent mappings even though the FortiGate-to-collector connection itself is healthy.
When users change workstations or addresses, mapping freshness matters. A firewall that still associates a reused IP with an earlier user could make an inappropriate group decision. Record event delivery, mapping age and source-address correspondence as part of identity troubleshooting.
Use the user monitor and logs to distinguish stages
FortiOS provides visibility into authenticated users and identity associations. The meaningful question is whether the required user, group and current source address are present when the session is evaluated. Viewing a collector as online is not sufficient if the specific user record is missing. Compare the identity source’s evidence with the FortiGate user monitor and the policy decision.
Consider an employee whose login works on the domain but whose firewall session is denied. Three plausible causes are missing FSSO event observation, a group mapping that does not match the intended policy, and a network path that uses a different source IP than the mapping. Obtain evidence of all three before changing access controls. A domain login’s success proves only the directory authentication, not the complete FortiGate forwarding authorization.
Logging needs careful handling because identity records can reveal individual activity. Collect the minimum useful data, protect it and follow workplace privacy requirements. Do not make a troubleshooting exception that grants a user access beyond the required application just because a mapping is temporarily missing.
Security and operational tradeoffs
Remote directories are valuable central sources of truth, but they also introduce availability dependencies. A directory outage may affect some policy paths more than others depending on cached identity state and the configuration. Plan emergency access and privileged administration separately from normal user identity where appropriate, including tested alternatives for authorized recovery.
Certificate trust is as important for secure LDAP transport as it is for HTTPS inspection. An encrypted channel that fails certificate validation should not be fixed by routinely disabling verification. Inspect names, issuer trust, expiry, time synchronization and directory service configuration. Authentication systems are high-value targets, so use least-privilege credentials and approved network boundaries.
Identity-based rules should be auditable. Record a policy’s allowed groups, directory source, mapping behavior and failure expectations. This helps explain why a particular user is permitted or blocked and reduces the tendency to leave broad IP-based bypass rules after emergency troubleshooting.
Another subtle identity problem arises from roaming devices and stale address leases. A laptop can receive a new source IP after reconnecting, while the collector’s last observed domain login refers to the old address. The firewall then may fail to associate the new session with the intended user even though the Windows desktop still shows that user signed in. A targeted diagnostic compares current DHCP lease, endpoint address, collector event and FortiGate user mapping, rather than simply resetting the directory password.
Study with fault cases that distinguish identity from policy
Case one: LDAP test fails for all users. Check transport, TLS and bind/search context. Case two: RADIUS accepts the login but the user is not allowed to a protected app. Check returned group claims and policy membership. Case three: FSSO works for one domain controller but users of another disappear. Check collector polling or agent coverage and current source-address mappings.
A high-quality exam response identifies the actual stage that failed, the evidence that proves it and the smallest safe corrective change. Understanding who authenticated the user, how that identity reached the FortiGate, and which firewall policy consumed it is the core of the 7.6 identity tasks.