I am configuring FSSO using the polling method and I am seeing some strange results. The Fortigate is seeing the user logon event and I can see the corresponding Kerberos event IDs 4768 and 4769 on the AD server, however the Fortigate is then logging a logoff event almost instantly for that same user.
As far as I understand, polling mode only reads events 4768 and 4769. On the server security event log, there is a logoff event (4634), even though the user is still logged onto the machine, not sure why that is being logged by the AD server.
Has anyone come across this type of behaviour before? Not sure if this is expected, however it means that the FSSO groups can't be used. I'm aware that this is not the recommended method for FSSO, however I have a customer who wants to use this (until I can persuade them to use DC agent mode).
Thanks
John
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Try adding the suffix as "default-domain" to the FSSO entry (CLI only):
config user fsso-polling
edit <id>
set default-domain <domain-suffix here>
end
The logoff event 4634 is not used by any FSSO solution (FGT itself, Collector Agent, FAC) for exactly the reason you outlined - it has no relation to whether a user has actually logged out of their workstation.
If you're getting instant kicks out of FSSO, the reason must be something else. Check authd + fssod debug outputs, reach out to TAC if you need help parsing them.
Created on 01-17-2023 09:18 AM Edited on 01-17-2023 09:19 AM
Thanks pminarik
I found what the issue was through the fssod debug, the time was out between the Fortigate and the AD server
[process_logon_time_stats:101] logon(john:10.245.225.41)'s effective time(1673970919) on Fortigate is before that(1673971018) on AD server. Please sync the time of Fortigate and AD server.
........
[auth_svr_check_obsolete_logon:840] the logon item(john:10.245.225.41) is obsolted at the time(Tue Jan 17 15:56:58 2023
) for its time is (Tue Jan 17 15:56:58 2023
So it looks like it was logging the user off again. However in the course of looking at the debug I have come across another issue which I can't seem to fix as yet.
The Fortigate tries a DNS query for the workstation after it has the logon information, but that is failing as there is no domain associated with it, the response is a SERVFAIL.
[dns_parse_resp:133] 2: DNS response received for host WINDOWS10-2 is_ip6 0, id 11
[dns_parse_resp:149] rcode err 2
[logon_dns_callback:290] failed to resolve logon-WINDOWS10-2 in vdom Lab
[dns_parse_resp:133] 2: DNS response received for host WINDOWS10-2 is_ip6 1, id 12
[dns_parse_resp:149] rcode err 2
[logon_dns_callback:290] failed to resolve logon-WINDOWS10-2 in vdom Lab
I've added a local domain under the DNS settings, however it doesn't appear to take effect with these requests. I'm using VDOMs by the way, I would have thought adding a local domain in the global DNS settings would work but it doesn't. I've specified the DNS servers for this VDOM, although I can't see a way of adding a domain to a VDOM specifically. I assume this is only done globally.
Try adding the suffix as "default-domain" to the FSSO entry (CLI only):
config user fsso-polling
edit <id>
set default-domain <domain-suffix here>
end
Thanks, that's fixed it!
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1665 | |
1077 | |
752 | |
446 | |
220 |
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.
Copyright 2024 Fortinet, Inc. All Rights Reserved.