Triggering a Jamf Check-in without Sudo

[techgeek]

Hi folks,

I am doing a task of making an app to resolve an issue. This app will exist as a standalone on our Macs, for users who are not admins.

As part of one of the scripts I am using within the app, I will need to force/trigger the Mac to perform a check-in at a particular stage of a script. The script will be run by the current logged-in non-admin user.

Now, I know the obvious is to simply do a sudo jamf policy and I could always include an administrator username and password within a script of the app to make it run as that user instead. But I would prefer not to do that, as I don't feel comfortable in including the admin password within the script, plus it would cause issues every time we change the admin password.

What I am trying to work out is a way for a standard user to simply trigger to the root user to perform a check-in policy. Surely there must be a way to do this outside Self Service?

Anyone got any ideas?

At the moment, my mind is thinking of a complicated potential setup of where I have a continuous LaunchDaemon to trigger the sudo jamf policy whenever a file is touched in a particular location. Please tell me there is an easier way than this! :-)

Many thanks.

[jzeles]

Would it be possible to integrate your process into the Self Service app? Doing so would allow the end user to run actions that require admin rights. My other thought would be to embed credentials into what you are building, but thats generally not a great security practice.

[mm2270]

Just curious, but why the opposition to using Self Service for this? Its part of why Self Service exists. I didn't see any real explanation in your post on why you can't, or won't, go that route.

Outside of that, one other thing I can think of is what you mentioned toward the end. Installing a LaunchDaemon that would run a sudo jamf policy command when a file is touched that is in the WatchPaths. Other than this, I'm not sure there's any other good way to do it.

As far as embedding the credentials, its possible you could do it. Both Applescript apps and other tools (like Platypus) will let you create apps that obscure the script to make it very hard for anyone to be able to read it. With Applescripts, you save them as run only apps. This means no-one can drop the applet onto Applescript Editor and read the script contents, so the password would be relatively well protected.
With Platypus, you can hide and encrypt the script contents. The script doesn't even show up anywhere within the app bundle, unlike with Applescript apps. Its almost impossible to get at the script contents. Just wanted to put those out there as options.

[techgeek]

After a bit of debating on which manner we want to undertake this in our organisation... we have decided to just embedded the password securely within the app. It'll just have to be added to our list of apps to update when we change the admin password of this account.

Would be great if one day there is a way a standard account can simply give the root account a bump to run its jamf policy earlier than it is suppose to. One day I'm sure.

Thanks guys for your input.

[thoule]

I had to accomplish something similar. My solution was to create a launchD with a watched Folder. The watched folder was world readable/writable. In my case a script run by a non-admin user would drop a file with the name 'custom-trigger'. The script referenced below as /usr/local/company/tool/apprun.sh will run 'jamf policy -event custom-trigger' with admin rights.

mymac:LaunchDaemons thoule$ more edu.company.app.plist 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>edu.company.app</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/company/tool/apprun.sh</string>
</array>
<key>WatchPaths</key>
<array>
<string>/usr/local/company/tool/apprunWatchedFolder/</string>
</array>
<key>OnDemand</key>
<true/>
</dict>
</plist>

[oladoke_durotoy]

This sounds good, I was trying to follow the logic and then realised you still need an offline policy to check an trigger. I am not a big supporter of embedding passwords, especially admin credentials.

Thanks for sharing though.