I have configured FSSO for a client in conjunction with and explicit proxy on a Fortigate FW and works well. Testing has highlighted a potential issue I wasn't aware of, in that when a user locks their workstation, the FG is sent a logoff event from the collector agent. Result of this is that the workstation can no longer authenticate through the explicit proxy as there is no user/IP entry due to the logoff event. Obviously whilst the workstation is locked the user doesn't need to browse the web, however the logs show that applications are still trying to access the internet, such as MS Office365 but are being denied.
When the user unlocks the workstation a logon event is sent to the FG and the user can browse again through the proxy. There seems to be a small delay in the FG getting the logon event and then authenticated through the proxy, which impacts the user experience.
I've been searching to find out whether this is expected behaviour but can't find anything related. Windows event IDs for workstation lock/unlock are 4800 and 4801 but these aren't monitored from what I can see.
Does anyone know if there is any way of preventing this behaviour occurring with the lock/unlock causing logoff/logon events?
FSSO has never monitored logoff events in the domain, and to my knowledge also does not interact with locking events.
The immediate trigger for the logoff will be identifiable from the Collector's logs, but as they are quite unreadable for an untrained eye, I would recommend reaching out to TAC for assistance with this.
(I am assuming basic FSSO with either event log parsing or DC Agents; if you're using TS Agents or FSSOMA (mobility agent feature of FortiClient), let us know)
This is basic FSSO with CA and DC Agents. How does the FG get informed of a logoff event if it is not monitoring logoff events, must be some information from the DC? I can logoff events from the CA in the user event logs.
I will do some further investigation on this, had some feedback earlier with someone testing lock/unlocking of their workstation that they didn't get the logoff event, just a logon event when unlocking. It may be an isolated case.
> How does the FG get informed of a logoff event if it is not monitoring logoff events, must be some information from the DC?
User removal from FSSO is handled by workstation check and dead entry timer.
Workstation check is started ever X minutes (5 by default), using WMI to attempt to read the username of the currently logged in user.If the username matches, entry is kept. If the username is different, or none at all (nobody logged in), the FSSO entry is removed. Note that this works with user sessions in general, the state of it is not relevant (i.e. no difference between user logged in and working, and away with locked screen).
If workstation check doesn't work at all (disabled, or failing due to PC being off, offline, or maybe due to WMI permission issues), then dead entry timer starts and the user's FSSO session gets wiped once the timer reaches zero (8 hours be default; timer resets with every new successful workstation check or a new logon event by the same user on the same PC/IP).
Logoff events aren't utilized because they are notoriously useless for detecting a user's state. I often see a bunch of "logoff events" in the DC's logs despite the user continuously being logged in on their PC.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.