Require an administrator password to Access System-Wide Preferences - Scripted method not working!

Legendary Contributor III

Ok, I resisted posting this for a while, but I've finally given up and am throwing in the towel, in the hopes that someone who is/has experienced what I'm facing found a solution.

As part of our hardening process, we follow many of the recommendations provided in the CIS Benchmark guides. One of them is the subject of this title - enabling the "Require an administrator password to access system-wide preferences" checkbox under the Advanced section of Security & Privacy. The CIS guide, even the current ones, recommend using a scripted method, something like

/usr/bin/security authorizationdb read system.preferences > /tmp/system.preferences.plist

/usr/bin/defaults write /tmp/system.preferences.plist shared -bool false

/usr/bin/security authorizationdb write system.preferences < /tmp/system.preferences.plist

I was using this all throughout macOS Catalina and Big Sur, and even, I think for earlier versions of Monterey. But somewhere along the line, this just stopped working. I can't get the shared false value to appear when reading back the system.preferences using security authorizationdb. And the checkbox is not checked in the GUI.

I've seen some other threads here where this setting was discussed and it looks like I'm not alone in having trouble getting this to work on Monterey and up.

So I'm posing the question here. I've tried literally every imaginable thing I can think of, and cannot get this to apply to any of our devices anymore. Has anyone run into this and found a solution? Is this just irreparably broken, maybe on managed devices only? Something Apple has to fix? I'm stumped as to why it won't apply. And, why does the CIS guide continue to recommend it? It must be working for the team who assembles that guide, so I wonder where the issue lies. There has to be a reason, but all my searches for why this isn't working have turned up nothing.


Valued Contributor

I use...

security authorizationdb read system.preferences > /tmp/system.preferences.plist
/usr/libexec/PlistBuddy -c "Set :shared false" /tmp/system.preferences.plist
security authorizationdb write system.preferences < /tmp/system.preferences.plist

This is working on Ventura.


Valued Contributor

You'll unfortunately need a much more complex to really work on Ventura.

  authDBs=("system.preferences" "system.preferences.energysaver" "" "system.preferences.printing" "system.preferences.sharing" "system.preferences.softwareupdate" "system.preferences.startupdisk" "system.preferences.timemachine")

  for section in ${authDBs[@]}; do
  /usr/bin/security -q authorizationdb read "$section" > "/tmp/$section.plist"
  key_value=$(/usr/libexec/PlistBuddy -c "Print :shared" "/tmp/$section.plist" 2>&1)
  	if [[ "$key_value" == *"Does Not Exist"* ]]; then
    		/usr/libexec/PlistBuddy -c "Add :shared bool false" "/tmp/$section.plist"
    		/usr/libexec/PlistBuddy -c "Set :shared false" "/tmp/$section.plist"
    	/usr/bin/security -q authorizationdb write "$section" < "/tmp/$section.plist"

Legendary Contributor III

Thank you both @boberito and @PaulHazelden for your suggestions.

I had seen the use of PlistBuddy in some alternate scripts for this, and I tried it but wasn't having much luck. I had not yet seen the more comprehensive script from you @boberito so thank you for that. I've given that a try.

The thing is, even after trying these methods, the checkbox in the GUI is not checked. I don't know if that's simply a visual/GUI issue or if it means the settings aren't actually getting applied. Any thoughts on this? Are you seeing the box checked in the UI or does it also remain unchecked for you?

In the end I'll need to rework some of the items I have that check our hardening compliance settings to see how to confirm this is in place.

Valued Contributor

There's a lot of places where UI won't necessarily match the value of the settings when you set it in sort of non supported Apple ways. So I wouldn't put too much stock into the UI checkbox.

New Contributor III

@boberito I am having mixed results with this script on Ventura. Some of the machines in environment pass the check and others fail. I took a machine, wiped it and then enrolled the device to get all policies/profiles including this script and it passed the check. I even upgraded it to Sonoma and it still passed. So not sure why some machines come back as failed and some don't. The logs for the script show a return code 0, that it was successful. I even tried running the script manually on one of the affected machines and it still failed.

We only have 1 config profile using restrictions and the system preferences is not modified in the profile. 

New Contributor

I think i found the issue why some Ventura and Sonoma machine failed to apply the Require an administrator password to access system-wide preferences script. The reason is because the existing machine earlier had applied below command will not going to work to add share false value. Is there anyone here know how to revert back below command to original state?

/usr/bin/security authorizationdb write system.preferences allow