Standard users in macOS enterprise settings

Security standards in many organizations require users to run as standard users. In the past, not having local admin rights would often cause issues as more software required elevated rights. For instance, the Adobe applications would not work as expected. On modern versions of macOS and Windows however, users can do most things without local admin rights. Adobe and Microsoft have made sure their application suites work well without local admin rights and on Windows, enrolling users as standard users is common.

Although Unix systems are secure multi-user systems by design, on macOS, there are a few quirks when running as a standard user. For instance, standard users are not able to use the Printers & Scanners and Network preference panes in System Preferences, preventing them from adding printers and wireless networks.

Apple has provided guidance to schools that enroll their students as standard users, allowing them access to printing and wireless networks. Other sysadmins have also located relevant preferences. The script below, will let most users run as standard users without any issues.

# Provides standard user access to preference panels they would expect to be able to access, and might need access to.
# Provides standard users access to system preferences
/usr/bin/security authorizationdb write system.preferences allow
# Provides standard users access to network preferences
/usr/bin/security authorizationdb write allow
/usr/bin/security authorizationdb write allow
# Provides standard users access to printing preferences
/usr/bin/security authorizationdb write system.preferences.printing allow
/usr/bin/security authorizationdb write system.print.admin allow
/usr/sbin/dseditgroup -o edit -a staff -t group lpadmin
# Provides standard users access to energy saver
/usr/bin/security authorizationdb write system.preferences.energysaver allow
# Provides standard users access to Find My Mac
#/usr/bin/security authorizationdb write allow

Some apps can be run from the user’s home folder, but installing software on macOS mostly requires local admin user rights.

One can limit what is available to packages from IT, presenting a selection of user-installable apps in Jamf Self Service or another similar solution. For this to actually be more secure it is important to use clean VMs or a workstation specifically for building packages, that isn’t used for anything else.

App Store access can be allowed with a config profile.

You can also give individual users that need elevated rights separate admin users they can use for specific purposes, by entering those credentials as needed.

The above is usually the more secure solution, and should also be how IT admins set up their own users unless they have a good reason not to. There’s also the possibility of using a Self Service script to let users give themselves temporary admin rights to perform installations, or, which lets you toggle. The app might be a good solution for developers who need local admin rights frequently.

This doesn’t address everything, though.

In some areas, macOS does not seem fully prepared for standard users or device management.

FileVault, for instance, requires SecureToken before it can be enabled. SecureToken is only given to the first admin user created on a system, and can only be given to another user via GUI user action.

If you are using Jamf and DEP PreStage enrollment, enrolling users as standard users will cause a situation where there is no SecureToken – and FileVault cannot be enabled.

Some organizations create an admin user on every machine first, and manually create more users. This seems to go against how DEP was intended to work, however. Also, such a setup isn’t really zero-touch deployment.

If you enroll users as admin users and script their conversion to standard users as part of initial setup, they do get SecureToken and FileVault can be enabled. However, the Jamf admin user and any other admin users created by Jamf will not get SecureToken or FileVault access (also applicable if your users are enrolled as local admin users). Such a setup obviously also does not follow Apple’s intentions. Admin users without FileVault access are not able to access Startup Security Utility in Recovery either. Giving SecureToken to an admin requires converting the initial user back to an admin as well as GUI action from the user. Furthermore, activating FileVault using a configuration profile requires a user-initiated restart, but some users rarely perform one. Unless your MDM solution has built-in support for reminding the user to do so, you would have to script the reminders or perform the restart for them.

Check out Travelling Tech Guy’s wrap-up on Secure Tokens.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s