If your organization mandates that users run as standard users, one way of allowing them to install software and perform operations where admin privileges are necessary, is to let them grant themselves temporary privileges.
There are a few solutions out there already. With the introduction of macOS Catalina, Apple announced they were deprecating Python and moving from Bash to Zsh – meaning one should probably replace solutions that use Python and update those that have not been tested to work with Zsh.
Here is a simple Catalina compatible solution for Jamf Self Service, that does not pass admin credentials in the script (obfuscated or otherwise).
The Zsh scripts are based on code given to me at MacSysAdmin in Gothenburg last year by Zsh wizard Armin Briegel (much appreciated). I have added a timer to make it suitable if you need admin rights for more than 15 minutes, and written an Extension Attribute for Jamf, so that it only runs on clients that have activated it.
Setting up the Jamf Self Service policy
The setup consists of one Extension Attribute and two scripts – and their corresponding policies, detailed below.
- In Jamf, under Settings-Computer Management-Extension Attributes, add the TemporaryAdminRightsActivated Extension Attribute. Set these options: Data Type: String, Inventory Display: Extension Attributes and Input Type: Script. Copy the linked code above from GitHub into the text field.
- Create a Smart Computer Group called “Temporary Admin Rights Activated” where the Criteria is TemporaryAdminRightsActivated is Yes.
- Create a Self Service Policy called “Grant TempAdmin,” running the promoteUser.sh script (again, copy the linked code from GitHub). Execution Frequency should be Ongoing, and Make the policy Available in Self Service under the Self Service tab. Set the Self Service Display Name and button names as appropriate, these will be visible to the user. You should also add a Self Service notification that informs the user that rights have been granted, and for how long.
- Create a Policy called “Remove TempAdmin.” Use the linked demoteUser.sh script. Under Scope, add the Smart Computer Group you created in step 2. Set it to run on Recurring Check-in (which should be every 15 minutes, if not, change it). Execution Frequency should be Ongoing.
If your organization uses FileVault, uncomment the check for that in the demoteUser.sh script. Adjust the privilegeMinutes variable in the demoteUser.sh script to indicate how many minutes you want the user to have temporary admin rights for. 15 minutes should be sufficient for simple installations, 45 minutes or more might be needed for larger installations or tinkering. For developers and sysadmins, consider letting them run as admins all the time, or use the Privileges.app, which would let them toggle.
SoundSnw 
Hi,
Many thanks for this! After a couple tests I’ve found out the ‘promote/demote user’ script only works for local accounts. However, in my company we work with Active Directory accounts (‘mobile accounts’) and when I execute the script it returns ‘object not found’
In order to get it to work for AD accounts I’ve replaced the line below:
currentUser=$(scutil <<< "show State:/Users/ConsoleUser" | awk '/Name
&& ! /loginwindow/ { print $3 }')
with
currentUser=$(users)
This will grab the current logged on user and now the scripts works fine for the mobile accounts.
Hope this little modification will help others out too.
Kind regards,
Eric
LikeLike
I had been working to implement https://github.com/jamf/MakeMeAnAdmin in our environment, but even though it worked without issues during testing it seems to continually not work in production. Admin rights will get granted, but they won’t get revoked.
I like that your workflow is more Jamf-based, meaning I can see the logs of everything running in Jamf (as opposed to MakeMeAnAdmin, in which the process to revoke admin rights is triggered by a LaunchDaemon on the computer, so we just have to trust that it’s working without having an easy way to check it). The downside I see to your workflow is if a user grants themselves access and then kills internet connection, their admin access won’t be revoked. I guess there isn’t really any incentive for a user to do that, since they could always just grant themselves admin rights again by clicking the Self Service Policy when their admin rights expire. Can you think of anything to account for that, though? I wondered if there was a way to use the “Make Available Offline” option for the Policy to revoke admin access, but I haven’t used that option at all in the past and wasn’t sure if it would work with a Policy that should only be scoped to the computer if it was in the specific Smart Group (I don’t need it to run every 15 minutes if the computer doesn’t have temporary admin access).
Another minor downside over MakeMeAnAdmin is that we can’t set an exact time for the user to have admin access since access will be revoked based on the computer’s Jamf checkin. So a user could potentially have admin rights for as few as 15 minutes (if their computer happens to check in with Jamf exactly 15 minutes after the timestamp file was created) or for a many as 34:59 minutes (if the computer happens to check in with Jamf 14:59 after the timestamp file was created, then doesn’t check in for another 20 minutes). But I understand that short of having a local LaunchDaemon handle the process or setting the recurring checkin to more frequent than 15 minutes (which I’m not going to do), we just have to sort of live with that. I think it’s definitely something I would prefer over not having the logging features.
LikeLike