A FortiGate receives FSSO logon information from a Windows collector agent, but no users appear as authenticated in identity-based firewall policies. The administrator confirms the collector agent shows active workstation logons. On the FortiGate the FSSO group filter and the polling connection are configured. What is the most likely reason the logons are not usable in policy?
- AThe FortiGate is missing a local user account for each domain user, which FSSO requires before a logon can be matched to a policy.
- BSSL inspection is disabled on the identity policy, so the FortiGate cannot read the user identity from the session.
- CThe collector agent is using TCP 8000 instead of TCP 8002, so the FortiGate silently drops the logon records.
- DThe user groups carrying the logons are not included in the FSSO group filter that controls which groups the collector agent forwards to this FortiGate. Correct
Why A is wrong: This is tempting because local users exist for other auth methods, but FSSO is passive and maps users by group membership reported from AD; it does not require per-user local accounts on the FortiGate.
Why B is wrong: SSL inspection decrypts traffic content and is unrelated to how FSSO associates a source IP with a logged-on user; identity comes from the collector agent mapping, not from inspecting the session.
Why C is wrong: TCP 8000 is the default collector-agent-to-FortiGate port and TCP 8002 is used between the DC agent and collector agent, so this reverses the roles; a wrong port would break the connection entirely, not deliver logons the agent can see while policy stays empty.
Why D is correct: The collector agent only forwards logon events for groups permitted by the group filter; if the relevant AD groups are excluded, the FortiGate never learns those mappings and cannot match them in policy.