Removing Local Admin Privileges

@msg|gsm A word of warning - If you use Cisco Webex Meetings in your environment be aware that the current self-update process will delete the contents of the Cisco Webex Meetings.app package rather than installing an update if the user isn't an Admin.

As for users running as non-Admin, if you have the option SAP's Privileges.app is probably the least painful way to go.

Get ready to manage a lot of things that you may currently let the users deal with. Like Printers!

that being said here is my script:

#!/bin/sh

## this will demote the current user if it is not YOURLOCALADMINUSERNAMEHERE
currentUser=$(ls -l /dev/console | awk '{ print $3 }')
echo "current user is $currentUser"

if [ $currentUser != "YOURLOCALADMINNAMEHERE" ] ; then
IsUserAdmin=$(id -G $currentUser| grep 80)
    if [ -n "$IsUserAdmin" ]; then
      /usr/sbin/dseditgroup -o edit -n /Local/Default -d $currentUser -t "user" "admin"
      exit 0
    else
        echo "$currentUser is not a local admin"
    fi
fi

Printers? i have mine packaged and users can add them as needed, including drivers. Our issue was with adding fonts, marketing goes nuts when they cant add 3000 founts in a minute....so we just used the Makemeanadmin app posted on github here: https://github.com/jamf/MakeMeAnAdmin. I took the time down a bit, but no complaints from anyone.

We are doing the same with admin rights. You can modify the authorization db for certain functions:

#!/bin/bash
# Give users permissions access to "Print & Scan, Network, Time" Preference Pane

/usr/bin/security authorizationdb write system.preferences allow > /dev/null 2>&1
/usr/bin/security authorizationdb write system.preferences.datetime allow > /dev/null 2>&1
/usr/bin/security authorizationdb write system.preferences.network allow > /dev/null 2>&1
/usr/bin/security authorizationdb write system.services.systemconfiguration.network allow > /dev/null 2>&1
/usr/bin/security authorizationdb write system.preferences.printing allow > /dev/null 2>&1
/usr/bin/security authorizationdb write system.print.operator allow > /dev/null 2>&1
/usr/sbin/dseditgroup -o edit -n /Local/Default -a everyone -t group lpadmin > /dev/null 2>&1
/usr/sbin/dseditgroup -o edit -n /Local/Default -a everyone -t group _lpadmin > /dev/null 2>&1
/usr/sbin/dseditgroup -o edit -n /Local/Default -a 'Domain Users' -t group lpadmin > /dev/null 2>&1

exit 0

The "Make me admin" scripts work better for us than Privileges, since it simply nags you, doesn't force the downgrade.

No real pain points for us at all. For our "heavy" users like developers, we modify the "make me admin" script to basically give them admin all day long. Sort of defeats the purpose, sure, but we can look security in the eye and tell them that it gets downgraded at COB every day.

@strayer Hey Mate, I used your script to run a test to make sure it would work. For some reason randomly users are reported as admin, there seems to be no consistency to it. I even remoted to one of the devices and found that the users account was not an admin and when running "id -G username" locally the group 80 was not reported. Why is the script not working as intended? Is it possibly because the is an "80" in the string? If so how can I amend this?

#!/bin/sh

## this will demote the current user if it is not YOURLOCALADMINUSERNAMEHERE
currentUser=$(ls -l /dev/console | awk '{ print $3 }')
echo "current user is $currentUser"

if [[ $currentUser != "administrator" ]] && [[ $currentUser != "*******" ]] && [[ $currentUser != "****" ]] && [[ $currentUser != "*****" ]] && [[ $currentUser != "****" ]] ; then
IsUserAdmin=$(id -G $currentUser| grep 80)
    if [ -n "$IsUserAdmin" ]; then
#      /usr/sbin/dseditgroup -o edit -n /Local/Default -d $currentUser -t "user" "admin"
        echo "REMOVE ADMIN TRIGGERED FOR $currentUser"
                echo $(id -G $currentUser)
      exit 0
    else
        echo "$currentUser is not a local admin"
    fi
fi

@djrory Change the grep pattern to '80' to prevent substring matching.

