Alternative workflow to LimitToUser in newer version

[mnordbye]

Hey everyone,

We had a great workflow in our post production environment using PrivilegesCLI through SSH to enable admin rights to a specific user (config profile with "LimitToUser"), without having to log in with that user.

But, since this no longer works in Privileges 2.x -> , and version 1.5.4 and CLI seems to stop working in MacOS Sequoia, we are looking for an alternative method.

Does anyone in the community have a workflow/solution for this?

• The goal is to be able to have a local user on each computer, which we can give administrator rights through SSH (or locally in the terminal), even when a different user is logged in.

[mthielemann]

What about sudo dseditgroup -o edit -a your_unprivileged_user -t user admin?

[mnordbye]

Hi @mthielemann ,

Thanks for the reply! :)

So you would just run this command through SSH, and the respective user would get the same rights as when using Privileges?

Have you implemented this with Privileges before, or made something as simple as PrivilegesCLI, as to avoid writing that whole command each time?

[mthielemann]

Yes, this command adds a user to the admin group, which is what Privileges does. Even though Privileges has a lot more features, the basic functionality is to add and remove users from the admin group. So if you don't need all of these features and management capabilities, you can just do it on the command line with dseditgroup.

[mnordbye]

Thanks, we'll try that.

Out of theory though, doesn't running this command require admin rights to run? So we would need a different administrator user to make the first one admin using dseditgroup?

This is the great thing about PrivilegesCLI, which can be run without being admin. So our local localadmin user could make itself admin while being a standard user.
A note here is that this is for a corporate environment, where continuous local admin users aren't, but Privileges and similar workflows are approved.

[mthielemann]

So you have a localadmin without admin rights? Then you can't use dseditgroup because it requires admin rights to add a user to a group. In Privileges 2 we wanted to make sure that users have full control over their admin rights and that no one can change their admin rights in the background (via SSH), so I am afraid Privileges is no longer an option for you. On the other hand, you might consider changing your workflow…

[mnordbye]

I see, then this won't work for our special case anymore. Too bad, 1.5.4 made our lives as sys-admins so easy. :D

Thanks for all the help! Privileges 2 is still our go-to solution for personal laptops etc. Works great!