Skip to main content
jjm1971
jjm1971
Visitor III
January 17, 2023
Solved

Fortigate FSSO Polling

  • January 17, 2023
  • 2 replies
  • 3856 views

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

 

FortiGate 

Best answer by pminarik

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

2 replies

pminarik
Staff
pminarik
Staff
January 17, 2023

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.

    jjm1971
    jjm1971Author
    Visitor III
    January 17, 2023

    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.

     

     

    pminarik
    Staff
    pminarikAnswer
    Staff
    January 18, 2023

    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

    jjm1971
    jjm1971Author
    Visitor III
    January 18, 2023

    Thanks, that's fixed it!

    Terms & ConditionsAccessibility statement