Extension attribute script works locally but not via Jamf

michaelherrick
New Contributor III

Hi Everyone,

I'm working on an EA to check for the presence of a particular cert in the user's Login keychain.:

#!/bin/bash
currentUser=`stat -f '%Su' /dev/console`
echo "Current username is $currentUser"

fullName=$(dscl . read /Users/`whoami` RealName | grep -v RealName | cut -c 2-)
echo "Full Name is: $fullName"

firstName=$(echo $fullName | awk '{print $1;}')
echo "First Name is: $firstName"

CERTNAME=$firstName
echo "Cert Name is $CERTNAME"

if [[ `security find-certificate -c $CERTNAME /Users/$currentUser/Library/Keychains/login.keychain` ]]; then
   echo "<result>Installed</result>"
else
  echo "<result>Not Installed</result>"
fi
exit 0

Basically, the certificate we're looking for always has the user's first name. The script returns the proper result (Installed) when I run the script locally on my Mac, but always returns "Not Installed" when deployed as an EA. Has anyone else ran in to this behavior before? At first I thought it was the "currentUser" variable not setting correctly, but even when I plug in a defined user folder in the if statement , the EA returns "Not Installed"

-Mike

1 ACCEPTED SOLUTION

thoule
Valued Contributor II

Well, you've got 'whoami' in there, so that's going to return 'root' when run via jamf. Perhaps you meant to put currentUser in there?

I'd also recommend you use a full path when calling applications such as security ('/usr/bin/security')

View solution in original post

4 REPLIES 4

thoule
Valued Contributor II

Well, you've got 'whoami' in there, so that's going to return 'root' when run via jamf. Perhaps you meant to put currentUser in there?

I'd also recommend you use a full path when calling applications such as security ('/usr/bin/security')

NowAllTheTime
Contributor III

Does the script work if you run the script locally while logged in as a different user than the user who you are trying to inventory the certificate for? My thought is it will also fail in that scenario. I think the only reason it is succeeding in your local test is that your login keychain is already unlocked so you can read from it without any issues. To be able to search within another user's login keychain you need to unlock that keychain with their login keychain password. I'm assuming you don't (and should not) know the login keychain passwords of your users, so you cannot unlock their login keychains and search within them. It is my understanding that this is by design even with root privileges.

mjhersh
Contributor

There are dark forces at work with keychains. It's not enough to run it as a given user, and it's not enough to run it in the user's context. It takes multiple steps of contortions to go from the headless root environment of the Jamf client into proper userland where the security command will actually work.

This is how I solved a very similar problem, and I suspect it will work for you as well:

currentUser=`python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");'`

uid=`id -u $currentUser`

launchctl asuser $uid su $currentUser -c "/usr/bin/security find-certificate -c $CERTNAME /Users/$currentUser/Library/Keychains/login.keychain"

Tested in Sierra and High Sierra.

bwiessner
Contributor II

@michaelherrick I got this to work - hope it helps.

#!/bin/bash

consoleuser=$(ls -l /dev/console | cut -d " " -f4)

firstName=$(dscl . read /Users/$consoleuser RealName | grep -v RealName | cut -c 2- | awk '{ print $1 }')
echo $firstName

if [[ `security find-certificate -c $firstName /Users/$consoleuser/Library/Keychains/login.keychain` ]]; then
   echo "<result>Installed</result>"
else
  echo "<result>Not Installed</result>"
fi
exit 0