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.

    __________________________________________________________________________________________________________________

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

    __________________________________________________________________________________________________________________

Children
  • Thanks, I was able to add the GPO to the domain policy so the server hosting the STAS could access WMI on domain workstations. It appears there were other factors at work here as well, sort of a chicken and egg thing. There are firewall rules that only allow certain traffic to reach certain servers on the network before the user is authenticated, specifically domain controllers and the STAS server. In those rules I did not have port 445 as that is SMB and we did not want to allow unauthenticated users to get to file shares. I added that port to the rules thinking perhaps the STAS server was unable to get to port 445 on an unauthenticated workstation and thus failing, not sure if that is actually the case though. Will run for a little while with both the GPO and port 445 and see how it goes, if it stabilizes I remove the port 445 and see if things get crazy again.

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

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

    __________________________________________________________________________________________________________________