Preventing Standard Users from Upgrading macOS?

MNussbaum
New Contributor III

Very recently we've had some users who have upgraded their version of macOS beyond Monterey up to Ventura or Sonoma (I know, we need to get away from it ASAP, but we're stuck a bit longer because of the Microsoft/Adobe SMB hidden file issue).

Our staff are all standard users and do not have admin access to their computers. In the past, any attempt to upgrade macOS to a new version would not be possible without entering admin credentials.

Why is this suddenly being allowed to happen and what is the best practice using Jamf to prevent it?

7 REPLIES 7

sdagley
Esteemed Contributor II

@MNussbaum You need to use the forceDelayedMajorSoftwareUpdates key in a Restrictions payload (https://support.apple.com/guide/deployment/installing-and-enforcing-software-updates-depd30715cbb/we...). Apple now makes macOS upgrades available as Delta updates which can be applied via the Software Update process instead of having to then the fill Install macOS app which requires admin rights.

AJPinto
Honored Contributor III

You can only block OS updates for up to 90 days with a Configuration Profile, that is the longest you can block updates. At this point you can only defer macOS 14.6 and 14.6.1, everything else is free game to install. Apple updated their OS update and deferral workflow a few years ago, and made Major OS updates use the same workflow as minor OS updates.

 

Be very aware that macOS 12 Monterey has likely seen its last security update, I very highly doubt it will get the next round of security updates that come out in September. Basically, you are out of time, you need to update. An issue with SMB not working right with Adobe will likely be easier to swallow than a data breach from running an unpatched OS.

MNussbaum
New Contributor III

That is what I believed to be the case but was hopeful someone had a solution that could prevent the macOS upgrades beyond the 90 day deferral.

Definitely aware that we are overdue to move away from macOS Monterey. Microsoft and Adobe apps are going to lose their current + 2 support as well. Unfortunately our workflows rely heavily on working directly on SMB shares, so we're working to get all of that data moved off of those as quickly as we can.

sdagley
Esteemed Contributor II

Unfortunately Apple's view is 90 days should be sufficient for organizations to adopt new macOS upgrades regardless of whether or not they want or are ready to.

You _could_ try deploying a Restricted Software configuration to terminate the com.apple.MobileSoftwareUpdate.UpdateBrainService process any time it's detected as running which will prevent the software update process from putting the downloaded installer pieces together. That probably is NOT a good idea though.

And what is the "Microsoft/Adobe SMB hidden file issue" as I don't think I've seen that mentioned as a need to stay on macOS Monterey before?

AJPinto
Honored Contributor III

You not being able to defer beyond 90 days is what apple wants, there is not really a "solution" for this as it is working as intended. Honestly, if Adobe/MS have not "fixed" something in 3 years they are not going to fix it. A new workflow needs to be identified. It sucks as an admin to be in your position, we have all been there before :).

mschlosser
Contributor II

Interesting question, i'd have to consider long and hard before doing this, because i'm sure it has many implications; however you could try removing the user accounts secure token. then they wouldn't be able to approve software updates, no matter how they were downloaded.

from documentation: "If a user does not have a secure token associated with their account, this account will not have access to perform any critical tasks on the macOS device, including – approving system extensions, kernel extensions, enabling FileVault and approving software updates on a Mac."

So a lot of drawbacks to consider.

M

This is a terrible idea. Removing the secureToken will also prevent users from being able to unlock filevault and log into the machine, not just enable it. In addition, you'll also invalidate the bootstrap token in Jamf Pro and that is needed for Jamf to manage the system effectively.