Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 13 replies
  • Answers 2 answers
  • Subscribers 27 subscribers
  • Views 24726 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

Confirmation of STAS Setup

Dave Watkins

Hi

 

I'm currently evaluating Sophos XG for a fairly large installation of 5-10k users and about 1Gb of internet traffic. I'm trying to work out the requirements for STAS installation and it _looks_ like I would need to manually install the agent on every single domain controller for it to work properly. I can't find any command line options to automate that nor can I find any way to not have to install it on every DC.

 

To be fair I may have missed something as the documentation seems fragmented and old in a lost of cases. For example the Admin Guide for v16 here points to a document from Feb 2016 for V9 of UTM with an obviously different interface

 

The Watchguard solution didn't require an agent on every DC so I'm hoping i'm just missing something, but if not then at the very least would be an automated installation option.

 

Am I missing something or is the above actually correct?

 

Thanks



This thread was automatically locked due to age.
Parents
  • 0

    Dave,

    at this link you can find the procedure to activate STAS and AD integration:

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

    Make sure to follow all the links inside each article.

    XG uses STAS because data can be more accurated. I mean that users logoff is intercepted by the STAS agent and so the firewall rules and logs are accurated. Without an agent on the DC, it can require up to 15 minutes, before the userA is logged out and userB log-in on the same workstation because of AD mechanisms and this can produce some navigation issues.

    Regards

Reply
  • 0

    Dave,

    at this link you can find the procedure to activate STAS and AD integration:

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

    Make sure to follow all the links inside each article.

    XG uses STAS because data can be more accurated. I mean that users logoff is intercepted by the STAS agent and so the firewall rules and logs are accurated. Without an agent on the DC, it can require up to 15 minutes, before the userA is logged out and userB log-in on the same workstation because of AD mechanisms and this can produce some navigation issues.

    Regards

