Removal of Admin Rights

[Stephen_marquar]

I'm curious to know if anyone has removed admin rights from their users. I'm talking about demoting admins to standard accounts. What have you done from a management perspective following that? Are you using some sort of Privileged Access Management solution such as CyberArk or BeyondTrust? I'm also curious if anyone out there has removed admin rights from a company with a high number of engineers. I'm familiar with scripting the account demotions, but I'm curious to see how everyone is managing privilege after that.

[danlaw777]

We have, and its a pain. So far our engineers aren't using mac's but our marketing and graphics department are almost all mac's now. The apps and software updating is difficult enough, but when our marketing groups goes in with a new vendor, we almost always have to install new fonts, 20 of them or so. Right now we don't have a work around, tho we are exploring our options. I'm a VERY new mac admin, and have ZERO experience in scripting, but we'll see for how long.....

[dash4385]

We moved all Non-engineers to standard accounts and have a self-service policy that allows temp admin access for 5 minutes and we log how often it is used.

[danlaw777]

@dash4385 how did you do that?

[RobertHammen]

I'd suggest taking a look at SAP Privileges. You can also set it up to auto-demote users, as documented here: Travelling Tech Guy

[JeanRod]

Hey Robert, By any chance do you know if this affects how the Mac OS is updated? will users need to use admin access to update their own machines? or can you still push updates through jamf without them having admin access?

[T_Armstrong]

Also, take a look at Jamf's own "5 minute" script.
https://github.com/jamf/MakeMeAnAdmin

Personally, I like the SAP approach better, but the Jamf script is a whole lot easier to implement.

[Madmax85]

As mentioned above, we now use the SAP Privileges.app in our environment. We used the MakeMeAnAdmin script in Self Service before that but if people were offline they couldn't escalate their privileges which is why we went with Privleges.app instead. It seems to work well for our needs.

[sirsir]

We've used this script in the past without issue.

#!/bin/bash

localAccts=$(dscl . list /Users UniqueID | awk '$2>500{print $1}' | grep -v yourlocaladminaccounthere)

while read account; do
    echo "Making sure $account is not in the local admin group"
    dseditgroup -o edit -d $account admin
done < <(echo "$localAccts")

exit

[danlaw777]

i deployed the "MakeMeAnAdmin" and have had excellent success in just a few days. thank you @T.Armstrong

[Stephen_marquar]

I'm curious how you manage these suggestions with development engineers. I would imagine that development applications, builds, etc would require admin privilege almost all the time. Certain engineers may need access to certain areas of the preferences pane to make small changes depending on what they are doing. I would anticipate a very high demand for temp admin access. Likely more requests than our support staff could handle.

[JoshRouthier]

Looking into this for an upcoming project, and one of my main sticking points will be how to track who and how often a user is promoting themselves to an admin. Has anyone been able to implement a temp-admin solution with reporting that can be referred to at later points in time? Thank you @RobertHammen for the SAP Privileges suggestion, and @T.Armstrong for the "MakeMeAnAdmin" suggestion.

[ckelley]

Did you ever find a good solution to this?

[Stephen_marquar]

I've considered the option of allow the the user to be an admin for a certain amount of time. My question is, how do I implement that effectively? I could put a "challenge/response" around it, but we would have users flooding support with calls for it. If we put it in Self-Service we would just have users elevating themselves all day. If we set it to allow it just once a day for a certain amount of time, how do we determine how long as certain users may have different needs. If a user is going a dev build that day they may need it for several hours.

[pete_c]

At my previous Jamf instance I had developers who also were typically very expectant that they'd be able to have full access to their machines ("root"). I explained to them that they still had it, just they had to use the same mechanism as everyone else, a Self Service policy to temporarily promote to admin - as a corporate standard and as a security measure.

I gave my non-dev users a 5 minute version, and the devs all got an hour. I never had anyone tell me that wasn't long enough, and when I reviewed the usage logs I found that a new dev would typically spend their first day elevating their rights once or twice and then virtually never again in the first month - they set up their environments the way they wanted, got their preferred IDE and editor and monospace font etc.

While Privledges.app is great and definitely more well rounded than running a script from Self Service, directing users to Self Service helps reinforce that it should always be 'the first stop' anytime there's a question or concern - reinforcing the very concepts of self-reliance and DIY on your own schedule.

[wmehilos]

@pete_c Either that or they're elevating, opening a terminal and running "sudo zsh" and leaving the window open all day.

[Zackn9ne]

Simply push Privledges.app

Leverage the following script. You have to grab current user with the python current user trick.

#!/bin/sh

loggedInUser=$(/usr/bin/python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");')

sudo -u $loggedInUser /Applications/Privileges.app/Contents/Resources/PrivilegesCLI --remove

[sax_man424]

Does Privileges log when permissions are escalated and if so are the logs stored locally on the device?