Sophos STAS

[mrbios]

Struggling to find a clear answer to this from anywhere, and all the guides online (of which there aren't many) don't seem to go in to any detail for the part I'm looking for information about...I've emailed sophos support, but their T1 support can take an age to reply, want to sort this out this holiday.

 

I've got Sophos STAS installed on my DCs - Currently running both the Agent and Collector on the DCs. However I've made a new member server setup to move the collector service to.

 

On the domain controllers, the service account running the Agent has to have Administrator or Domain admin rights - it reads from the event log of the DC.

The service account that runs the collector service needs to be able to read the remote registry or WMI of every workstation to detect logoff events. (as i understand it)

 

I've got two service accounts:

svc_stasagent

and

svc_stascollector

 

At the moment the svc_stasagent is in the Administrators group and a workstation admins group (which is deployed to all workstations as a member of the local Administrators group) and this works. However i don't like using one account for both, hence splitting them.

 

I plan to add both of these accounts to the security group i have that does "deny local login", add both to protected users group, and tick "account is sensitive and cannot be delegated" any reason any of those would cause an issue? When i try and save the stascollector account on the STAS Collector, if it's a member of protected users i get an error. If i remove it from protected users, save the credentials, then add it back in, the service seems to start fine and as far as i can tell it works. The only issue i've spotted is that with protected users added to the account, the test for "Registry read access" fails, while "WMI Verifications" succeeds. So i presume it'll be fine so long as i use WMI Verification.

 

Any thoughts from anyone who has used STAS on the more secure way of configuring this? Am i on the right track? Or any Wave9 chaps want to chip in? as i know you have a service that helps people set this up.

[Steve21]

Struggling to find a clear answer to this from anywhere, and all the guides online (of which there aren't many) don't seem to go in to any detail for the part I'm looking for information about...I've emailed sophos support, but their T1 support can take an age to reply, want to sort this out this holiday.

 

I've got Sophos STAS installed on my DCs - Currently running both the Agent and Collector on the DCs. However I've made a new member server setup to move the collector service to.

 

On the domain controllers, the service account running the Agent has to have Administrator or Domain admin rights - it reads from the event log of the DC.

The service account that runs the collector service needs to be able to read the remote registry or WMI of every workstation to detect logoff events. (as i understand it)

 

I've got two service accounts:

svc_stasagent

and

svc_stascollector

 

At the moment the svc_stasagent is in the Administrators group and a workstation admins group (which is deployed to all workstations as a member of the local Administrators group) and this works. However i don't like using one account for both, hence splitting them.

 

I plan to add both of these accounts to the security group i have that does "deny local login", add both to protected users group, and tick "account is sensitive and cannot be delegated" any reason any of those would cause an issue? When i try and save the stascollector account on the STAS Collector, if it's a member of protected users i get an error. If i remove it from protected users, save the credentials, then add it back in, the service seems to start fine and as far as i can tell it works. The only issue i've spotted is that with protected users added to the account, the test for "Registry read access" fails, while "WMI Verifications" succeeds. So i presume it'll be fine so long as i use WMI Verification.

 

Any thoughts from anyone who has used STAS on the more secure way of configuring this? Am i on the right track? Or any Wave9 chaps want to chip in? as i know you have a service that helps people set this up.

 

I had this argument when Wave9 set up our Sophos and the engineers wouldn’t do anything other than full admin rights on the account

 

Never really got an answer as to why, when as you say you can add accounts permissions for wmi etc

 

So would be interested to see if you get anywhere with this!

 

Steve

[mrbios]

I had this argument when Wave9 set up our Sophos and the engineers wouldn’t do anything other than full admin rights on the account

 

Never really got an answer as to why, when as you say you can add accounts permissions for wmi etc

 

So would be interested to see if you get anywhere with this!

 

Steve

 

Do you currently have Agent and Collector running together from the DCs like i do? or have you separated your agent and collector services?

 

I'm fairly certain it'll be a lot more secure with them separated and separate service accounts for each with the collector not having any domain admin rights. Will let you know how i get on with it next week though!

[Steve21]

Do you currently have Agent and Collector running together from the DCs like i do? or have you separated your agent and collector services?

 

I'm fairly certain it'll be a lot more secure with them separated and separate service accounts for each with the collector not having any domain admin rights. Will let you know how i get on with it next week though!

 

So ours is slightly different because one of our two DCs is core which isn’t supported by STAS

 

So we have one GUI DC installed directly, and then a member server monitoring for the Core DC

 

But there’s only one service account (being the admin one) that’s ours was installed under by Wave9

 

Steve

[mrbios]

So ours is slightly different because one of our two DCs is core which isn’t supported by STAS

 

So we have one GUI DC installed directly, and then a member server monitoring for the Core DC

 

But there’s only one service account (being the admin one) that’s ours was installed under by Wave9

 

Steve

 

So this seems to work, although i need to work out what firewall rule was stopping the collector from working because it wouldn't start serving the firewall until i disabled the inbound firewall on the collector machine.... EDIT: Nvm fixed that one, the guide i was using didn't mention udp 6677 inbound on the collector.

 

I've now got three user accounts for my sophos setup:

svc_sophosfirewall - The account the firewall uses to read AD, just a typical domain user, nothing special.

svc_sophosagent - The domain admin account used on the sophos agent on the DCs - added this to the protected users group, but you have to do that after saving the service credentials otherwise it moans at you. Looks as though it only talks to the collector via kerberos anyway so shouldn't matter that it can't do NTLM.

svc_sophoscollector - An account with local admin on all the desktops. Added to a workstation admins group which is deployed via gpp to all desktops local administrators. I still don't like that this has to be an admin on every workstation but it's got "account is sensitive and cannot be delegated ticked" and im going to added it to deny login locally group. It only needs to be able to be used to read WMI.

 

I think that's about as secure as i can make it. Highly frustrating that none of the guides out there describe this way of doing the accounts though, they all just seem to make one account and make it a domain admin which seems very lazy.

Edited April 11, 2023 by mrbios

[HereIGoAgain2601]

Do you have Sophos central av? We have just got rid of STAS and gone with the heartbeat authentication which is working a treat.

[mrbios]

Do you have Sophos central av? We have just got rid of STAS and gone with the heartbeat authentication which is working a treat.

 

No, no Sophos AV here. Only used for firewall purposes for user identification.

 

Also using RADIUS authentication for BYOD/non-domain wireless clients.