FSSO Collection Gaps Across Four Domain Controllers
A retail chain uses FortiAuthenticator 6.5 as an FSSO collector for 45 FortiGates and 2,400 domain users. Four domain controllers serve the estate: two at headquarters and one in each of two store clusters. FSSO agents are installed only on the two headquarters DCs. Store users authenticate to their local DCs. FortiGate user lists show many store users as Guest, and some HQ users appear in Domain Users but not in the FSSO group used by the internet-access policy. A pilot added FortiAuthenticator polling for one store DC, but duplicate user sessions appeared. The FortiGate FSSO connector uses TCP 8000 and a single collector IP. The AD service account is a member of Domain Users only. The FSSO agent service runs as Local System, and event log forwarding is not configured.
1. Explain why store users show as Guest and why some HQ users miss the FSSO group.
Read the worked answer
Guest normally means the FortiGate has no FSSO logon record for that IP/user, so the policy falls back to an unauthenticated or guest category. Store users authenticate against store DCs, but agents are only on HQ DCs; those logon events are never collected. Some HQ users may be collected but not mapped into the FSSO group because the FortiGate FSSO group filter or the FAC group mapping does not match the AD group DN, or the service account cannot read the needed event logs. Confirm with a test store user: log on, check the store DC Security log, then check FAC FSSO monitor and the FortiGate FSSO list. Do not treat Guest as a group-membership problem until you prove the logon event reached the collector.
2. How should collector coverage be designed to avoid duplicates and gaps?
Read the worked answer
Cover every DC that can authenticate users. Either install the FSSO agent on all four DCs or configure FAC polling for all four; do not run both agent and polling against the same DC, which is the likely cause of duplicate sessions in the pilot. Keep one logical collector endpoint for the FortiGates and use TCP 8000 as configured. If using agents, run them under an account or service context that can read Security event logs; add the account to Event Log Readers if needed. If using polling, ensure the FAC service account has the required rights and that all DCs are listed. After changing coverage, clear stale FSSO sessions and test a store user and an HQ user in each cluster.
3. Which verification steps and logs would you use to confirm the fix?
Read the worked answer
On FortiGate, use diagnose debug authd fsso list to see whether the user/IP is present and which group is associated; clear a single test user and log on again. On FAC, check Monitor > FSSO or the equivalent collector view for the workstation and logon event. On the agent, check its log and the Windows Security event log for the logon type; on polling, check FAC collector logs for DC connection errors. Verify DNS and TCP 8000 between FortiGate and collector, and check that the FortiGate FSSO group name matches the group the collector sends. Capture on the FortiGate if the user list is empty but the collector shows the user.