Sophos Endpoint Blocking updates

tycollins
New Contributor

4544464f-efac-4ee2-8377-12345eab15b7.png

Posting on here since Sophos has been less then helpful, We installed Sophos endpoint wither their Ventura Config profile and it looks like it works and is functional. However when I go to do an update on the computer while logged in as the local admin no password is accepted. Also when I go to More info and then install through that window it locks SophosEndpoint as the user name and no password I try works there. I've attached a screenshot of the weird login window I haven't seen before

image.png

7 REPLIES 7

AJPinto
Honored Contributor II

Looks like its performing permissions management over the softwareupdate binary. You will need to work with the vendor on this, even if they dont want to work with you. The application should be auto promoting this binary, and not prompting for anything so a rule is likely configured wrong.

 

We do not use Sophos but have a similar tool that handles point of time permissions management, and all kinds of rules have to be setup or it will break all kinds of stuff you dont want to break.

SCCM
Contributor III

How are you triggering the prompt? Ive not seen that before

s-mcc
New Contributor

Just ran into this same issue on one of our endpoints. 

 

We're looking into two possibilities right now: 

  1. As pointed out, the fact the softwareupdate process is calling a Group of "SophosEndpoint" that contained the primary user of our device (but deactivated) suggests it's doing something it 'aught not to be. 
  2. Can't see a single thing on the Config Profile from v1.1 to v1.2 that could contribute to that behavior, as a code issue being run by the auto-updater seems far more likely, but we're updating the affected machines to rule it out. 

I'll update this is we come up with an answer (or to rule these out). 

DCHGIT
New Contributor

@tycollins @s-mcc  anyone find a solution to this? I periodically receive the same error on Ventura.

@SCCM Initiating an OS upgrade from Settings will cause it:

DCHGIT_0-1697044207478.png

 

tonyalvaro
New Contributor

Currently experiencing the same issue. Sophos doesn't have any solution. I even tried uninstalling Sophos and I still get the prompt with SophosEndpoint as the username.

AJPinto
Honored Contributor II

We use CyberArk EPM, and last month I noticed if it installs before any user logs it EPM force generates macOS's Secure Token. Of course, EPM has no way to pass that secure token to a user. The vendor was as useless as you would expect. We wound up delaying the install of EPM until after Disk Encryption is enabled, that way the end user would have already logged in and they get a Secure Token and Volume Ownership before EPM can go and mess things up. I'd wager Sophos is doing the same thing.

s-mcc
New Contributor

I have a pending solution update to this:

We confirmed that all of these errors were related to the lack of volume ownership on the part of our affected users. 

Working with Sophos support, they became dead set on the cause being "Installation of Sophos before user login". 

Using the kb as reference (Use secure token, bootstrap token, and volume ownership in deployments - Apple Support) we created an extension attribute to hunt through our machines and report back any machines that had tokens assigned to the "_sophos" account. That list lined up with the machine errors we were seeing, (and some machines we had not yet).

We've broken out in to two phases for remediation:

  1. Even though the logistics of how Sophos installed post-enrollment but pre-login are not clear, we have added a delay into our Sophos installation polices. It was one of the few apps allowed to install outside of a dep-notify/swiftDialog initial configurations during setup (check-in trigger), and we added it to an "enrollment complete" delayed smart group to ensure even pausing at the Setup Assistant would not allow a background action. Since this change no more affected machines have appeared.
  2. Using the admin account created via our Pre-stage Enrollment, we're repairing the token issues for the affected users. So far that seems to be working, but I'm still waiting on full confirmation from my in-field team.