Kestrel's staff stop seeing a login page
Kestrel Logistics used the captive portal from the authentication lesson for a month. Staff complained: they had just logged on to Windows, and every morning the browser asked for the same password again. Finance wanted FIN-SRV (10.0.2.30) open to its staff without a prompt, and HR wanted social media blocked for everyone except Marketing. Both rules are about AD groups, and Windows already knows who is sitting at 10.0.1.23. FSSO lets FGT1 borrow that knowledge.
The domain has two domain controllers, DC1 (10.0.1.5) and DC2 (10.0.1.6). The collector agent runs on a member server, COLL1 (10.0.1.8), all on the LAN behind FGT1's port2.
From a Windows logon to an entry on FGT1
Notice what the FortiGate trusts: an IP address. Step 3 is the fragile one. If DNS has an old record for Alice's laptop, the logon is mapped to the wrong address and someone else gets her access.
DC agent mode, polling mode and agentless polling
| Mode | How logons are collected | Trade-off |
|---|---|---|
| DC agent mode | A DC agent on every DC pushes logon events to the collector agent | Real-time and complete, but software on every DC (a DC without it is a blind spot) |
| Collector agent polling | The collector agent polls each DC for logon events; no DC agents | Nothing installed on the DCs; logons can be missed or late on busy DCs |
| Agentless (FortiGate polling) | The FortiGate reads the DCs' security event logs itself (Poll Active Directory Server connector) | No Windows software at all; supports fewer event types, no NTLM logons, can miss bursts of logons, needs an LDAP server for groups |
| FortiAuthenticator | Collects from DCs, agents, syslog and RADIUS accounting, and feeds many FortiGates | An extra appliance; best for large or multi-site estates |
Terminal servers (Citrix, Remote Desktop) need the TS agent on the terminal server. Many users share one IP address there, and only the TS agent can tell their sessions apart by source port. Without it, the last user to log on wins the IP address.
In practice DC agent mode is the default choice once DC owners accept the agent. Polling is popular because it is quick to deploy, and the "sometimes it doesn't know me" tickets that follow are usually missed polls.
Connecting FGT1 to the collector agent
New External Connector: FSSO Agent on Windows AD
- Name
- KESTREL-FSSO
- Primary FSSO Agent
- 10.0.1.8
- Password
- ••••••••Only if the collector agent requires authenticated access.
- Trusted SSL certificate
- Off
- User Group Source
- Collector Agent LocalGroups come from the collector agent's group filter. Apply & Refresh fetches them.
FSSO agents
User group source
config user fsso
edit "KESTREL-FSSO"
set server "10.0.1.8"
set password <collector-password>
set port 8000
set logon-timeout 5
next
endport 8000 is the default collector agent port. Up to five collector agents can be listed (server2 to server5) for redundancy. logon-timeout (minutes, default 5) is how long FGT1 keeps FSSO users after losing the collector agent.
With several collector agents, FGT1 uses the first one it can reach and checks the connection every 10 seconds. It does not fail back on its own when the first one returns; the current connection must be dropped for the preferred agent to take over again.
On the collector agent, set the group filter for this FortiGate to the groups that policies will use (here FIN-Staff, Marketing and Domain Users). A small filter keeps the FortiGate's list short and makes the group names in policies predictable.
Using FSSO groups in policies
The groups sent by the collector agent appear on FGT1 as FSSO groups (config user adgrp). Policies don't use them directly: they go into a user group of type FSSO.
config user group
edit "FSSO-Finance"
set group-type fsso-service
set member "CN=FIN-STAFF,OU=GROUPS,DC=CORP,DC=EXAMPLE,DC=COM"
next
end
config firewall policy
edit 14
set name "FSSO-Finance-to-FIN-SRV"
set srcintf "port2"
set dstintf "port3"
set srcaddr "LAN-subnet"
set dstaddr "FIN-SRV"
set groups "FSSO-Finance"
set service "HTTPS"
set action accept
next
endGUI: User & Authentication › User Groups › Create New, Type: Fortinet Single Sign-On (FSSO), then pick the groups in Members. The member names are exactly as the collector agent reports them.
A user who isn't in FGT1's FSSO list simply doesn't match this policy. By default (auth-on-demand implicitly), the traffic carries on down the policy list. That gives a useful fallback: below the FSSO policies, a policy with an LDAP-backed firewall group catches unidentified users with the captive portal, and anything still unmatched hits the implicit deny.
Learn more: Remote LDAP and RADIUS Servers
In FortiOS 7.6 the FSSO connectors are under Security Fabric › External Connectors (Endpoint/Identity section), and the firewall user list is in the Firewall Users widget on Dashboard › Assets & Identities. The collector agent is separate Windows software with its own versions; check the FortiOS release notes for the supported agent version before upgrading either side. This page has not yet been reviewed against FortiOS 7.4.
Checking each hop of the logon path
Work from the FortiGate outwards. First, is FGT1 connected to the collector agent?
FGT1 # diagnose debug authd fsso server-status Server Name Connection Status Version Address ----------- ----------------- ------- ------- KESTREL-FSSO connected FSAE server 1.1 10.0.1.8
diagnose debug enable first if nothing is printed. Anything other than connected means no logons reach FGT1 at all: check TCP 8000 to COLL1, the password and the collector agent service.Then, does FGT1 know the user, on the right IP address, with the right groups?
FGT1 # diagnose debug authd fsso list ----FSSO logons---- IP: 10.0.1.23 User: ALICE Groups: CN=FIN-STAFF,OU=GROUPS,DC=CORP,DC=EXAMPLE,DC=COM Workstation: PC023.CORP.EXAMPLE.COM Total number of logons listed: 1, filtered: 0 ----end of FSSO logons----
diagnose debug authd fsso filter user ALICE first.Finally, is the user being used for traffic?
FGT1 # diagnose firewall auth list 10.0.1.23, ALICE type: fsso, id: 0, duration: 312, idled: 4 server: KESTREL-FSSO group_name: KESTREL-FSSO CN=FIN-STAFF,OU=GROUPS,DC=CORP,DC=EXAMPLE,DC=COM ----- 1 listed, 0 filtered ------
Users the FortiGate doesn't recognise
One user is missing; everyone else works
Alice isn't in diagnose debug authd fsso list. Typical reasons: her laptop logged on with cached credentials before it reached the office network, so no DC saw a logon; the logon went to a DC without a DC agent; or, in polling mode, the event was missed.
Show the fix
Have the user log off and on again while connected to the LAN, then check the list. If it happens often, check that every DC has the DC agent (a newly added DC is the classic gap), or move from polling to DC agent mode. Laptops that connect over VPN after logon need another method, such as the VPN's own user groups.
The user is listed, but with the wrong IP address
The collector agent resolved the workstation name to a stale DNS record, often after a laptop moved from Wi-Fi to a docking station and received a new DHCP address. Another device may now hold the old address.
Show the fix
Fix DNS: dynamic DNS updates from DHCP or the clients, and scavenging of old records. Check with nslookup PC023 from COLL1, since the collector agent's resolver is the one that matters.
The user is listed, but the policy still doesn't match
The groups field doesn't contain FIN-STAFF. Either the group isn't in the collector agent's group filter, or the user was added to the AD group after logging on.
Show the fix
Add the group to the filter, use Apply & Refresh on the connector, and add it to the FSSO user group. Group membership is read when the logon is processed, so a user added to a group today normally needs to log on again before FGT1 sees it.
Nobody is recognised
server-status is not connected, or the list is empty. FGT1 can't reach COLL1 on TCP 8000, the password differs, or the collector agent service stopped.
Show the fix
Sniff the path from FGT1 (diagnose sniffer packet any 'host 10.0.1.8 and port 8000' 4): SYNs with no reply point at the Windows firewall on COLL1 or the collector agent service. Check both, and re-enter the password on both sides. Then trace the FSSO daemon on FGT1 for a short time:
Keep authd debugging short
diagnose debug application authd -1 prints every logon event on a busy network. Run it only while reproducing the fault, then diagnose debug disable and diagnose debug reset. Do not use diagnose debug authd fsso clear-logons to "refresh" things in production: it clears the logon list and users lose FSSO policy access until their entries return.
Designing FSSO that stays accurate
- Deploy two collector agents and list both on the connector; keep
logon-timeoutlong enough to ride out a collector restart. - Put a DC agent on every DC, and add it to the build checklist for new DCs.
- Keep DNS for workstations clean; FSSO is only as accurate as the name-to-IP mapping.
- Exclude service accounts (backup, monitoring) on the collector agent so their logons don't replace the real user on a PC.
- Use the TS agent for terminal servers, and plan a non-FSSO policy for devices that do not log on to the domain.
Try it: follow one logon through FSSO
In a lab with a domain controller, a collector agent and a FortiGate VM, connect the FSSO connector and filter one group. Log on to a domain PC as a member of that group, then run diagnose debug authd fsso server-status, diagnose debug authd fsso list and, after browsing through an FSSO policy, diagnose firewall auth list. Next, remove the user from the AD group without logging off and note what the FortiGate still believes. Finally, change the PC's IP address without updating DNS and explain what the list shows.
- FSSO turns DC logon events into IP address, user and groups on the FortiGate, without a prompt.
- DC agents report to the collector agent (UDP 8002); the FortiGate connects to it on TCP 8000.
- Policies use FSSO user groups; unidentified users fall through to the next policy.
- Troubleshoot with server-status, the FSSO list, then the firewall auth list.
Test yourself on FSSO
Kestrel adds a third domain controller, DC3. Afterwards, some users are randomly not recognised in the mornings. The deployment uses DC agent mode. What is the most likely cause?
diagnose debug authd fsso list shows ALICE on 10.0.1.57, but her PC is now 10.0.1.23. What should you check first?
server-status shows KESTREL-FSSO connected and the FSSO list shows BOB with group CN=DOMAIN USERS only. The policy uses FSSO-Finance. Why doesn't Bob match?
Forty staff use one Remote Desktop server at 10.0.2.40. With DC agent mode only, what does FGT1 see?
The collector agent server reboots for updates and is down for 12 minutes. logon-timeout is 5. What happens to FSSO users?