Ultimate Admin Script

[Egisto Chancellor]

Iam looking to see if there is anything like the Make Me an Admin script that will work in macOS Ventura. The current script does not work in Ventura. I don't get any report of errors just doesn't make the account an admin account.

@sara_mccullar I don't have a recommendation to replace Make Me an Admin, but PrivilegesDemoter is a companion tool for Privileges you might want to check out. It is intended to prevent/discourage users from retaining admin rights longer than necessary.

If your goal is to automate the updates of macOS computers with standard user accounts in your fleet to Ventura (or from macOS 13.0 - 13.2) by making them admins for 30min then there are better ways to do this IMO.

We have some users who need admin rights periodically for the work they are doing. It's not for software updates. We want to be able to get all our users to have a standard account. Those that need to be able to be admin accounts can have that access through a self service option or app.

I am using version 30.1, and it looks like we no longer need to pass --current-user as the script is able to pick up that a user is logged in. I am also safely assuming this since in the Wiki there is no reference to using --current-user. Looks like 30.2 was just released so I might test with that.

I am actually using the exact same workflow in your video (Nudge + Erase-install). I have had little to no luck though getting standard users to update their devices via self-service policy using erase-install, and having Nudge point to that execution policy.

In testing, I have had to resort to giving the user temporary admin access. A good portion of our users are on Monterey, but some users are on Ventura, and they have needed temp admin access to update with erase-install. I have been testing on Silicon macbookpros with users but every single test with a silicon macbook pro times out after the standard user is prompted for a password by erase-install. Intel devices with admin users update just fine.

I have been resorting to the makemeadmin script for elevating permissions which seems to be working for Ventura. I just don't want users to be prompted that they will receive admin so I might edit the script. My only issue now is that I don't want to remove admin from users who already have admin on their local machine (engineers mostly)

The issue looked very similar to another issue on the github page here: -install/issues/412 but in my case the volume owner's password just doesn't work at all when erase-install prompts the user for their password. The user is in fact a volume owner, standard user but it just won't go through with the update and it times out after 60 minutes.

The other issue with the script is that it logs the standard user's account password to the scrip log. So I will stop using it for security reasons soon. For a middle school student though its not a deal breaker.

So here is the thing with Privileges, yes it allows the user to become an admin. I can only get the time limit to set if I use the toggle feature when you right click on the dock icon. Now most of our users are not going to do that. They will just click the dock icon and hit request privileges. I do believe that after maybe 48 hours (honestly wasn't keeping track for that long period) it did revert the user account back to a standard account.

Now I know there is the Privileges Demoter. All that does is give a pop up reminder to extend or remove the admin privilege. We have had people who could ignore the old nudge (pre big sur) and never run the updates.. Those people are most likely not going to be ones needing admin rights, but I want something that will take away those rights in 30 minutes.

Looking at Privileges, it does seem to come with a CLI, where you can run commands as a standard user to add or remove elevation. I think in theory you could create a LaunchAgent that runs every 30 minutes that will run the CLI option to remove the admin rights (scroll down to "How do I use Privileges.app in a script or from the command line?") :

Many thanks @pkleiber. I had already seen these posts. Problem with Demotor is that it 'requests' if you want to remove the rights. I don't want to give the users that option, I just want to remove them :)

I've created a LaunchDaemon which on the face of it appears to work. I've had to use a LaunchDaemon over an agent for a few reasons, but mainly so that I can run the script as root to obtain the following:

I've not tested this thoroughly, but it appears to work. For my own settings, I've set the Daemon to run every 3 minutes, so it has the potential to go over the 15 minutes which we want to adhere to, but that's not a big issue. The Daemon runs the script below. Obviously, Privileges needs to already be installed:

The main issues I had with the script above is that I didn't want to remove admin permissions from any IT support accounts (we have multiple different schools, each with their own admin accounts), so I had to come up with a method that didn't revoke permissions from these accounts.

Secondly, I noticed an issue with the script I posted above in that if a user elevated their permissions and then logged out, and then a different user logged in and elevated their permissions, then the first user would be left with permanent admin permissions, as the script only revoked permissions for the last user to elevate using Privileges. I got around this by only applying the 15 minute timer to the last user, and just removing permissions immediately for the previous user. In our case, this is specifically for staff devices, so it's unlikely that more than 2 users would login to the same device within 15 minutes, but if this is the case then the script above could be modified to include more than the last 2 users to elevate their permissions.

Just wanted to reply to this topic. It now looks like PrivilegesDemoter will revoke admin permissions silently in the background after a specified period of time, regardless of how the permissions were elevated (either by right clicking on the Privileges dock icon or running the app). Settings can also be configured in a Configuration Profile.

Jamf's purpose is to simplify work by helping organizations manage and secure an Apple experience that end users love and organizations trust. Jamf is the only company in the world that provides a complete management and security solution for an Apple-first environment that is enterprise secure, consumer simple and protects personal privacy. Learn about Jamf.

This site contains User Content submitted by Jamf Nation community members. Jamf does not review User Content submitted by members or other third parties before it is posted. All content on Jamf Nation is for informational purposes only. Information and posts may be out of date when you view them. Jamf is not responsible for, nor assumes any liability for any User Content or other third-party content appearing on Jamf Nation.

We have been having huge issues with the standard account; cannot update software(Chrome), cannot add personal network printers, cannot add WiFi, etc. So it was the consensus to promote the standard account to an Admin account. I am hoping there is an script to perform this very act, because updating 900+ devices is a little daunting.

I see there is a script to demote and we have it in the wings for deployment should this entire Admin rights thing go South. I am no scripter, but know enough to follow through what will happen when things are run. So any and all help is appreciated.

-o: specify the operation. In this case, it is edit.

-a: add a user or group to the target group. In this case, it will be the currently logged in user.

-t: specify the type of resource that you are adding to the group. In this case, you are telling the command that the currently logged in user is a user, not a group.

We use no AD and have all Macs. We do not want to grant temp Admin Rights though, we figure it that these clients are old enough to take care of this stuff themselves. AS far as the argument goes about the management portion, this may change next year after we get a hang of this JSS program, its huge and I am new to it.

The standard accounts are all named differently.

is this where an 'if' statement would come in? I am no scripter, but I can basically follow through the script to see what it is supposed to do. I would think it would need to find the current user logged in and then change their group from standard to admin.... but how to get from point a to point b is way beyond me.

but when run on the standard account it fails with the attached error. I do not think it is using the admin account to install the script. I have had the user reboot the device, relload Self Service and still nothing works and still get the error.

@rhooper Making everyone admin is generally considered the opposite direction organizations should go. There are likely answers to each of the problems you're mentioning. If you're intent on giving admin access though, you might consider watching this video that provides a nice solution for giving admin privileges on an as needed basis.

3a8082e126