Skip to main content

Hi, I have quite a few macs with admin accounts on 10.13.6 that dont have a secure token (viewed by running sysadminctl command).
I want to add the secure token silently without involving the user via ssh or someother tool, as i have seen the users of the machines have this secure token.
I have tried sysadminctl -secureTokenOn "admin account" -password "password" but get
Operation is not permitted without secure token unlock.
i know that
sysadminctl -adminUser user -adminPassword “password” -secureTokenOn "admin account" -password “password”
Will probably do it but i cant go asking for the user password



Does anyone know of another way?

@johntgeck I just tried your script and got the same error.

Then ran my iteration here and it does work.. just prompts for an additional pop up from sysadminctl 

#!/bin/bash


#get logged in user
currentuser=$(/bin/ls -la /dev/console | /usr/bin/cut -d ' ' -f 4)

user_entry=""

#prompt user for their password
while [ "$user_entry" = "" ] ; do

user_entry=$(osascript -e '
tell application "Finder"
activate
try
display dialog "Please enter local password" with title "Assign SecureToken" default answer ""
set user_entry to the (text returned of the result)
on error number -128
set user_entry to ""
end try
return user_entry
end tell')

done
echo $user_entry

#pass info into terminal to grant token from admin user

sudo /usr/sbin/sysadminctl -secureTokenOn $currentuser -password $user_entry interactive || -adminUser $4 -adminPassword $5

exit 0

 


Thank you for this! 
This worked for me.

I created another user (admin1) and when I created that user, it had SecureToken Enabled. 

I logged into the original Admin account that didn't have it enabled and ran this script from Terminal. 
From there, I typed in the password for original admin account, and when the box came up for credentials, I used the newly created admin1 credentials. It enabled SecureToken for my original admin and then I deleted the other admin account that I created. 

Saved me the trouble of having to wipe/re-install OS.


Thank you for this! 
This worked for me.

I created another user (admin1) and when I created that user, it had SecureToken Enabled. 

I logged into the original Admin account that didn't have it enabled and ran this script from Terminal. 
From there, I typed in the password for original admin account, and when the box came up for credentials, I used the newly created admin1 credentials. It enabled SecureToken for my original admin and then I deleted the other admin account that I created. 

Saved me the trouble of having to wipe/re-install OS.


Yep, this is the solution we've been using in limited scope, but it doesn't help the other 200 or so computers that have been deployed that are in a similar situation. I'm not walking around and touching them all.


Yep, this is the solution we've been using in limited scope, but it doesn't help the other 200 or so computers that have been deployed that are in a similar situation. I'm not walking around and touching them all.


I have managed to get this pretty streamlined where all the user has to do is setup a quick 5 minute zoom meeting, then run a policy from Self Service, and then once it asks to change system settings, we get take control of the screen and enter the IT admin account. 
Then they are now secure token enabled and good to go. 

Glad to share more if you want to know more. 


Yep, this is the solution we've been using in limited scope, but it doesn't help the other 200 or so computers that have been deployed that are in a similar situation. I'm not walking around and touching them all.


We have been able to resolve about 150 of these issues will minimal effort so our users can now update on their own and don't have the secure token issues. 


We have been able to resolve about 150 of these issues will minimal effort so our users can now update on their own and don't have the secure token issues. 


My problem is most of the computers suffering this issue are unattended (lab or classroom computers), but I'm taking all of these suggestions to heart to find the most streamlined solution.


My problem is most of the computers suffering this issue are unattended (lab or classroom computers), but I'm taking all of these suggestions to heart to find the most streamlined solution.


do they all have the same admin account password? 


do they all have the same admin account password? 


They do, yes.


my problem is laps totally screwed this up.  Our original admin password doesnt always work for this, where yes it recognizes the admin password as correct and shows the admin with the token and volume ownership, but its not working to allow an update (almost like laps broke the actual record of the admin password for volume ownership).  So im not sure how to proceed since I cant get any of the above methods to work.  Only one I didnt try was to create another admin user and see if it gets a token.


my problem is laps totally screwed this up.  Our original admin password doesnt always work for this, where yes it recognizes the admin password as correct and shows the admin with the token and volume ownership, but its not working to allow an update (almost like laps broke the actual record of the admin password for volume ownership).  So im not sure how to proceed since I cant get any of the above methods to work.  Only one I didnt try was to create another admin user and see if it gets a token.


The jamf documentation outlines that it changes the password but doesnt change the cryptographic encryption password. So expected behaviour and it will vary from machine to machine based on other variables... 

Its a bit of a dogs breakfast to get consistant across a fleet of macs...

 


The jamf documentation outlines that it changes the password but doesnt change the cryptographic encryption password. So expected behaviour and it will vary from machine to machine based on other variables... 

Its a bit of a dogs breakfast to get consistant across a fleet of macs...

 


Which is why, despite the obvious security advantages of LAPS, we still maintain a separate local admin that does not have a rotating password. 


We use the LAPS password in the event that a user needs to perform an unexpected admin task in the field.


So I have come up with a script to change the laps passwords on a specified smart group back manually to a specific password.  This is helping us undo some of the issues we have seen on Apple Silicon with volume ownership.  Obviously for security reasons I would run this only locally on a machine and not upload this script to the jamf cloud distribution point without some encryption of passwords.


 


#!/bin/bash

# API USER
user="YOUR_API_USERNAME_HERE"
# API PASSWORD
pass="YOUR_API_USER_PASSWORD_HERE"
# URL (https://yourjamfserver.jamfcloud.com)
jurl="https://YOUR_JAMF_URL_HERE"
# Smart group or static group ID to get computer IDs from
groupID="YOUR_SMARTGROUP_ID_HERE"
# Define the admin user name
adminname="YOUR_ADMIN_USERNAME_HERE"
# New LAPS password to set
newPassword="YOUR_PASSWORD_HERE"


# Get Bearer token for API calls
getBearerToken() {
response=$(curl -s -u "$user:$pass" "$jurl/api/v1/auth/token" -X POST)
token=$(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")
echo "Token acquired."
}

# Invalidate the token once done
invalidateToken() {
curl -w "%{http_code}" -H "Authorization: Bearer $token" "$jurl/api/v1/auth/invalidate-token" -X POST -s -o /dev/null
echo "Token invalidated."
}

# Check token expiration and get a new one if necessary
checkTokenExpiration() {
nowEpochUTC=$(date -j -f "%Y-%m-%dT%T" "$(date -u +"%Y-%m-%dT%T")" +"%s")
if [[ tokenExpirationEpoch -gt nowEpochUTC ]]; then
echo "Token is valid."
else
echo "Token expired, fetching new token."
getBearerToken
fi
}

# Run the function to get the token
getBearerToken

# Grab all computer IDs from the smart group (ID 802)
echo "Fetching computer IDs from group ID: $groupID"
computerids=($(curl -s $jurl/JSSResource/computergroups/id/$groupID \\
-H 'accept: application/xml' \\
-H "Authorization: Bearer $token" | xmllint --xpath '/computer_group/computers/computer/id/text()' -))

echo "Found Computer IDs: ${computerids[@]}"

# Loop through all computer IDs to look up the managementId and reset the LAPS password
for id in "${computerids[@]}"; do
checkTokenExpiration

# Get computer details to retrieve the managementId
computerInfo=$(curl -s "$jurl/api/v1/computers-inventory/$id?section=GENERAL" \\
-H 'accept: application/json' \\
-H "Authorization: Bearer $token")

# Extract the managementId using jq
managementId=$(echo "$computerInfo" | jq -r '.general.managementId')

if [[ -z "$managementId" || "$managementId" == "null" ]]; then
echo "No management ID found for computer $id, skipping..."
continue
fi

echo "Found Management ID: $managementId for computer $id"

# Reset the LAPS password for the macadmin user using the correct API endpoint
curl -s -X PUT "$jurl/api/v2/local-admin-password/$managementId/set-password" \\
-H "accept: application/json" \\
-H "Authorization: Bearer $token" \\
-H "Content-Type: application/json" \\
-d "{\\"lapsUserPasswordList\\": [{\\"username\\": \\"$adminname\\", \\"password\\": \\"$newPassword\\"}]}" || echo "Failed to reset LAPS password for computer $id with Management ID: $managementId"

done

# Invalidate the token when done
invalidateToken

exit 0

 


 


They do, yes.


Then theoretically (unfortunate security risk) you could embed the admin password into the script and sent the whole script to the Mac to grant the secure token access. You would still need to be at the Mac though to enter in the user credentials. 
It is a pretty unfortunate situation. Have yet to find a fully automated solution, but this is the best I have come up with thus far. 


#!/bin/bash


#get logged in user
currentuser=$(/bin/ls -la /dev/console | /usr/bin/cut -d ' ' -f 4)

#sudo jamf policy -id ##

sudo killall opendirectoryd
user_entry=""

#prompt user for their password

user_entry=$(/usr/bin/osascript<<END
application "System Events"
activate
set the answer to text returned of (display dialog "Please Enter your Password:" with title "Assign Secure Token" default answer "" with hidden answer buttons {"Continue"} default button 1)
END
)


#pass info into terminal to grant token from it Admin user

sudo -u $4 /usr/sbin/sysadminctl -secureTokenOn $currentuser -password $user_entry interactive || -adminUser $4 -adminPassword -

tokenstatus= /usr/sbin/sysadminctl -secureTokenStatus $currentuser

echo $tokenstatus

exit 0

Hope this helps. 


Reply