Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 3 replies
  • Subscribers 3 subscribers
  • Views 14292 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

Script To Disable Tamper Protection?

Robert Neal

We have a Server/Client environment with Sophos Enterprise Console running on a main server and Sophos Endpoint Security and Control installed on a few hundred clients.  In many cases, I'm not able to disable Tamper Protection, which is causing a lot of issues. 

Some computers disable within minutes by dropping the computer into a "No Update" group in the Sophos Enterprise Console, but most take hours or don't disable at all.  On the ones that don't disable, if you log in manually, "Configure Tamper Protection" and "Authenticate User" are greyed out.

Is there any way to just create a script (or powershell script) that disables tamper protection?  We (obviously) have the proper credentials to disable it, so just running a script with those credentials before I need to disable it would be a good enough solution.

Is that even possible?



This thread was automatically locked due to age.
Parents
  • +1

    Hello Robert Neal,

    coincidentally I've written about disabling TP programmatically yesterday.

    [TP] greyed out
    the screenshot suggests that the logged on user is not a member of the SophosAdminstrator group. This is how it looks for a SophosUser. Anyway, the endpoints should apply the settings from the policy. within minutes is the expected behaviour when a two-way communication (SEC able to connect to the endpoint's port 8194) exist, otherwise a policy can only be sent in response to a message from the endpoint but even then hours is a little bit much. Do the endpoints eventually comply with the other policies and just not TP? I'd first rule out a communication problem.

    What is the underlying lot of issues that causes the need for disabling TP?   

    Christian

Reply
  • +1

    Hello Robert Neal,

    coincidentally I've written about disabling TP programmatically yesterday.

    [TP] greyed out
    the screenshot suggests that the logged on user is not a member of the SophosAdminstrator group. This is how it looks for a SophosUser. Anyway, the endpoints should apply the settings from the policy. within minutes is the expected behaviour when a two-way communication (SEC able to connect to the endpoint's port 8194) exist, otherwise a policy can only be sent in response to a message from the endpoint but even then hours is a little bit much. Do the endpoints eventually comply with the other policies and just not TP? I'd first rule out a communication problem.

    What is the underlying lot of issues that causes the need for disabling TP?   

    Christian

Children
  • 0 in reply to QC

    Hi Christian, thanks for responding!  Correct, that screenshot is from a "user" machine, but as an admin, I was hoping for some way to force an un-installation.  I'd like to avoid logging directly into the users machine if possible.  

    Unfortunately, the endopints very often don't have the new policies applied...either in a timely manner or at all.  Just to confirm, this doesn't happen on every machine at a location, just a random 1 out of 10.

    Disabling TP would mostly be required when uninstalling an agent.  This can be do to customer offboarding, re-installation of Sophos or during the rare occasion that AV interferes with a software installation.  It's actually a scenario that comes up often.

  • 0 in reply to Robert Neal

    Hello Robert Neal,

    a scenario that comes up often
    and I thought that I live in a hostile (University) environment [;)].
    Seriously, the bigger part of our several thousand endpoints are locally administered (naturally TP is not enabled), lots of laptops. heterogeneous hard- and software, various OS versions (including pre-installed OEM builds).
    very often don't have the new policies applied
    Nevertheless, even though the downstream RMS channel is often not available management works as it's supposed to do - either the endpoint complies within minutes at least in less than one hour or so. The TP policy shouldn't be an exception. As said, our environment can hardly be described as "clean" and homogenous and in view of this fact and my experience I'd say that 1 out of 10 is way too much. Thus I wonder if there's some perhaps obscure underlying common cause. As I've mentioned I'd try to determine why some endpoints "refuse" to comply - might be a communication (RMS) issue, might be an endpoint-infrastructure (COM) problem, might be a failing component.

    Christian

Unfiltered HTML