Children
  • 0 in reply to lferrara

    Hi Luk

     

    Thanks for the link, unfortunately for me it's not relevant, at least as far as I can tell. We have 40-50 domain controllers and that link is for a single domain controller environment.

    This install isn't about blocking by user but rather simple tracking. Obviously catching logon/logoff events is still very good, but what I'm looking for is a way to automate installation on all our DC's or some way to not require installation on all DC's at all.

     

    Thanks

    Dave

  • 0 in reply to Dave Watkins

    Dave,

    use RADIUS instead. Installing STAS on 50 DC is quite a long process. The link can be used for multiple AD:

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

    With RADIUS you should be ok.

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

    Regards

  • 0 in reply to lferrara

    Dave:

    just to add another thid:

    You do not need to install STAS on all DC but on 2 or 3 is already enough (for failover reason). Make sure that Forest-Trusts exist otherwise Users will not be able to autheticate correctly. STAS supports only one Forest.

    Regards

  • 0 in reply to lferrara

    Unfortunately this needs to be completely transparent to the users (about 10,000 of them at the moment but that will grow).

     

    Pushing STAS to the DC's isn't a problem if it can be done silently with no user interaction. We can easily setup auto deployment of it to new and existing DC's via SCCM as long as it can be scripted.

  • 0 in reply to lferrara

    It's one big forest so trusts won't be an issue.

     

    This was the info I needed. Everything I'd read so far vaguely indicated it needed to go on every DC but wasn't specific in saying it only needed to be on a couple of DC's.

     

    This just says "Download and Install STAS on the Additional Domain Controller(s)" 

     

    If that's the case then this is an easily solved problem

     

    Thanks

    Dave

  • 0 in reply to Dave Watkins

    Sorry, my bug mistake (I need to go to bed!).

    You have to install to all DC, otherwise audit events are not catched! The problem is that you can have up to 5 Collectors per each group. So in your case you need to create up to 10 collectors. I am not sure what is the maximum number of groups supported by XG.

    Let's see if or can help us to find out!

    Regards

  • 0 in reply to lferrara

    There are numerous ini files that get synced if you were to use the GUI configuration sync option.  Haven't tried it, but wouldn't think it's too difficult to wrap those ini files into a SCCM package and then restart the STAS services.

    Here is what that sync log looks like (with ini files located in install root):

    5/4/2017 1:33:45 PM [0x1750]: CAdvanceDialog::OnBnClickedCtaagentSync-> Config sync clicked...
    5/4/2017 1:33:51 PM [0x1750]: In CAdvanceDialog::CheckSuiteForConfigSync...
    5/4/2017 1:33:51 PM [0x1750]: CAdvanceDialog::CheckSuiteForConfigSync-> Config Sync Type...3
    5/4/2017 1:33:51 PM [0x1750]: CAdvanceDialog::CheckSuiteForConfigSync-> Config Sync Destination CTAS Type...3
    5/4/2017 1:33:51 PM [0x1750]: CAdvanceDialog::OnBnClickedCtaagentSync-> Sending config files to Ip 192.168.25.101 ...
    5/4/2017 1:33:51 PM [0x1750]: sendConfigFile_to_IP:: Sending stas.ini to server...
    5/4/2017 1:33:51 PM [0x1750]: sendConfigFile_to_IP:: stas.ini sent...
    5/4/2017 1:33:52 PM [0x1750]: sendConfigFile_to_IP:: sending coll-list.ini...
    5/4/2017 1:33:52 PM [0x1750]: sendConfigFile_to_IP:: coll-list.ini updated...
    5/4/2017 1:33:52 PM [0x1750]: sendConfigFile_to_IP:: coll-list.ini sent...
    5/4/2017 1:33:52 PM [0x1750]: sendConfigFile_to_IP:: Sending authnet-list.ini to server...
    5/4/2017 1:33:53 PM [0x1750]: sendConfigFile_to_IP:: authnet-list.ini sent...
    5/4/2017 1:33:53 PM [0x1750]: sendConfigFile_to_IP:: Sending cr-list.ini to server...
    5/4/2017 1:33:53 PM [0x1750]: sendConfigFile_to_IP:: cr-list.ini sent...
    5/4/2017 1:33:54 PM [0x1750]: sendConfigFile_to_IP:: Sending dc-list.ini to server...
    5/4/2017 1:33:54 PM [0x1750]: sendConfigFile_to_IP:: dc-list.ini sent...
    5/4/2017 1:33:54 PM [0x1750]: sendConfigFile_to_IP:: Sending ip-exclusion-list.ini to server...
    5/4/2017 1:33:55 PM [0x1750]: sendConfigFile_to_IP:: ip-exclusion-list.ini sent...
    5/4/2017 1:33:55 PM [0x1750]: sendConfigFile_to_IP:: Sending login-ip-exclusion-list.ini to server...
    5/4/2017 1:33:55 PM [0x1750]: sendConfigFile_to_IP:: login-ip-exclusion-list.ini sent...
    5/4/2017 1:33:55 PM [0x1750]: sendConfigFile_to_IP:: Sending logoff-exclusion-list.ini to server...
    5/4/2017 1:33:56 PM [0x1750]: sendConfigFile_to_IP:: logoff-exclusion-list.ini sent...
    5/4/2017 1:33:56 PM [0x1750]: sendConfigFile_to_IP:: Sending user-exclusion-list.ini to server...
    5/4/2017 1:33:56 PM [0x1750]: sendConfigFile_to_IP:: user-exclusion-list.ini sent...

    I may be way off here though.

  • 0 in reply to axsom1

    The problem is getting the agent installed on the DC's in the first place, and having an automated process to install it as new DC's are created, without command line options I can't see how that's possible without completely deconstructing the installer and copying all the files, registering any services and adding any registry entries all manually

  • 0 in reply to Dave Watkins

    It's unfortunate we have to try to hack it together.  Sadly we may have to raise this as a feature request to get Sophos to actually support it (if there is no other way to do it that is undocumented).

    I did test by running stas.exe /verysilent and copying the ini files.  Worked fine but the service wasn't installed in this mode.  I could pull out the service information and perform another test if you want.

    Would a redundant collector group with all 50 DC's communicating be feasible in your network design?  Are all the users in a single site or are there remote sites to consider?  Are there remote firewalls that will need to know the authenticated users?

    As far as I recall, we can have 5 collectors per group but only one collector is active.  We would setup multiple groups if we had remote sites to deal with.  

    Thanks,

    John

  • 0 in reply to axsom1

    Hi John

     

    Users are scattered over a lot of sites, some with Domain Controllers, some without, depending on site size and requirements to have a local server. All sites are connected over MPLS at decent speeds, so no remote firewalls. Everyone routes back to our Date Center for internet access where the firewalls actually are.

     

    If there is a /verysilent command line option then presumably there are others. Maybe a silent install is possible it's just the options aren't published. In saying that if we have multiple collectors anyway and the DC's can't all point to the same IP having an automated install may not help a great deal since you'd still have to go and tell it where to send it's data

     

    I haven't gotten deep enough yet to understand the collector design and layout so can't answer the question there. Ideally the collectors would live in our Data Center and the Domain Controller's that mostly live out on the sites would all pass to them.

     

    On the up side we did just manage to unlock IPS so it wasn't only using a single core so now we can turn that on and not cripple our bandwidth, so there has been one success today :)

     

    Dave