Preventing root access

Assuming that they're doing this from the command line, one approach you could take is to remove the admin group from /etc/sudoers.

The main change would be removing the %admin entry (which stands for the admin group) from the User privilege specification section and replacing it with the entry for your local admin account.

For example, assuming your local admin account was named localadmin, you could change the User privilege specification section from this:

##
## User privilege specification
##
root ALL=(ALL) ALL
%admin  ALL=(ALL) ALL

To this:

##
## User privilege specification
##
root ALL=(ALL) ALL
localadmin  ALL=(ALL) ALL

At that point, your users will have admin rights in the GUI, but they'll effectively be standard users on the command line.

• Don't allow your users to be admins
• They can still become root via single user mode (not sure about El Capitan, but probably so) ** You can disable this by setting the open efi firmware password, but this may cause other issues... it's a trade-off.

I would also suggest showing your users how not having admin access won't affect them with normal use... perhaps deploy a few "tester" machines to them and then have them ask you for regular things they need. You can then publish in Self Service... I found this a great way to empower my users, while keeping control.

@rtrouton Thanks for the info! I'll certainly take a look at this. Can you tell me if making this change would in any way affect the Casper management account? Without having dug into this yet would I be correct in assuming that I would need to specify that account in this file if I remove %admin?

@Kedgar I wish I could prevent them from being admins but when the president of the campus has stated everyone should have admin rights, we have to choose our battles wisely. I have at least removed admin rights from the lab and classroom systems I support. In those cases I could convince the dept chair that this was needed and didn't negatively impact the students.

The other part of this is that there is concern about who has admin access on each other's systems to the point that the president manages his own system with it not being in our directory services and our CIO feels that it might be too tempting for even tech support people to want to look through the data on their systems or file shares that are mounted. Basically people want admin on their own systems but don't want anyone else to have admin except when they need that person to have it.

With this bit of info that rtrouton has shared I might be able to accommodate this to some degree but the worry is in terms of technical support is what negative impact would this bring if it works the way I think it does?

@jhuls, you would need to specify the Casper management account in the /etc/sudoers file, as it normally gets its ability to use sudo via the account being a member of the admin group. So if your local admin account is named localadmin and your Casper management account is called caspermanage, the relevant section of the /etc/sudoers file would look like this:

##
## User privilege specification
##
root ALL=(ALL) ALL
localadmin  ALL=(ALL) ALL
caspermanage  ALL=(ALL) ALL

@rtrouton Thanks so much! That's what I suspected.

Of course the next question would be...what's the best method for deploying a change to this file? Can this be replaced using a dmg of the file edited to our needs and created with Composer or is it best to script the change? I'm not exactly an expert at scripting but aren't afraid to get my hands dirty. Having said that though if I can deploy my own sudoers file as a dmg that's much simpler and I'm all for simple. ;-)

Be careful, by making this change in the sudoers file, you may be breaking something that was deemed necessary as outlined by their requirement to having admin rights as dictated by the President of the campus.

Is it worth fighting this? If you've highlighted what you feel to be the pitfalls and those in charge are not bothered, then persisting with this is probably only going to bring you stress and heartache. As long as you are happy that you have provided this info, then any subsequent wrong doing from this is no longer your concern; just make sure you have a paper trail to your documentation.

If you feel that you can't manage the machines in a way that you feel is fit and no one is willing to listen, then perhaps the best solution is moving on to somewhere new. Just make sure you ask in the interview what their policy is for users and access rights on their machines!