Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Subscribers 29 subscribers
  • Views 9071 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSO client vs STAS

contact.pl contact.pl

Hi,

Long time ago I tried STAS with mixed results and I gave up. Now I have latest version 17.1.2 and I am wondering which direction should I go - STAS or SSO client? I know is not easy to deploy SSO client but .... maybe it would give more reliable results. In short I am looking for quick comparison between those two authentication methods which would help me to make decision.

Pawel



This thread was automatically locked due to age.
  • 0

    I would say ithardly depends on your Environment. From my point of view, STAS is a suitable solution for well-managed environments with well-managed, rather static endpoints. Static means: Most of your Users are using a classic desktop-PC. We've been facing a lot of issues with Laptops being removed from Dockingstation (hand over from RJ45 to WLAN). As far as I know, SSO Client is also possible to use when having not a Domain Environment what's not the case with STAS (of corse it's not). 

  • 0

    Hi Pawel,

    I do not believe that the SSO client is a suitable solution for a medium to large network. I would use the SSO client for exceptions e.g. non-domain machines. I recently migrated from UTM 9 to XG17.1 and while I initially experienced a number of issues with STAS, I managed to resolve these together with the assistance of Sophos support. STAS is far from perfect but it's the best tool for SSO for XG.

    Check out these KBs:

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

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

     

     

  • 0

    In my experience SSO client is more stable and easy to work with. The only issue is the official deploy method. I just repackage the client in msi and deploy it and reg keys through gpo, It has working well since they fix it in 16.05.5.

    STAS always have problem with logout detection, client with multiple network connection and get confused when you use remote desktop.

  • 0 in reply to daiqingxu

    daiqingxu,

     

    3 quick questions

    - how do You deploy registry settings through msi - they are in current user branch

    - how do You start sssophose.exe and do You monitor if it was killed and then do You restart it

    - do You know if there is any way to troubleshoot why sssophos is not starting. Sometimes I see that process just starts and terminates without any logs or anything

     

    Pawel

  • 0 in reply to envercpt

    HI Envercpt,

    Did You encounter following issues and did You managed to solve it:

    - on computers there are services which are running under domain accounts => in those case almost whole traffic is tagged as comming from "service user" not actual user [SOLVED - there is setting in STAS for that]

    - when user is working on his PC, sometimes admin creates remote session to fix something and requests elevated privilages using domain account - in such cases STAS starts to see admin as user working from PC

    - I do see lots of logout and then imeddiate logins - any reason why STAS may be doing it?

     

    Pawel

  • +1 in reply to contact.pl contact.pl

    I deploy registry settings through gpp.

    I use taskscheduler to start it at user log on, session connection, network connect and every 10 minutes. I belive it has some edge cases around multiple user logged on same computer, but haven't have time to look into that. Also i deploy it through gpp of user, so it won't apply to service accounts

    I remember it will terminate it when it can't connect to the firewall / domain. I am not sure here.

  • +1 in reply to contact.pl contact.pl

    Hi Pawel,

    None of our domain workstations have services running under Domain Admins. Only servers. We have also created an AD group called Local Admins which gives a few designated users local administrative rights on their workstations.

    I have noticed strange behavior with remote desktops - will check again on Monday and revert.

    Enver