Skip to main content

As we all know Jamf introduced us new LAPS solution. I have created EA to read local admin password. 

In order using actively LAPS auto deploy must be enabled. You can read this jamf article for how to enable Jamf LAPS -> https://community.jamf.com/t5/tech-thoughts/how-to-securely-manage-local-admin-passwords-with-jamf-pro-and/ba-p/289969. 

#!/bin/bash
# Reading JAMF Laps password
# Author: A. Collins

username="api username"
password="password"
url="your jamf url"
localadmin="local admin account that deployed in prestage"


serialnn=$(ioreg -rd1 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformSerialNumber/{print $4}')

#Variable declarations
bearerToken=""
tokenExpirationEpoch="0"

getBearerToken() {
response=$(curl -s -u "$username":"$password" "$url"/api/v1/auth/token -X POST)
bearerToken=$(echo "$response" | plutil -extract token raw -)
tokenExpiration=$(echo "$response" | plutil -extract expires raw - | awk -F . '{print $1}')
tokenExpirationEpoch=$(date -j -f "%Y-%m-%dT%T" "$tokenExpiration" +"%s")
}

checkTokenExpiration() {
nowEpochUTC=$(date -j -f "%Y-%m-%dT%T" "$(date -u +"%Y-%m-%dT%T")" +"%s")
if [[ tokenExpirationEpoch -gt nowEpochUTC ]]
then
echo "Token valid until the following epoch time: " "$tokenExpirationEpoch"
else
echo "No valid token available, getting new token"
getBearerToken
fi
}

invalidateToken() {
responseCode=$(curl -w "%{http_code}" -H "Authorization: Bearer ${bearerToken}" $url/api/v1/auth/invalidate-token -X POST -s -o /dev/null)
if [[ ${responseCode} == 204 ]]
then
echo "Token successfully invalidated"
bearerToken=""
tokenExpirationEpoch="0"
elif [[ ${responseCode} == 401 ]]
then
echo "Token already invalid"
else
echo "An unknown error occurred invalidating the token"
fi
}

checkTokenExpiration
ComputerJSSID=$(curl -H "Accept: text/xml" -sfku "${username}:${password}" "${url}/JSSResource/computers/serialnumber/${serialnn}/subset/general" | xmllint --xpath '/computer/general/id/text()' -)
#echo "Computer JSS ID is: $ComputerJSSID"

managementId=$(curl -s -H "Authorization: Bearer ${bearerToken}" "$url/api/v1/computers-inventory-detail/$ComputerJSSID" -X GET -H "accept: application/json" | grep managementId | awk -F'"' '{print $4}')
#echo "Management ID is: $managementId"

#Read Password
localadminpass=$(curl -s -H "Authorization: Bearer ${bearerToken}" "$url/api/v2/local-admin-password/$managementId/account/$localadmin/password" -X GET -H "accept: application/json" | awk -F '["]' '/"password" 😕 { print $4 }')


invalidateToken


echo "<result>$localadminpass</result>"

 

Good in theory but doing API calls from an endpoint is not recommended (even Jamf say this). Even more so that the EA is updated every time an inventory update is done which could be multiple times a day. If you do need to do API calls it would probably be best to encrypt the creds somehow or use base64 encoded in the EA but no matter how you look at it you're still doing calls from an endpoint (even if it is a RO action or account with RO privs)

You can encode credentials to pass through, the reason I shared this, also changing serialnn with below allow techs to see local admin password by entering serial

read -r -d '' applescriptCode <<'EOF'
 set dialogText to text returned of (display dialog "Please Enter Serial Number" default answer "")
 return dialogText
EOF

serialnn=$(osascript -e "$applescriptCode");

Another way you can do it is rather than send $username:$password is to use 

 

-H Authotization: Basic <base64encodedcreds>

 

 I have thought about how to get this password for techs (not using it at this time though). I figured that Jamf will come up with a solution so it can be audited like the PRK when you view it and so it's not visible in plain text when looking at the record. But you're still doing API calls on an endpoint which just doesn't sit right given you can't 100% trust the device or the user

Another way you can do it is rather than send $username:$password is to use 

 

-H Authotization: Basic <base64encodedcreds>

 

 I have thought about how to get this password for techs (not using it at this time though). I figured that Jamf will come up with a solution so it can be audited like the PRK when you view it and so it's not visible in plain text when looking at the record. But you're still doing API calls on an endpoint which just doesn't sit right given you can't 100% trust the device or the user


+1 for for @shannon_pasto 's reminder that calling the Jamf Pro API from an arbitrary endpoint isn't recommended. And for anyone considering restricting the IP addresses allowed to access your Jamf Pro console be aware that same restriction will apply to calling the API.

Reply


Terms & ConditionsCookie settings