FSSO Users Intermittently Prompted for Portal
An international retailer has a FortiGate 600E at headquarters and 180 stores. Headquarters authenticates 3,200 domain users through FSSO. Agentless polling is configured against DC1 only; DC2 was added to the domain last year and hosts the wireless users who log on at store opening. The FortiGate has a web filter profile that applies FSSO groups and a fallback captive portal for unknown users. Every morning between 07:45 and 08:30, many wireless users are redirected to the portal and must type credentials; after they authenticate once, browsing works. Wired users on DC1 are unaffected. DNS reverse lookup zones exist for both DC subnets. The FSSO polling frequency is 10 seconds, workstation check is enabled, and the FortiGate can reach DC2 over LDAP and SMB. Guest Wi-Fi uses RADIUS and is not affected. The business wants transparent authentication without weakening guest separation.
1. Why are users authenticated on DC2 not recognized by FSSO, and what evidence confirms it?
Read the worked answer
Agentless FSSO polling reads logon events only from the domain controllers configured on the FortiGate. If only DC1 is configured, a wireless user who authenticates to DC2 has no security event read by the FortiGate, so no IP-to-user mapping is created and the fallback portal appears. Confirm with diagnose debug authd fsso list: the user's workstation IP should be missing or stale, while DC1 users are present. Run diagnose debug authd fsso refresh-log and check the FSSO debug output for DC1 only. Also verify that the DC2 LDAP server object is reachable, that the service account can read security logs, and that the FSSO group import includes DC2 users. Workstation check depends on reverse DNS, so confirm the wireless subnet has PTR records and that the FortiGate resolves the client IP. The morning timing matches wireless logons on DC2, not a general FSSO outage.
2. How should the authentication policy order be designed for domain, BYOD, VPN, and guest users?
Read the worked answer
Put transparent identity first. A policy for known domain users should match the FSSO group and use set fsso enable so recognized users pass without a portal. Below it, a policy for managed devices can require a client certificate. For unknown BYOD, use active authentication against RADIUS or LDAP with MFA, scoped only to internet access; do not place that captive-portal policy above the FSSO policy or every user will be prompted. VPN users should terminate on a separate portal policy with LDAP plus MFA. Guest Wi-Fi should stay on its own SSID, VLAN, and VDOM or policy with RADIUS and isolation, never mixed with corporate FSSO. End with an explicit deny. This order avoids multiple redirects and keeps guest separation intact. Test the policy order with one user from each category before broad rollout.
3. What validation and monitoring steps would you use before rolling the fix to all stores?
Read the worked answer
Validate with a pilot store or a test account in each DC. On the FortiGate, watch diagnose debug authd fsso list after a DC2 logon and confirm the workstation IP maps to the correct user and group. Check diagnose firewall auth list for the authenticated session and verify the policy hit count for the FSSO policy increments. Use an FSSO debug filter for the test user's IP to avoid log noise. Confirm the portal no longer appears for the pilot user but still appears for a guest and for an unknown BYOD device. Monitor FSSO polling errors and DC2 connectivity for a week before enabling all stores. Document the fallback path and a rollback that removes DC2 polling if log volume or LDAP load causes problems.