| Solution |
FSSO follows the basic sequence below:
General FSSO layouts:
- User -> DC <polling> Collector -> FortiGate.
- User -> DC -> DCAgent (on the DC) -> Collector -> FortiGate.
- User -> Terminal server -> TSAgent (on the TS) -> Collector -> FortiGate.
Collector = FortiAuthenticator as an FSSO Collector or a standalone Collector Agent installed on a domain member host or Domain server itself.
General sequence:
- A user causes a logon to the DC. This is only possible from within the domain network and can be confirmed with 'echo %logonserver%'. The output must be a DC of the network.
For example:
C:\Users\Test>echo %logonserver%
\\LABTEST-DC
- The logon has to be inside a certain Event ID, typically 4624 or 4768, found in the event viewer under security event logs.
- The collector can poll this event log with respective permissions, OR a DCAgent can push info from the DC to the FAC or Collector Agent. Both methods are possible, but it is better to decide on one. DCAgent needs to be installed to the DC and hooks on a restart of the DC into lsass.exe. Polling does not require this interaction or maintenance, but it will cause regular polling traffic.
- The logon event contains the username and workstation/IP values, which the collector will use to:
- DNS lookup the current IP from the workstation and perform a periodic check via DNS for the case that the IP changed.
- LDAP lookup group membership to receive the set of groups in a string in either the domain\group or CN=group,CN=users format.
- After that, it will be possible to see the user in the logon list on the collector (via Show logon users).
- The collector will try matching the groups of the user against the group filter with an EXACT text string match (domain\group!= CN=group,CN=users...,DC=domain).
Filter only for event IDs that are genuinely required. Make sure that the DNS server for the DNS initial and periodic workstation lookups are fast. If the group matches the filter and an IP was received for this logon event, FortiGate can receive the logon event.
- FortiGate can display the user with:
diag debug authd fsso list | grep X.X.X.X -B1 -A6 <- While this is the IP of the affected user.
diag firewall auth list | grep x.x.x.x -B1 -A 6 <- While this is the IP of the affected user.
The first command shows the pulled logon info from FSSO Collector Agent.
The second command shows the actually authenticated user groups on FortiGate.
For example:
diagnose firewall auth list | grep -A 7 192.168.222.1
192.168.222.1, Test1
src_mac: de:ad:be:ef:ca:fe
type: fw, id: 0, duration: 3298, idled: 2
expire: 297, allow-idle: 300
server: LDAP
packets: in 459352 out 128544, bytes: in 647744424 out 11044928
group_id: 6
group_name: testldapgroup
192.168.222.1, Test2
type: fsso_citrix, id: 3, duration: 1918, idled: 1918
server: fssotest
packets: in 0 out 0, bytes: in 0 out 0
group_id: 5 33554433
group_name: FSSOIT CN=USERS,DC=FORTI,DC=LAB
port_range: (1224-1423)
192.168.222.1, Test3
type: fsso_citrix, id: 4, duration: 107, idled: 107
server: fssotest
packets: in 0 out 0, bytes: in 0 out 0
group_id: 5 33554433
group_name: FSSOIT CN=USERS,DC=FORTI,DC=LAB
port_range: (1424-1623)
----- 3 listed, 0 filtered ------
Troubleshooting:
All failures with FSSO should follow the order above in reverse:
Policy needs to have the user with the fitting IP that is matching the policy, but also the group.
- Is the user known to the firewall with the correct group and IP? If there is no user entry, FSSO policies cannot be matched.
- Is the Collector Agent having the same information? Is the user known there as well, with the correct group and IP?
- If the user is not there as well or is wrong, crosscheck the event IDs from the Windows security event logs. There should be an event with the user and machine name at the minimum. FSSO takes these and will resolve the user IP from the machine against DNS (use the nslookup command on the same(!) Collector Agent host for testing).
- As such, the IP will be periodically looked up. On the Collector Agent, run an nslookup against the machine name to find out what the DNS server response is and whether it is recent.
The standalone collector agent has a setting for the event IDs that are to be polled, either in a comma separated list or with a set of events. See Technical Tip: Windows event IDs used by FSSO in WinSec polling for more information.
In summary:
- 0 - polls: 672, 680, 4768, 4776 - this is the default subset.
- 1 - polls: 672, 673, 680, 4768, 4769, 4776.
- 2 - polls: 672, 673, 680, 4768, 4769, 4776, 4624 (EventID 4624 was added to default polling in Windows 2016 for better support of macOS and newer Windows server platforms).
The 'user not polled' error describes a problem at step 3 while DNS is step 4. If there is a delay on that information, check:
- Whether nslookup has the correct info and has updated it quickly.
- If so, then the Collector might be delaying the lookup for some reason.
The Collector Agent debug log contains statistics about the time spent on certain tasks. If DNS is delaying the tasks, similar DNS failures may be seen: check the logs for 'time spent' and consider the statistics lines about DNS and workstation connection.
It is also possible to enable the debug log of the collector. For that, switch it to 'debug' and increase the size, leave it running for about an hour and then test FSSO with a user that is affected, noting down the testing timestamp and username.
Related article:
FSSO troubleshooting tips
|
