“FSSO is a software agent that enables FortiGate to identify network users for security policies or for VPN access, without asking for their username and password. When a user logs in to a directory service, the FSSO agent sends FortiGate the username, the IP address , and the list of groups that the user belongs to. FortiGate uses this information to maintain a local database of usernames, IP addresses , and group mappings.”
“To display the list of FSSO users that are currently logged in, use the CLI command diagnose debug authd fsso list . For each user, the user name, user group, IP address , and the name of the workstation from which they logged in shows.”
“You can monitor users who authenticate through your firewall policies using the Dashboard > Assets & Identities > Firewall Users page. It displays the user, user group, duration, IP address , traffic volume, and authentication method.”
Technical Deep Dive:
The first thing to verify is whether FortiGate has actually learned the user correctly in its FSSO active users table , especially the user-to-IP mapping . FSSO enforcement is identity-based, but the real-time match on live traffic still depends on FortiGate associating the traffic’s source IP with the authenticated Windows user. If that mapping is missing, stale, or tied to the wrong IP because of DHCP changes, DNS update lag, or collector-agent timing, the firewall policy match can fail even though the user successfully logged in to Windows.
That is why C is the best first check.
A may be the next thing to verify if the user is present but still denied, but first you must confirm the user is even present in the FSSO table with the correct IP.
B is unrelated to the initial FSSO identity-mapping problem.
D is less likely because the Windows logon already succeeded.
Useful checks:
diagnose debug authd fsso list
diagnose debug authd fsso server-status
execute fsso refresh
These commands confirm whether FortiGate has the user, group, and IP mapping needed for policy matching.