Old thread but FWIW Apple did mention they recommended running as local admin this past WWDC in the zero touch session, and again in another session I cannot recall. If you use FV2, only admins that have crypto tokens can add/modify crypto users to unlock the disk. IT deploying a standard local account is a horrible idea for a plethora of reasons.

Unless you work in a high security env or maybe EDU, 95% of Orgs can let their users be local admin in my opinion.

I'll agree with @tlarkin that having a standard local admin account is a bad idea these days. It's a "one ring to rule them all" type issue that comes up way too often.

In a previous job, everyone (including those of us in IT) was a standard user on their machines for security reasons but we had a standard admin account (though over the years, the password drifted between admins), so if you needed to do something with admin rights, you contact IT and someone went to you and entered the user/password. It was BAD! Once I got there, I brought in Jamf and we used the "Make me an admin" workflow presented at JNUC by @Andrina and logged all uses.

After a while we realized the only legitimate uses were for printer stuff, so we found a process like @jconte mentions (though mine was not as thorough or elegant) to give printer rights to standard users and our tickets went down.

But these days I tend to leave users as admins unless I have cause (or legal reasons) not to. The issues of not having admin rights on your machine have thus far severely outweighed the risks of having it.

Hope this provides some hard-earned (for lack of a better word) "wisdom" to help. As a friend of mine likes to say: Good judgement comes from experience. And experience comes from bad judgement.

Good luck!

@chadlawson Chad I work in an environment that is hyper-conscious of security, so clearly fall into that high security env/use case that @tlarkin referred to. I am curious, based on your experience, how do you mitigate the risk that anyone with local admin access on a Mac has the ability to circumvent most if not all security measures implemented on the device by JAMF/MDM layer, be they config profiles, or policy controlled (policies -> a local admin can remove JAMF binary -> JAMF policies cease functioning) ? Users with Local Admin also have the ability to export certs which may be used for identification/validation that device is compliant/secure. For a user with malicious intent, this then enables them the ability to spoof a legitimate/security "compliant" device that has all these measures in place, and allow that uncontrolled/unmanaged device access to a production network. I totally appreciate the challenges applying standard user accounts creates, and personally if there was a choice, given that hassle/massive overheard of implementing standard user level, versus a real (perceived?) security risk of allowing local admin, I would support local admin. Unfortunately we are bound by security requirements, especially in todays heightened security focused climate, so welcome your feedback on how you balance security versus risk, given the exposures I have highlighted above. thanks..

@RJH, I don't know if I can give you a clear answer, but I can put my experience into a little additional context which may help. We were a manufacturing company and the leaders (at the time) in the industry. Combine that with the company president being former NSA and former Army Signal Intelligence (non-morse, he always pointed out) and we had a lot of rules regarding information security.

For example, we were not allowed to throw away receipts from the local grocery story or restaurants into the trash. We had to put them in a shred bin or burn bag. Nothing with printing was allowed to get thrown out where a dumpster diver could start gathering information and targeting an employee for intel.

So trust of the outside was low, but trust of personnel was a "trust but verify" kind of thing. We monitored the network but didn't do blocking aside from the basics. We took the approach that if we handled security as a technology thing only, it would always be an arms race and made it harder to detect. Instead we did the basics (non-admin accounts, etc.) and the rest was handled at a (near) zero-tolerance policy level. Nearly any violation of acceptable usage was grounds for termination.

Yes, an admin can remove the Jamf framework. And yes, I can make a launch daemon that will watch for it and put it back. And yes, an informed admin could find it and remove it. And so on and so forth. But if a user "accidentally" deletes the MDM profile, they can't get into certain company resources and re-enrollment has a monetary cost and a signed paper on file, so no one did it.

As you are clearly well aware, it's a balancing act between security and usability. I'd rather make sure my people can get their work done than assume they are trying to screw us. When I used to wear my tin foil hat as it were (though for two days it was literal based on an inside joke) I spent more time herding cats than I did moving the company forward.

That's just my $0.02, and there are reasons I don't do that work anymore. So I don't envy you the tasks ahead, but I hope the discussion on "why" helps as much as the discussion of "how." And I hope others on this thread give you good stuff as well.

I look forward to hearing what approaches you take. If I can help, I'll be happy to.