We'd love to hear about it! Click here to go to the product suggestion community
We have password audits and with Sophos installed on the DC's it shows as an AD account that has a password set to never expire. Can I set it to expire and reset it?
Please see What is the SophosSAU account? It should answer most of your questions.
And give my regards to your auditor . A password set to never expire - so what? What's the significance of changing the password of this account? A reasonable lockout policy thwarts any password guessing attack. The account's rights are limited (although it has Log on as a service). And if someone manages to grab the obfuscated value from the registry and deobfuscate it or otherwise obtains the actual value - what the hacker could do with this account is probably your least concern.
In reply to QC:
I am finally getting around to try this and the directions are not accurate or it can no longer be done. Trying to do it on a 2016 Domain controller.
In reply to B_B:
directions are not accurateexcept that they refer to a local account only (on a DC it's a domain account) they seem to be correct. I've just tested the procedure on a 2016 (though not a DC but that shouldn't make a difference). What makes you think it can no longer be done?
It was at the end of the day so I might have missed something. I was logged in as a domain admin and did not have rights to change the config file. Do I need to be the actual administrator?
if you open the file from Explorer the editor (Notepad, whatever) is normally in user mode. If it's a location where approval is required you can't subsequently save the file. Some editors recognize the situation and offer you to elevate themselves. For Notepad run it as admin and use the Open dialog to edit the config.
I should have said that I ran Notepad as admin. When that didn't work I saved the file somewhere else and tried to copy/move to folder to overwrite didn't work.
hm, haven't worked with a 2016 DC - not even an admin can modify files under ProgramData? Does psexec.exe still work, i.e. enable you to run commands as SYSTEM?
I think we are in different places in our lives. I blame Sophos first for pretty much everything at this point in my life.
It has nothing to do with it being in ProgramData folder or it being a DC because I can modify other files in ProgramData that are not in the Sophos folder.
different places maybe, I tend to forget to mention Tamper Protection, or rather turning it off when manipulating an installation.
I guess I should have asked if you realize I am posting in the sophos central forum because of the issues I am having.
So from my understanding the directions give you two options. Either change the account used or change the password with a new value.
Yes. You will need to edit the HKLM\Software\Sophos\AutoUpdate\Service registry key and enter the credentials of an account that can be used for this impersonation.
There isn't a AutoUpdate in HKLM\Software\Sophos\
Changing the password This is for on prem. I do not see these settings for Sophos Central Agent
I have to apologize, I didn't think. As to posting in the sophos central forum - no offence intended but posts don't always end up in the most applicable forum.
As said, I did not think. The minor shortcoming: HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\AutoUpdate\ - I missed the missing reference to bitness, most Sophos components are 32bit and the keys are under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ on 64bit systems. The bigger mistake is the oversight w.r.t. the local GUI - guess the GUI for Central Endpoint doesn't display the update settings as changing them doesn't make sense.Thinking it over I'm pretty sure that AutoUpdate doesn't need the impersonation account in a Central installation. The account is used when accessing an update location via UNC. It might be that the account is only impersonated when updating via UNC is attempted, and Central updates via HTTPS. If you disable the account - does it still update? Could this be a solution?
Is there any chance we can have someone from Sophos pipe in on if it's actually needed? I am really not a fan of using a DC to test. We all know how hard it is to fix when Sophos has issues.
Christian I appreciate all the help and as much as your in the community I forget you don't work for Sophos and I am sorry for being short and rude.
I don't see where you have been rude :)
not a fan of using a DC to testno other computer on Central? Doesn't matter whether the account is local or AD. If AutoUpdate requires that it can impersonate it before updating the you'll get an error when it's disabled. Nothing bad will happen otherwise and once re-enabled updating works as before.
I know and was going to. I am just tired of doing Sophos job for them. If it's not needed then why is it added? If it's for the..... MY GOD Seriously .... I just logged in to make sure I said the correct name of the proxy and there is this below. So does this replace the SophosSAU account?
If it's not needed then why is it added?because it was always there. Sophos tries to not to branch components and their installers as far as possible. Thus AutoUpdate can work with on-premise UNC and HTTP, and HTTP from Sophos (as fallback for roaming endpoints) updating, and for Central HTTPS from Sophos or a cache. And, BTW, it can also update PureMessage's SPAM rules.
Proxy is not related to SophosSAU, the option to define a proxy has "always" been there. As said, the impersonation account should only apply to UNC updating.