Skip to main content
Toyens
Toyens
New Member
April 16, 2018
Question

Problem to autheticate after connection deleted as dead entry

  • April 16, 2018
  • 2 replies
  • 4876 views

Hi,

 

I'm working on a Fortigate 1000C with firmware v5.4.5 for some time at work an there still one problem I can't fix. I'm using FSSO with the Collector agent on my DC to do the link the AD. The problem is, when someone just lock is Windows session, not logging off, and the computer switch to sleep mode, it become unreachable. Then, the user status become not verified so the connection is deleted by the dead entry setting. When the user come back and try to access internet, a login Windows appear. I can type any username and password but it never work. The only way to get access to internet again is by logging off the Windows session.

 

Is there a way so entering username and password when I get that sreen will reconnect the user without closing the Windows session?

    2 replies

    V
    varle
    New Member
    April 16, 2018

    Hi Toyens, take a look this KB

    http://kb.fortinet.com/kb/viewContent.do?externalId=FD31772

     

    You need open port between workstation and FSSO

     

     

    xsilver_FTNT
    Staff
    xsilver_FTNT
    Staff
    April 17, 2018

    Hi Toyens,

     

    at the moment I'm not sure if DCAgent handles the unlock. However during the unlock there is supposed to be logon event on DC Kerberos level. Visible in EventLog. Most probably some of 4624 sub types.

     

    Check:

    ---

    - what logon event happen on DC when Workstation is unlocked

    - DCAgent or Collector Agent logs to see if those components saw the event created by unlock

     

    Possible solutions:

    ---

    1. disable workstation check by setting the interval to 0. This way Collector will not track workstations and they do not fall into dead entry period timer because fo not-verified state in locked up state. However this also has it's consequences as user will be seen logged on indefinitely if no one else logs in or WMI logout is detected.

     

    2. prolong dead entry timeout to cover locked state. Consequences are increased time till logged out workstation is detected.

     

    3. if users simply lock workstation over night instead proper logout, teach them to log out properly. So this error can also be used as lever/force to make them learn to do not leave computer logged in and just locked.

     

    4. if check reveal that there is logon event upon unlock, like 4624 logon type 7 (unlock) , then you can combine DCAgent mode and WinSec Polling modes .. see registry and value of "supportLogonMonitorType". Dword:00010000 is WinSec polling + 00000001 is DCAgent mode = 00010001 should result in combination of Polling and listening to DCAgents.

    You might also need to add 4624 into monitored event ID list .. "ep_eventid_list"="1;4624"

     

    5. as your logon screen comes probably from fall back to non-FSSO authentication method like NTLM , then you need to verify that auth path and check which method is used instead of FSSO when Workstation unlocks, and how it's processed, if proper group is set and where it leads. That should give you a hint which user name and password you can use to pass authentication to access protected resources once you try to browse from unlocked workstation. This is fine, but I would rather fix FSSO and maybe even disable such fallback.

     

    Kind regards,

    Tomas

    Terms & ConditionsAccessibility statement