I’ll die If I don’t get admin rights

The mobile device management (MDM) engineer at a high-security organisation can often find themself refereeing a tug of war between the usability and support requirements of high-end users, like developers and security personnel.

I've been there, and it's a terrible place to be. You've barely started to sketch build requirements before you hear the pleas, "admin rights, admin rights."

I started by explaining that I could give them tools in Jamf to perform the tasks without elevated privileges. A policy in Jamf can easily run a single command or script with elevated privileges. It also allows support team members to track the Mac's setup through the computer's Jamf policy log. It's not just security, but also the user who can benefit.

The next thing is to get a good list of requirements from the users. They should be able to give you a starting point.

Common Sense

You also need some common sense. When I first looked at the requirements, I resisted installing Homebrew, as it allows a wide range of tools to be installed. As I thought about it more, I noticed that because Homebrew only installs in the user space /usr/local, it's not really a security hole. If you want to keep an eye on the use of Homebrew, then an extension attribute that lists the contents of /usr/local/Cellar or the output of brew list will do that.

I don't use it to install the software I manage, but giving it to users offers them an element of control. Installing it as the end user with elevated privileges is not easy, but I found a script on Jamf Nation that could be quickly adapted.

That's another thing I learned. If you're having a problem, then someone else likely has the answer. It's worth reaching out on Jamf Nation or in one of the MacAdmins Slack channels.

A Swift Response

When you solve the first requirements, it's time for some beta testing of the build. Users will forget things, even though they do them regularly. It's not even worth complaining about it, it's just how it is. You would probably be the same.

To keep the noise about admin rights at a low level, you need to give a swift response to any request. Even if the first response is, "OK, noted. I'm working on, and I'll get back to you soon."

Champions

You should find some champions, senior members of the users and explain exactly why you are restricting admin rights. Assure them you can provide a better support experience if you know what's been done to a Mac. Listen to their concerns and share some of yours. Make them a partner in solving problems as they arise.

An Example

In my experience, the most vocal group was the iOS developers. They needed to install multiple versions of Xcode, switch between them, and when it's no longer required, uninstall an old version. I could see their point.

I don't know if you've ever had the joy of handling Xcode, but even uploading a package that is up to 8Gb in size is a problem. Downloading it is better, but if the net is slow it can get dicey too. I came up with a solution I thought would do.

All of the iOS developers had been perfectly happy downloading and installing Xcode previously, so I wrote a script that looked in ~/Downloads for Xcode.app, installed it and its support packages before checking what version it thought it was and renaming it to match. The developers can easily download from Apple, and I need never touch Xcode again.

The Lesson

What did I learn in this process? The biggest thing is that the demand for admin rights is just as much a personal thing as it is a tech thing. Don't let it become a battle, make it a partnership where you can deliver a secure build while delivering what the user wants to get their job done.