For years, I’ve been running Mac deployment projects for companies and schools. In a lot of cases, we’re asked to set the users to be non-admins. Lots of people have said to me that setting users to be non-admins can cause a lot of problems, so I thought I’d make the switch and try it out for myself.
For the past 6 weeks, I’ve been a non-admin and have been logging each time I’m prompted to enter the admin account details. In this blog, I’ll list out the events and dates and explain some of the things you will need to consider when you want to take away admin rights for your users.
It’s worth pointing out that my experience may not match everyone’s as it will depend on the apps you use and the kind of tasks you generally perform.
A bit of background
As a non-admin on a Mac, you only have right access (the ability to make changes) to your home folder and items inside it. Generally speaking, making any changes that would affect other users of the Mac is blocked. This includes changing some system preference settings, installing or updating applications or adding printers.
Although the log of events is quite long, the main reasons for admin prompts can be categorised into the following areas:
- Application Installs & updates – As expected, each time I installed a new app or installed an update to one of my apps I had to authenticate as an admin
- Performing Mac admin work – Running Mac admin apps like Composer from JAMF Software, running terminal commands and messing around in places like Directory Utility. I was going to pretty much count this out as these activities aren’t what a “normal” user would be doing. That being said, it is interesting to see that a Mac Admin can’t really work without at least access to admin credentials
- Reading passwords from my Keychain – I wouldn’t have thought this was an issue, but on the odd occasions when I wanted to read a password from my own Keychain, I had to enter an admin username and password (twice, which was a little annoying)
- Making network changes – As I move around a lot, working at different clients offices, I often have to adjust my network settings. Probably not an issue if you can get the network interfaces configured for your users ahead of time, but it was certainly an issue for me
- A few other odd cases – I had a few anomalies that cropped up. In one case, I ejected an external Thunderbolt drive. “UnmountAssistantAgent” needed me to enter an admin password before it would let me eject it. It hasn’t happened since so it was probably just a glitch
Things that specifically weren’t an issue
- Printing – Interestingly, this is one of the first things we adjust for non-admin users so they can add their own printers. Personally, as I already have the printers I needed, and rarely print anyway, this didn’t come up
- Mac App Store apps – Some of you will already know this, but the Mac App Store lets non-admin users install apps and update them
What can you do about the problem areas?
The main thing that constantly prompted for admin rights was updating non-Mac App Store apps. Flash, Hipchat, Adobe Acrobat, Omnifocus and lots of other apps were offering updates quite often. If you are the Mac admin for your organisation, you will need to make sure you handle the deployment of updates for your users, and ideally switch off any prompts so they aren’t bugged with update nags that they can’t do anything about.
Its safe to say that if you want your users to work as non-admins, you will need to implement a system that can deploy the updates for you. The Casper Suite from JAMF Software or Munki with AutoPKG are two example tools that will let you handle this.
The underlying system that determines whether a user is allowed to perform a particular action stores its rules in a SQLite database here /var/db/auth.db. It is possible to make adjustments to this database to grant access for non-admin users to specific system tasks. Note that to successfully allow a particular action, you may also need to add the user to specific system groups and / or alter permissions in certain file system areas.
Rich Trouton has written a great blog about the auth.db here.
Here is my log of events for anyone that is interested in the specific cases where admin rights were needed:
- 30th May – Omnifocus update
- 3rd June – Plugged in Thunderbolt monitor with an Ethernet cable connected. Needed admin credentials to add the interface, even though it had been added before
- 3rd June – Needed to check something in Directory Utility AD connector.
- 4th June – Used JAMF Composer to create a pkg
- 5th June – Google Earth update
- 8th June – Plugged in an iBeacon USB dongle, Mac saw it as a network interface and wanted admin credentials to add it
- 8th June – Read a password out of my Keychain, asked for admin credentials twice
- 9th June – Hipchat update
- 9th June – Had to create a clean user account to take some screenshots
- 9th June – Deleting some files from /Users/Shared
- 9th June – Editing CUPS printer at 127.0.0.1:631 to set B & W and Duplex as defaults
- 9th June – Flash update
- 17th June – Hipchat update
- 25th June – Connected to a clients guest network, but got stopped at the captive portal. Wanted to remove the network as it keeps auto-connecting to it
- 25th June – Plugged in a USB Ethernet adaptor, and I needed admin rights to connect.
- 25th June – PDF got stuck in my trash and needed admin rights to delete it
- 27th June – VMWare Fusion update
- 29th June – Changing network location (this shouldn’t need admin rights so was just a bug)
- 4th July – Omnifocus update
- 8th July – Needed to change the order of the preferred wireless networks
- 15th July – Read a password out of my Keychain, asked for admin credentials twice
- 15th July – Adobe Acrobat update
- 15th July – Installing a new Python IDE in /Applications