What are your trying to accomplish with this type of workflow?

Preventing users from elevating to admin unless given permission. In a scenario, where multiple people need to be given admin permission can provide that code to whoever needs it, then change the code. I’m aware this isn’t perfect solution, but I find it to make more sense than just allowing them to do it without some form of protection. Maybe there is another workflow than can gatekeep this function use more than times per month it’s used?

If your end users are going to have to reach out to someone like a help desk technician and explain their need, wouldn’t it make more sense to just have the technician do the work for them? End users can still do anything while their privileges are elevated. A code isn’t going to guarantee they do what they say they’ll do.

I’m aware it isn’t a perfect solution. Right now, there isn’t a perfect solution. I am looking for something better than what is in place. If you aren’t interested in discussing actual solutions to my request, I appreciate the feedback you provided, but I’d like to actually consider how this could work.

As I said in my response earlier:

I’m aware this isn’t perfect solution, but I find it to make more sense than just allowing them to do it without some form of protection.

Here are some of the benefits, even with the flaws as you stated that I am already aware of.

While I know they still will be able to do things with full privileges, we would have knowledge of when someone is elevating while they are doing - rather than reviewing logs to find out they elevated later.

We could pre-emptively create a verification code and provide it to someone on the spot, rather than needing to wait for IT support to remote to manage the action. In our environment, providing a verification token would be faster than waiting or scheduling a remote session.

In addition, if needed we could loop in automation to send the request through management for an  approval based on the request. The dream could be to use that automation to randomly generate it’s own code and push the parameter for the policy/code through API. This could potentially scope the policy to the user. That feels pretty far out the scope that’s currently available, but I think a clunky version could be created.

I could see several reasons why a solution like this could be beneficial. Sure, it’s not the perfect solution, but it might work for some environments better than what they are currently using.

I’ve created something similar except instead of using a code based system, I have the policy to run once per computer. Therefore, when a user needs temporary admin rights, they contact IT, and then either add the computer to the policy or we flush the computer from the policy so they can run it again. This will allow IT to generate an easy ticket which keeps track of each time a user requests admin rights.

Once a computer is added to the policy, the button is added within Self Service. Once pressed, a window appears telling the user that they will be given admin rights for 10 minutes (timer and messaging can easily be changed). They are then given admin rights to do whatever it is they need. However, the one thing it prevents a user from doing is creating another local user with admin rights. If a user attempts this, it will revoke admin rights from the actual user and immediately delete the account that was created. Other than that, they are free to do what they need within the 10 minutes. A message will appear when they have 1 minute left and then a final message once the timer is up. At which point, their admin rights are revoked.

It’s a simple and straightforward way for this without using Jamf Connect.

Hi Justin,

Thanks for the idea. That does pretty much check all the boxes. How were you able to prevent a user from creating another local user?

Hi,

Within the script, there is a section that monitors for new admin users and deletes them if one is detected. It does this by checking the local users list when the script first runs and if a change is made, it flags it. In doing so, it deletes the new admin account and revokes the access of the current user that did it. It then throws up a message letting them know that an unauthorized admin was detected and that their admin access has been revoked. It’s almost an immediate detection as well which is nice.

In theory what you are wanting would be possible. You would need a webserver with API functionality for your script to call, the web server would issue a response of yes or no based on the token provided and Jamf's script would respond accordingly. You would then need to figure out how to create a new record on this webserver for each Mac, and how to rotate those tokens. In essence you would be building a very poor permissions management tool that is giving you no real permissions management. Keep in mind, giving admin access for any period of time is still giving admin access.

You need to look in to a EPM tool, off the top of my head CyberArk and BeyondTrust each make decent tools in this space.

Thanks for the idea. That does pretty much check all the boxes. How were you able to prevent a user from creating another local user?

You dont. As I said above, once you give a user admin access they can do anything with it while they have it.

https://github.com/Sdelsaz/PIN-for-Admin

I’ve used this script with several of my customers before, and it worked quite successfully. It would be nice if Jamf Connect also offered a similar optional EA that provides a PIN option. This might not be the most appropriate request, but having it as an option wouldn’t be a bad idea.

Awesome. Thank you all for the thoughtful responses!