Tricking require an admin password to access system-wide settings

Summary

macOS has a setting under System Settings > Security and Privacy > Advanced called “Require an administrator password to access system-wide settings” (I’m going to call it “require admin setting” from here out). The help section describes this option as “Prevent users from changing locked system settings without an administrator’s password.” Unfortunately the setting doesn’t work as documented, and it can be set to “enabled” while still allowing standard users to modify system-wide settings.

You can see an example of what this looks like in this video.

On a fresh computer out of box the system administrator password is already required to unlock many system wide preference panes, like network for example. Enabling the require admin setting simply prevents that authentication from being shared with another pane. For example if an admin account unlocks the battery preference pane then leaves the computer a standard account could modify the network preference pane. In this write up we’re going to go over methods on how this setting can be modified so that both system settings and most compliance checks will incorrectly assume an administrator’s password is required to change settings, when in fact either a standard account’s password or no password at all will modify them.

A number of compliance benchmarks like CIS, STIG and NIST recommend enabling this feature to avoid standard accounts from changing some settings, like disabling content filtering or changing DNS settings.

macOS 14 Sonoma STIG: “The system must be configured to require an administrator password in order to modify the systemwide preferences in System Settings. Some Preference Panes in System Settings contain settings that affect the entire system. Requiring a password to unlock these system wide settings reduces the risk of a nonauthorized user modifying system configurations.”
CIS Apple macOS 14 Sonoma Benchmark, control 2.6.8: “By requiring a password to unlock system-wide System Preferences, the risk of a user changing configurations that affect the entire system is mitigated and requires an admin user to re-authenticate to make changes. Users will need to enter their password to unlock some additional preference panes that are unlocked by default like Network, Startup and Printers & Scanners. Run the following command to verify that accessing system-wide preferences requires an administrator password.”

Notes:

This has been reported to Apple Platform Security and it’s been considered a “Feature Request”. FB13705715 has been filed with Apple as a feature enhancement.

This has been reported to the macOS Security and compliance project and fixed.

This has been reported to the CIS team to update checks and remediations.

What the require admin setting changes

First let’s look at what the setting does, when enabling it in System Settings the authorizations database is edited for a number of system setting panes to set the “shared” key to the value “false”.

These preference panes are:

system.preferences
system.preferences.energysaver
system.preferences.network
system.preferences.printing
system.preferences.sharing
system.preferences.softwareupdate
system.preferences.startupdisk
system.preferences.timemachine

To validate what the setting changes you can use the following command with the setting both on and off, you’ll see the shared key change from true to false.

Command:

/usr/bin/security authorizationdb read system.preferences.network

Output (shared key in bold):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>allow-root</key>
	<true/>
	<key>authenticate-user</key>
	<true/>
	<key>class</key>
	<string>user</string>
	<key>group</key>
	<string>admin</string>
	<key>modified</key>
	<real>731951705.60508299</real>
	<key>session-owner</key>
	<false/>
	<key>shared</key>
	<false/>
	<key>timeout</key>
	<integer>2147483647</integer>
	<key>tries</key>
	<integer>10000</integer>
</dict>
</plist>

Apple’s authorizations documentation on the shared key is as follows, note that there is nothing in it about requiring an admin password:

If shared is set to true, then the Security Server marks the credentials used to gain this right as shared. The Security Server may use any shared credentials to authorize this right. For maximum security, set sharing to false so credentials stored by the Security Server for one application may not be used by another application.

https://developer.apple.com/library/archive/documentation/Security/Conceptual/authorization_concepts/02authconcepts/authconcepts.html

So according to Apple’s documentation it prevents a user from entering a password in one preference pane and sharing that authorization with another preference pane after.

Tricking the require admin setting

Reviewing the output in the previous section you’ll notice there are some other keys present that aren’t modified when enabling or disabling the require admin setting. Specifically the following are of interest to us:

group: The group of users allowed to modify settings after authentication. (Default admin)
session-owner: true/false if the current session owner is allowed to modify the setting. (Default false)
authenticate-user: true/false if authentication is necessary before making modifications. (Default true)
timeout: The credential used by this rule expires in the specified number of seconds. For maximum security where the user must authenticate or consent every time, set the timeout to 0. (default 2147483647)
- Note: Timeout only applies when the shared key is set to true

So for example setting the key “group” to the value “everyone” will allow any user on the system to modify settings or setting the “session-owner” key to “true“ will allow the currently logged in user to modify System Settings. You will need to modify authorizations for both the root system.preferences and the individual pane, otherwise the authorizations for the system.preferences will take precedence.

Some examples of false pass configs. Once applied, sign in as a standard user, open System Settings > Network and modify the DNS server. When prompted for “Administrator credentials” just enter the standard username and password and the settings will be applied. You’ll need to quit and re-open

First save these snippets as system.preferences.changes.plist file then run the following command to apply them.

sudo /usr/bin/security authorizationdb write system.preferences.network < system.preferences.changes.plist

sudo /usr/bin/security authorizationdb write system.preferences < system.preferences.changes.plist

Any user (standard or admin) can edit the network preferences with their password:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>authenticate-user</key>
	<true/>
	<key>class</key>
	<string>user</string>
	<key>group</key>
	<string>everyone</string>
	<key>session-owner</key>
	<false/>
	<key>shared</key>
	<false/>
</dict>
</plist>

The currently logged in user (standard or admin) can edit the network preferences without any authentication, even though admin group is required:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>authenticate-user</key>
	<false/>
	<key>class</key>
	<string>user</string>
	<key>group</key>
	<string>admin</string>
	<key>session-owner</key>
	<true/>
	<key>shared</key>
	<false/>
</dict>
</plist>

Properly requiring admin to unlock system-wide settings

If you’d like to properly require that an administrator is required to unlock system-wide settings then you’ll need to make sure all the following settings are set for each preference pane, in this example we’re only setting the root system.preferences and system.preferences.network

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>authenticate-user</key>
	<true/>
	<key>class</key>
	<string>user</string>
	<key>group</key>
	<string>admin</string>
	<key>session-owner</key>
	<false/>
	<key>shared</key>
	<false/>
</dict>
</plist>

Breaking the require admin setting

It’s also possible to put the authorizations in a state where the setting is no longer able to be toggled on/off. This will cause a failure and the slider in system settings will never stay “on” when you enable it. This occurs when the “class” key is set to a value other than “user”, in this example we’re setting the “class” key to “allow” which will always allow anyone to modify this setting:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>class</key>
	<string>allow</string>
</dict>
</plist>

Why change this setting?

If you’re asking “This setting requires admin to change, what’s the big deal?” then great question! There are a number of cases this setting could be changed without organizational knowledge:

Another current or previous administrator followed steps online to allow standard users to modify printers or modify network settings.
An application or application installer that runs as an admin installer modified the database without your knowledge.

For some organizations these are valid use cases and they should be taken into account.

How did you end up going down this rabbit hole?

I work at Mann Consulting, we co-manage Jamf instances for customers with high security needs. When implementing CIS Controls we found some computers weren’t providing us with consistent results. We found this was a result of changes made by a previous consulting firm that had since been removed from Jamf but the setting remained changed on the computers.

Special thanks to Bob Gendler for assistance in testing, documenting, providing feedback and listening to me curse this setting.

The following site also provided insights into all the setting available for authorizations.