Authentication and Access Control
Authentication and Access Control covers how FortiGate identifies users and administrators and how identity changes policy matching. Questions target authentication methods, group types, and the line between firewall authentication and admin authentication.
Identity sources
- Local users, LDAP, RADIUS, TACACS+, SAML, and PKI certificates are supported.
- FSSO consumes Windows Security Event Log or Collector agent data; FortiGate receives identity rather than authenticating the user itself.
- User groups can be firewall, FSSO, RADIUS, LDAP, or guest groups; policies match group membership.
- FortiToken and push provide MFA; admin MFA can be enforced per admin or globally.
- Certificate authentication uses CRL or OCSP checks; revocation failure policy determines whether access fails open or closed.
Admin access
- Admin profiles define read/write scope; super_admin is not required for every task.
- Trusted hosts restrict source addresses for admin logins.
- Two-factor authentication applies to admin accounts and can be combined with RADIUS.
- VDOM admins see only assigned VDOMs; global admin settings may remain visible depending on profile.
Worked example
A policy allows Domain Users to access the internet. A user logs in via FSSO. FortiGate receives a logon event from the Collector agent and maps the user to the FSSO group. Because the policy matches the group and the user's source IP is associated with that identity, traffic is accepted. If the user logs off and the collector does not send a logoff event, the session may persist until the FSSO timeout. The trap is assuming FortiGate performed the authentication; here it only consumed identity from the collector.
Traps
- Firewall authentication and admin authentication use different portals and often different user databases.
- LDAP group matching requires the correct group DN and bind credentials; nested groups need recursive queries.
- Captive portal authentication does not automatically apply to all policies; it must be enabled on the policy.
Key points
- FSSO passes identity to FortiGate; it does not authenticate the user on the firewall.
- Admin profiles and trusted hosts control administrative access separately from firewall policies.
- Policy group matching depends on correct LDAP DN, bind credentials, and nested-group handling.
- Captive portal must be enabled on the policy that carries the user traffic.
- Certificate revocation checking can fail open or closed depending on configuration.