Managing temporary local admin rights for standard macOS users in HexnodeSolved

You can manage this in a few ways, depending on whether you need a one-time demotion, temporary elevation, or approved app installation for standard users.

For removing local admin rights, the supported approach is to run a shell script from Hexnode that removes the required local user account from the macOS admin group. This can be deployed to managed Macs through Hexnode as a script action or policy-based script workflow.

For temporary admin access, Hexnode provides a portal-based option to change a local user’s role. While changing the role, enable the temporary role option and set an expiry time. After the configured duration, Hexnode reverts the user back to a standard account.

If you want to reduce the need for admin rights, publish approved apps through the Hexnode Self-Service Portal. Standard users can install the approved apps made available to them without requiring local admin credentials. You can also restrict App Store installations to admin users from macOS restrictions so users cannot install unmanaged apps directly.

The temporary role option sounds close to what we need. Can that be triggered through the Hexnode API? Our ideal flow is: user creates a request in an internal ticketing tool, security approves it, and then the user gets temporary admin rights automatically.

Hexnode does not currently expose a native API endpoint to trigger the portal’s macOS “Change User Role” action. So the built-in temporary role change cannot be initiated directly through an external ticketing or approval system using an API call. For now, the native temporary elevation workflow has to be performed from the Hexnode portal. If you need more automation, the practical alternative is to use a controlled scripting workflow that grants admin rights and then removes them after a defined period, such as by using a local scheduled demotion mechanism on the Mac. This should be tested carefully before deploying broadly, especially to ensure the account is reliably reverted to standard privileges.

That clarifies it. We will use scripts to demote existing local admins, use the portal option for temporary elevation where needed, and rely on Self-Service for approved app installs. The missing part is API-triggered temporary elevation, which is not currently available.