Admin Users in your Environment?

[Janowski]

Hello fellow JAMF users!

I have a non-technical question for you. Any of you folks in an environment where you have a special development crew whose basic needs and daily duties fall outside of the rules and policies meant to protect the the rest of your business? (e.g. unique combinations of web sharing, FTPing, hosting databases locally and almost daily updates to 3rd party apps and workflows).

We're in that boat and I'm interested in talking to folks that have been successful in addressing this kind of scenario.

We have some users in our environment we can manage with traditional means (AD groups, etc) but we're thinking of isolating these special devs and need to know more about how that theory works in practice.

thanks!

[davidacland]

One of the environments we support has a number of these user groups. To complicate things they have "traditionally" always had admin rights so taking them away presents a social challenge ;)

My ideal scenario is to work with the authorisation db, make them non-admins and give them the specific additional rights they need. We have had quite a lot of success with this, particularly when users only need one or two things. Xampp was a good example where this worked well. We allowed them to use sudo, but only for this one binary.

An issue with this approach is the process and methods changing with each OS release, giving you a lot of extra work each time you want to roll out an OS update. The further away you get from a vanilla install, the messier it gets.

In reality, there isn't enough time in the day for that kind of thing, so you often have to give in and give them admin rights.

I think some of the recent press adds more weight to people operating as standard users though and only elevating when required.

[dpertschi]

@Janowski I think the need by some user groups is completely legitimate; to be unencumbered by restrictive usage management, BUT- those users must enter into an agreeable safe use policy with their management and HR, in person and in writing. The user has to understand, from a business perspective, that granting elevated rights on the company network is a risk with consequences.

No exceptions, if the users are found to be deviating from the safe use policy or otherwise circumventing company security and patching policies, they go to the principle and get written up.

I know, easy for me to say sitting at the bottom of the pole, but it should be that simple.

[rhs615]

Hi @davidacland - thanks for the info. I just got a request to install Xampp on all lab machines for students learning web design. I'm trying to figure out how to approach this. I haven't working with the authorization db, but I'd be interesting in learning more about what you did. Can you go into more detail? Ideally, I'd like to scope Xampp permission to a particular LDAP group.

Thank you in advance..

[RobertHammen]

I'm not @davidacland but this has always been my "bible" on authorization (on Mavericks and later):

https://www.afp548.com/2013/10/22/modifying-the-os-x-mavericks-authorization-database/

[davidacland]

Hi @rhs615, for Xampp we add the specific files to the sudoers file for the particular group:

#!/bin/sh
echo "%NETBIOSDOMAIN\\Domain Users ALL= NOPASSWD:/Applications/XAMPP/xamppfiles/*" >> /etc/sudoers
exit 0

Just replace NETBIOSDOMAIN with you short domain name and change the particular group you need.

[rhs615]

Thank you, @RobertHammen and @davidacland - much appreciated!

[lashomb]

We use sudoers for our devs and it works fine. They are not allowed to install software, but they can download things to try and install frameworks into their webroot.

You can use puppet/chef or even self service scripts in Casper for permissions, like editing /etc/hosts or Apache files.

[tlarkin]

Hey Everyone,

Just wanted to chime in here about modifying the /etc/sudoers file. You should never edit the file directly, and you should only ever append or edit a copy of the file and then use visudo to verify that the file is formatted properly. Once verified you can then move it over or rename it to the proper file. Just echoing out a string to append the file can break it, and then put your system in a bad state of functionality.

Thanks
Tom

[rtrouton]

One thing I used to do was back up the existing sudoers file and then drop a new one in place. For example, use a package to drop a file named sudoers.new into /etc, then have the package run a postinstall script like this:

WARNING: Not tested, written from memory. May blow up stuff, make puppies indolent and kittens grim.

#!/bin/bash
FILE_DATE=`date +%Y%m%d`

####################################################################
## BACKUP PREVIOUS SUDOERS FILE AND REPLACE WITH NEW SUDOERS FILE ##
####################################################################

if [[ -f "/etc/sudoers.new" ]]; then 
   mkdir /var/root/sudoer-backup-$FILE_DATE
   mv /etc/sudoers /var/root/sudoer-backup-$FILE_DATE/sudoers
   cp /etc/sudoers.new /etc/sudoers
fi

[tlarkin]

I think ideally @rtrouton is on to the right path. Get on one of your OS X boxes, use visudo to edit the /etc/sudoers file, then back it up to a back up file, deploy it via package and move it in place after running the visudo -c command to verify the file is good.

Probably want to always keep a back up of the original as well, just in case.

Cheers,
Tom

[lashomb]

Good advice although visudo when in edit mode parses the file and won't save if there is an error (its running the check before the save)... If you exit out in the middle, you'll get a message about a .swp file and if you want to recover next time you try to use visudo. Not saying you can't screw things up with visudo, but there are checks there, and they've caught my errors from time to time.

The times I usually screw up the sudoers is when I try to replace it altogether. Sideloading it and doing the check is a good, safe approach.

For our environment, I add our developers to the _developer group which is also used by Xcode, and give that group permissions. I use a Cmnd Alias for all the paths. That way if I edit and screw up the Cmnd Alias, its less likely to hose the whole thing.