INSIGHTS
Cybersecurity

NSE4_FGT_AD-7.6 Firewall Authentication: LDAP, RADIUS, FSSO and Policy Identity

Compare LDAP, RADIUS, captive authentication and Fortinet Single Sign-On with practical identity-to-firewall-policy troubleshooting for FortiOS 7.6.0.

In this article
  1. Identity information has an origin and a lifetime
  2. LDAP as a directory connection
  3. RADIUS adds a centralized authentication decision
  4. Active authentication versus FSSO
  5. Explain a failed firewall match without guesswork
  6. A compact lab for the exam

A firewall rule can match the correct source network yet still deny access when the required user or group identity is missing. On FortiGate, authentication is the process of establishing who a user is; authorization is the policy decision that grants access to a particular destination and service. The NSE 4 7.6 administrator syllabus explicitly names LDAP, RADIUS, active and passive authentication, user monitoring, and Fortinet Single Sign-On (FSSO). Knowing what each method contributes is more important than memorizing a generic login dialog.

Identity information has an origin and a lifetime

Local FortiGate users are useful for controlled scenarios and fallback accounts, but an enterprise may prefer an existing directory or identity provider. Determine where credentials are validated, where user-to-group membership is resolved, how the firewall learns the user’s source address or session, and when that mapping expires. A firewall policy referring to a group cannot reliably enforce a human identity until an accepted association exists between the current traffic and that authenticated principal.

Consider a rotating workforce behind shared workstations. IP address alone is unstable proof of identity. If an old login mapping persists after another employee takes over a workstation, a group-based policy could temporarily be misapplied. For any identity method, plan how login, logout, address reassignment, stale mapping removal and access revocation are handled. The firewall policy design guide provides the packet and rule layer; identity requires a separate record of evidence.

LDAP as a directory connection

LDAP integrates FortiGate with a directory for user or group authentication in supported workflows. Typical elements include a server address or FQDN, bind identity, search base and common-name attribute. Use encrypted directory transport where supported, restrict service-account privileges and test directory reachability before associating the directory object with a production policy. Fortinet’s remote administrator authentication documentation and FortiOS LDAP examples help distinguish the directory connector from a firewall policy referencing the resulting group.

If an LDAP test fails, separate transport or DNS, bind authentication, directory search, group resolution and actual user password validation. A successful TCP connection to a directory is not evidence that the configured search base contains the intended user. Likewise, a valid group returned by LDAP is not enough if a traffic policy matches a different source interface or destination service. Solve the stage that failed rather than broadening authorization to every user.

RADIUS adds a centralized authentication decision

RADIUS can authenticate firewall users, administrative logins and VPN users in supported FortiOS features. Fortinet’s RADIUS server configuration guide describes server profiles, shared secrets, authentication methods and the relationship between a RADIUS object, user groups and firewall policies. A failed RADIUS request can arise from an incorrect secret, reachability, unsupported authentication method or the upstream server’s own policy decision. A server timeout is not the same outcome as an explicit access reject.

Design retries and failover carefully so that a temporarily unreachable authentication server does not silently authorize everyone. For high-value access, combine the identity source with suitable MFA and certificate-based protection where appropriate. When comparing RADIUS with LDAP, avoid claiming that either automatically produces correct per-session authorization: FortiGate still needs a matching local group or firewall policy and an appropriate source of user identity for that flow.

Active authentication versus FSSO

In active firewall authentication, a user explicitly provides credentials during the access workflow. In a passive FSSO workflow, FortiGate learns an authenticated user-to-IP association through integration with identity events, such as domain-controller information collected by an FSSO agent. The official Fortinet Single Sign-On agent setup documents an external connector under Security Fabric, a collector address and options for local versus collector-supplied group filtering.

FSSO reduces repeated prompts but introduces correlation problems: the event may not have arrived, the endpoint may have changed address, the source group may have changed, or a collector may be unreachable. If policy denies a known directory user, verify the collector state, learned logon mapping, group selection, address and timestamp before assuming that the username itself is wrong. A user able to sign into Windows is not automatically known to the firewall at the instant of a new network session.

Explain a failed firewall match without guesswork

Suppose a finance employee can reach a server by direct IP from a lab VLAN, but an identity-scoped application rule blocks the same service after moving desks. Test whether the traffic now enters through a different interface and whether the firewall has a current mapping from the new client IP to the authenticated user’s permitted group. Search authentication and forward-traffic logs together. If the identity mapping is present, verify the destination service and rule order; if absent, investigate the chosen LDAP/RADIUS/FSSO workflow and session lifetime.

A successful remedy might be re-establishing a stale identity event or fixing an incorrect group filter. An overly broad “allow finance subnet” rule would mask the identity requirement rather than fix it. Use the FortiGate logging workflow to distinguish an authentication event from a normal policy deny and an upstream application failure.

A compact lab for the exam

Build two firewall user groups with distinct access scopes and one destination service. Test local authentication, then a permitted LDAP or RADIUS lab identity. Capture an explicit reject, an unreachable authentication server, and a valid login whose firewall policy still denies access. If your lab supports FSSO, demonstrate login-event arrival and the mapping lifetime, then change the client address to reveal why stale state matters.

Document exactly which component supplied identity, which control evaluated group membership, and which firewall rule made the access decision. Fortinet expects candidates to interpret operational scenarios; that three-stage distinction is the transferable skill behind most exam authentication objectives.

Filed under Cybersecurity