STAS - Was it always a hot mess?

Just wondering what other people's experience has been with STAS, has it always been such a hot mess or is this a v18 thing? We have people that are constantly being disconnected from the   XG when authenticated with STAS and then others who just seem to stay connected all the time without a problem. There seems to be some sort of pattern depending upon which operating system they are on, Windows 7 clients seem to be more stable than the latest Windows 10 versions. I have had to start giving troublesome PCs static IP addresses via DHCP and setting them as clientless authentication devices which is not ideal but solves the disconnect problem. Any plans to upgrade STAS as part of v18 as it appears to be long overdue.

Parents
  • It depends. Like everything.

    There are customers having no Issues at all, some have some issues with STAS.

    Most likely, there is some "configuration issue" in the Customer domain.

     

    STAS highly depend on WMI.

    So basically STAS checks for a user logged in on AD Log.

    Afterwards, it will connect directly to this user via WMI and verify, he is A. Logged in, B. the correct user. If not, STAS will remove this user.

     

    Most likely, if you have "some" users expierence issues in STAS, their clients are not reachable via WMI.

     

    Do you have the proper GPO rolled out and could verify, this GPO is placed on the Endpoint?

    https://community.sophos.com/kb/en-us/123020

    Without GPO, the windows firewall will block the WMI Request.

    So you could use the KBA to verify this, using wmic.

     

    In bigger setups, with more GPOs, sometimes there is no "default" rule, so basically some clients are not getting the correct GPO to open WMI to STAS.

    So those clients are stuck in a loop. STAS via Log will login this user, WMI will logout them.

    __________________________________________________________________________________________________________________

  • So what is the way to handle Mac Users, Linux users and so on? There is no WMI on such systems.

    Why the double Check? I do not see how an entry in the AD logs could be faked.

Reply Children
  • There are more use cases of double checking.

    For example log off detection.

    You want to know, when this Client is offline.

    And most likely not all the time, AD is generating a Log off entry.

    There are couple stories on Microsoft pages, discussing, there are no log off entries after the client restarts. 

     

    So if you do not check sometimes, you could have a user logged in for hours, which is not the correct user at all. 

    __________________________________________________________________________________________________________________