Fortigate FSSO Agent - Logon/Logoff events

[jjm1971]

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?

[kiri]

hi there,

Most likely if you specify only the logon events (instead of 0, 1, 2) you won't have the users logged off anymore.
Check what are the correct IDs for your server OS.

6) Logon Event ID poller. Increase the level to '2' instead of '0' of visibility of LOGS in all the FSSO-CAs, On the main screen of the FSSO-CA.

Select Advanced Settings -> Windows Security Event Logon -> Event IDs to poll.
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-FSSO-Complete-troubleshooting-for-TA...

Technical Tip: Windows event IDs used by FSSO in WinSec polling mode
https://community.fortinet.com/t5/FortiAuthenticator/Technical-Tip-Windows-event-IDs-used-by-FSSO-in...

[jjm1971]

I was looking at this earlier, although I'm not sure which events are causing the logoff in the Fortigate FSSO logs and user event logs.  

[spoojary]

The behavior you observed with FSSO on Fortigate can occur due to how FSSO detects user logon/logoff events. Here are potential solutions:

1. Check FSSO Event Monitoring: Ensure FSSO isn't misinterpreting lock/unlock events as logoff/logon events.
2. Use Polling Mode: Consider switching to polling mode where FSSO polls domain controllers for logon sessions, reducing false logoff detections.
3. Adjust Session TTL: Increase the session Time-To-Live on Fortigate to give users a longer grace period.
4. Update Collector Agent: Ensure the FSSO collector agent is up-to-date and correctly configured.
5. Debug: Check Fortigate's debug logs for insights into logon/logoff event processing.
6. Contact Fortinet: If issues persist, reach out to Fortinet support or their community forums.

Always ensure changes made don't compromise security.

[pminarik]

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)

[jjm1971]

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. 

[pminarik]

> 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.