STAS - Was it always a hot mess?

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.

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.

The problem with STAS is there are many links in the chain, and it only takes one to go wrong and you start getting intermittent results. It's a pain to troubleshoot.

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. 

Log off detection can be changed to PING from WMI which can help if people get logged off incorrectly, but don't use the Dead Entry timer as it's broken (and has been for several years at least). There is the Sophos SSO client that is run via a windows login script which is pretty good though does require a bit more work to setup, which is why I've always try the STAS client first (and to be fair, works ok in the vast majority of situations).

FYI : STAS v3.0 is due for out sometime later on this year, I've no idea what will be in it but I'm hoping for at least having the DE timer fixed ....

Regards

The Login Client via Script is End of Life and not supported anymore. 

https://community.sophos.com/products/xg-firewall/b/blog/posts/sophos-windows-single-sign-on-client-transitions-to-end-of-life

Some customers already migrating to User ID with Central Endpoint. This would cover all clients with Sync-Sec. 

Meanwhile with Symantec SEC, one installs the client on every Domain Controllers, and bingo.  5 minutes.  Done deal.  Set it, forget it.

Paul Jr

Can't be that easy surely.

Yep.  Quick and annoyingly boring agent install on your DCs.  Brightmail (mail gateway), for example, uses it when you want to drop mails destined to un-existing email addresses in your domain.

Paul jr