The Great Debate: Should You Set Up Users as Admin or Standard?

What kind of accounts should you create when you provision Mac computers for your users: admin or standard?

It’s an age-old question in Apple IT. It’s an argument that pulls on many threads, including user convenience, IT workloads, and organizational security. And it has no easy, one-size-fits-all solution, which is why it’s been around so long.

To dig into that argument a bit and tease out some of those threads, Kandji’s Steven Vogt chatted recently with Rich Trouton. Rich has been doing Mac and server administration for over 20 years, in a variety of environments from higher ed and government to advertising and software development. He’s currently at SAP, where he supports that company’s Apple community.

Rich has also written extensively about managing Apple devices for Peachpit, Apress, and MacTech Magazine; his most recent book with co-author Charles Edge is Apple Device Management: A Unified Theory of Managing Macs, iPads, iPhones, and Apple TVs. He was also instrumental in bringing the SAP Privileges app—which addresses many of the concerns discussed below—to the Mac admin community.

Here’s a recap of that conversation. Check out the entire presentation here.

The User Spectrum

The admin versus standard issue has been around ever since Apple switched from Mac OS 9 to Mac OS X. In Mac OS 9, there was just one user who had the right to do anything they wanted. But when Apple switched to Unix, that brought multiple user roles to the Mac.

At one end of the spectrum, there’s the Unix root user. Apple really discourages anyone from running as root; before System Integrity Protection, a root user could do almost anything they wanted to the system. That’s no longer the case. In macOS Monterey, the system software isn't even running on a read-write disk, you’re actually booting from a snapshot of a cryptographically signed read-only volume that you can't alter. It doesn’t matter if you're running as root.

On the other end, you have standard users, who are generally restricted to making changes that impact only their own user-account spaces.

In the middle, you have admin users, who can do things that impact the system as a whole—adding and managing other users, installing apps for all users, changing settings, and so on. The admin user’s power has been somewhat limited by things like System Integrity Protection and Apple’s evolving privacy protections, but they can still do more than standard users.

Take, for example, an employee who travels a lot. They're crossing time zones, but for some reason Location Services isn’t updating their time zone settings automatically. So they call IT and say, "I'm in Barcelona, but my Mac is stuck on New York time."

If the user has admin rights, the IT person can say, "Go into System Preferences, go to Date and Time, click the lock, enter your password, hit Unlock, then you can change what you need to." A standard user in a similar situation is stuck. The IT department might have installed a tool that can change that setting remotely. Otherwise, the best you can do as an IT person is say you’ll fix it when they get back—way after it would be useful.

Another example is printers. By default, you need admin rights to manage them. IT could write a script adding those users to the group that handles printing rights—but that's extra work. If you give them admin rights, you can just tell them to click the lock in System Preferences and do what they need to do.

Then there are app updates. When apps like Firefox and Chrome start to update, a pop-up appears saying the installer needs a helper app—and that app requires admin rights because it needs to write to the /Applications folder, which is not writeable by a standard user. So you may need admin rights to run those updates.

The point is that having admin rights gives a user far more flexibility in handling their own stuff. But that flexibility comes with increased risks (which we’ll discuss more in a minute). Some organizations may opt against that. They may try to work around the problem by creating scripts and other tools. But inevitably they run into situations that they didn't think of, that they didn’t create tools to fix.

So that's the trade-off: You may lower your risk by making everyone a standard user, but then you’re committing yourself to more work. Or you accept some risks and make people admin users.

Security vs. Usability

What those risks are depends a lot on the kinds of security and regulatory requirements you have. Because if you have legal requirements that say, “Thou shalt not let anyone have admin privileges,” then that's the end of the argument: The law says you’ve got to do it, so you do it.

In a developer environment, different levels of security are needed. If you're a military defense contractor, you've probably got rules that other developers never have to deal with. You have to consider, What are the rules that I have to follow? And what is the client mandating?

The compliance framework an organization follows might not be as black and white as, “Thou shalt make everyone a standard user.” It’s important to make sure you understand the standards that you are trying to meet. A lot of IT departments will think, "We can't have people run as admin because our security requirements say we can't"—but nobody has actually looked closely at those requirements.

If you’re your own shop and just want to follow best practices, it really behooves you to figure out what makes sense for you. Security is supposed to protect the business, not stop it. Too many IT shops say, "I’m busy and this is what I've been told to do," without doing a careful evaluation of the consequences.

From the perspective of Mac device management, there isn’t a huge gap between standard and admin. If you’re managing Mac systems with MDM, you can enforce settings and layer on restrictions to meet security requirements. These restrictions will apply regardless of whether the user is admin or standard. For example, maybe you want to restrict SSH or the use of sudo. Even admin users are subject to these restrictions when enforced by MDM.

Trust and Company Culture

Giving users admin privileges can have some subtle impacts on company culture. If you give your folks those rights, you're expecting them to solve more of their problems for themselves while opening yourself up to more risk. Anytime you open yourself up to risk because you want to give something to someone else, that’s trust. You're saying, “I trust you to use this responsibly.” I'm trusting you to act like an adult who has been given a tool with the expectation that you're going to use it responsibly.

You're handing a laptop to an adult who managed to get out of bed and get to work and is expected to do things that make money for your business. If you're trusting them to do all that, why wouldn't you trust them enough to make them admin?

The decision to make users admin or standard sometimes comes from an organization's leadership—the CTO, perhaps, or the security team. You need to communicate with them so they can make an informed decision.

If you have a dedicated security team, how deep is their understanding of macOS? Because if they don’t understand how macOS works, you'll need to educate them. If they do understand how it works but they still want to stick with making everyone a standard user, you’re facing a tougher discussion.

Sometimes the best way for IT to understand how taking away admin rights will impact the user is to live in that environment yourself. What problems do you see day to day on your Mac? Which ones could be solved by granting yourself admin rights?

However, when communicating with management, it’s not a good idea to make them unwillingly live as standard users, because you’re going to get pushback—you’re taking something away, and anytime you do that you’re going to have resistance. The alternative might be to frame the discussion as, “We want to show that we trust folks.”

But overall, you have to take it down to pros and cons: The advantages of making people admin uses are that you save time for IT by making things more self-service and you can help the company culture by showing that you trust people. But you also have to look at the risks you assume. It’s a very holistic discussion to have.

About Kandji

With Kandji, you can specify whether the user account created during Automated Device Enrollment is standard or administrator. You can also use Kandji's Auto Apps feature to install SAP Privileges. With powerful and time-saving features such as zero-touch deployment, one-click compliance templates, and plenty more, Kandji has everything you need to manage your Apple fleet in the modern workplace.