Help with a script

[bbot]

I have a script that I'm running that installs new certificates into keychain. The only issue I'm running into is that it prompts the user for local admin credentials when we remove the old configuration profile and when it adds the new configuration profile to save the certificate into the keychain.

The script has to run as the local user so that it downloads the certificates as the user. Anyone know of a way to do this? Thanks!

find current user logged in

currentuser=stat -f "%Su" /dev/console

profile1=su "$currentuser" -c "/usr/bin/profiles -Lv | grep LC-802-1x-User"
profile2=echo $profile1 | awk '{print $4}'
echo $profilename

if [[ $profile2 == "LC-802-1x-User" ]]; then

su "$currentuser" -c "/usr/bin/profiles -R -p 04D1878B-BD77-4593-BAA4-4EB5AAE99304"

else

echo profile not found

fi

run profiles command as current logged in user

su "$currentuser" -c "/usr/bin/profiles -I -F /Library/LC/LC-802-1x-User.mobileconfig"

[bpavlov]

Have you considered just deploying the certificate using a configuration profile at the user level (or computer level if necessary)?

[bbot]

@bpavlov Yes, that's another issue I'm running into where updating the certificate in the configuration profile errors. Our certs are expiring in 2 weeks and we need to get this deployed to all 500 of our Macs. I have a webex with JAMF support to troubleshoot that.

I still want this script to work because we occasionally see certificates disappearing when keychains get corrupted (usually after password changes). I want to give the option of having users go into self-service and run this script to re-enroll their wifi.

[alexjdale]

We configure wifi at the system level, so it works all the time no matter who is or isn't logged in. I suggest that if it's an option. You don't need permission to use the System keychain.

[bbot]

@alexjdale That would make my life much easier as well, but our security team wants our wifi access to be at a user level.

[NickKoval · Accepted solution]

According to the man pages, profiles can only be run at the current user lever or at the root (read: computer) level. Trying to install a profile at the user level when you aren't that user isn't possible from the command line given those constraints.

What version of the JSS are you running? If it's new enough, you can create the profile in your JSS web interface that includes your certificates in the profile's payload. Then configure the distribution method to be "Make available in Self Service" & scope it accordingly. At that point, the end users can install it themselves - more importantly, as themselves.

[ndelgrande]

Like nkoval said, you can install certificates at the user level using a Config Profile. I am working on a similar project right now but also with unique certificates. You don't need to script this at all. This can all be done with a Config Profile and it will deploy to those Macs much faster than running a script during check-in.

[bentoms]

Yep... use the profile, errr @bbot

[bbot]

Thank you guys so much! This just made my life easier. We'll likely have to have all our users go into self-service and add the new configuration profile to reconnect to WiFi.

I have a case open with JAMF and they said there's an bug in casper with pushing out updated configuration profiles.

[dfarnworth]

Realise this is solved, but FYI for future, I believe that this line:

su "$currentuser" -c "/usr/bin/profiles -R -p 04D1878B-BD77-4593-BAA4-4EB5AAE99304"

should in fact read:

sudo -u "$currentuser" "/usr/bin/profiles -R -p 04D1878B-BD77-4593-BAA4-4EB5AAE99304"

[bbot]

Thanks @danf_b . Can you tell me how they differ?

[NickKoval]

The su command requires the target's user credentials - unless it is being run as root.
The sudo command uses the invoker's user credentials.

Because the jamf binary is executing as an admin user you can easily execute the sudo command because the invoker's password (the casper admin account password) is known. If you try to execute this command with su, you would need to know the password for the account identified by the $currentuser variable - something which most admins don't have.

[dfarnworth]

Thanks @nkoval, I've been out on hols.

I didn't even think that su could be used as above, however, apparently it can according to the man page. It seems though that if you have a real UID of 0 it will not ask for the password.

 su man -c catman
            Runs the command catman as user man.  You will be asked for man's password unless your real UID is 0.

All that said I know that the sudo -u method works and has done consistently for me.

[brock_walters]

Hello all -

I believe this has been cleared up but I just wanted to offer some other examples of using sudo to perform a command as a specific user:

sudo -u $USER *command.here*

sudo -u "#501" *command.here*

the 1st uses the global variable for the currently logged in user, the 2nd uses the UID of the 1st user created by OS X during the setup assistant. Any UID could be used but this is just an example of the syntax. sudo is probably better than su in this case for the reasons mentioned above. Good luck!