Differences of running script from Self Service vs being pushed

[bbot]

When running a script for 802.1x wifi configuration through Self Service, the following works perfectly. If I push it from a policy, the certificate doesn't get assigned to the com.apple.network.eap.user.identity.wlan.ssid identity in keychain.

Is there a difference in how the JSS distributes the script through self service vs pushing via policy?

If I run it through "sudo jamf policy" as the logged in user, it'll also work. Just seems to be when the policy kicks off on its' own is when it's not working.

#!/bin/sh
    security set-identity-preference -n -s "com.apple.network.eap.user.identity.wlan.ssid.LC-SSID"
    security set-identity-preference -c "$Cert" -s "com.apple.network.eap.user.identity.wlan.ssid.LC-SSID" /Users/$currUser/Library/Keychains/login.keychain /Library/Keychains/System.keychain

[Look]

I think both Self Service and sudo jamf are effectively initiated by a user, because the change you are making is a user security change when it runs by itself in the background the system prevents it happening.
Have you tried running it as a login item as well? or just recurring? I think login items have similar user details as Self Service and it might work, otherwise I think you need to have it make the call as the user you want to modify.

[bbot]

I've only tried as recurring. A majority of our user's do not reboot often and this needs to get pushed on the backend.
I'm looking into trying to run the command as the current logged in user, but haven't had much luck yet.

[mikeh]

Personally, I wouldn't have thought there would be any difference - the script should fail either way, because the jamf binary executes the script as root, not as the currently-logged in user. Apparently that's not the case here.

At any rate, it's been my experience that scripts executed from a policy are run by root. I think what you want to do is, determine against which user account the script should execute, and then use sudo -u $username security set-identity-preference [options]. You could use the $3 parameter, as well, but be prepared with a backup plan just in case $3 is not populated.

[Look]

I wouldn't have thought so either, except I have actually seen similar behaviour in other scenarios as well, I can only assuem that although the function is run as root it is still tied back to the user manually initiating the process (or a launchagent in the case of login policies), where as recurring policies are presumably coming of a launchdaemon instead at the system level. It reall only seems to relate to security things most of the time, I think I was playing with Kerberos tickets when I saw it.

[mm2270]

@Look Your assumption is pretty much how I understand it. The recurring trigger, when it runs naturally and not forced from Terminal, is called by the Jamf LaunchDaemon, which means its running entirely in a root context.
By contrast when you call the recurring trigger manually from Terminal or you run a policy from Self Service, the jamf binary has some understanding of the user context. I believe that's why it kind of works in those cases to affect things in user land, but when called by the LaunchDaemon it doesn't work.

Unfortunately in my experience it's not entirely consistent. I've seen cases where its not able to affect things in the user space, even when run from Self Service. For that reason I always design any scripts that I know may be used in a policy of any kind to either run items as the logged in user, or capture the username and direct commands at files in the user's home, at least when it calls for that.

[bbot]

Thanks guys. I'll have to play around with my terminal using root and see if I can modify my user login keychain. Been messing with commands like the below all night to no avail. I know what needs to be done, just not sure how to achieve it here.

su "$currUser" -c "security set-identity-preference -c $Cert -s com.apple.network.eap.user.identity.wlan.ssid.LCAAAA /Library/Keychains/System.keychain" su "$currUser" -c "security get-identity-preference -s com.apple.network.eap.user.identity.wlan.ssid.LC-AAAAAAA"

[lachlan_suncorp]

...

[loceee · Accepted solution]

on sierra this might get you there, take note of the the differences in launchctl syntax between macsOS version.

username=$(logname)
launchctl asuser ${username} security ...

As usual, @derflounder has blogged about it :)

https://derflounder.wordpress.com/2016/03/25/running-processes-in-os-x-as-the-logged-in-user-from-ou...

[loceee]

However security bin might behave a bit differently from memory, I remember fussing with this problem a bit too when attempting to set some identity preferences. Can't find my code though.