Posted on 08-06-2018 07:05 AM
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?
Posted on 08-06-2018 07:24 AM
Following...
Just went through this and couldn't come up with a solution that worked.
Had to wipe and re-install macOS
Posted on 08-06-2018 07:35 AM
Have you verified that the "admin" account has a secureToken?
sysadminctl -secureTokenStatus <username>
My (very limited) understanding is that only a secureToken enabled account can give a secureToken to another user.
Posted on 08-06-2018 07:43 AM
m.donovan yes, i ran the sysadminctl command to verify this.
Posted on 08-06-2018 08:31 AM
The sad fact is that you need two passwords to give someone a Secure Token: their own password, and the password of an admin account with a Secure Token. It is totally scriptable but the user has to participate.
You can easily get yourself into a situation where nobody knows a usable local admin password and the system cannot be encrypted. You need to start over. Apple is touting this as making the OS very secure, which it does, but at a huge cost. It's bad design for enterprises.
Posted on 08-06-2018 08:33 AM
Apple's enterprise support suggested re-running the first boot AppleSetup and creating a new admin account (which should have created a secure token for that account), but it didn't.
Posted on 08-06-2018 08:37 AM
SecureToken is garbage. We've had to wipe and redeploy our devices where SecureToken has broken for all users.
Posted on 08-06-2018 09:59 AM
Are your users Administrators on their Macs? Because they would need to be to grant another user account a SecureToken, even if you had their password.
This isn't really helpful post-deployment, but this is what I have planned for my deployment:
I'm using a script to activate FileVault as my admin user (with EncryptedStrings for the password) which so far has reliably given the admin user the SecureToken as long it is run before a user signs in (my DEP process has the Account Settings configured to skip account creation, just creates the management account and my admin user). So i'm taking over the login window for a few seconds before they sign in.
fdesetup enable -user "Admin" -password "password"
The user has to sign in around a tech so they get the SecureToken prompt and can be given a SecureToken to unlock their own machine. Local techs have their own local admin accounts on the Mac so I'll use
sysadminctl -adminUser "Admin" -adminPassword “password” -secureTokenOn "localAdmin" -password “password”
So that local techs can grant SecureToken without my Admin account.
Posted on 08-06-2018 12:05 PM
Had a similar issue earlier this year (see my post) where Apple came back and basically said the only option would be to erase and reinstall to get an account which could enable secure token (i.e. one created at initial setup). A few weeks ago someone mentioned that @rtrouton had some insight into 10.13.5+ getting a token after the fact, but I haven't tried that yet.
Posted on 03-21-2019 02:40 PM
The admin account created by JAMF on first boot during DEP enrollment in MDM is not created with securetoken. Because no account has a token, you can't add a token. This catch22 should not be possible, which is Apple's fault, and the account made by JAMF should have a token which I want to say is JAMF's fault, unless Apple is once again not giving sauce to the product they indicate we should be using.... Either way, until this is fixed all our new hardware is half bricked, has service limits, and can't dual boot. Or, we ditch JAMF and do entirely manual deployments to get full operation. Lose lose.
Posted on 03-22-2019 06:49 AM
@ebonweaver sorry but your claims are just not accurate. please have a look at my reply here: Secure Tokens
Posted on 03-22-2019 07:18 AM
Sorry to say, my statements are very much accurate. I'm aware you can script your way out of the problem, we're looking for the product to not require this or force a change of workflow to compensate.
Posted on 03-22-2019 07:23 AM
I am not scripting anything Sir. See other topic.
Posted on 04-17-2019 10:49 PM
I want to chip in.. :)
I to have this weird problem. But....
My local admin DOES have a secure Token. but still I am unable to add the secure TOken to a (mobile) user account who has no Secure Token
sysadminctl interactive -secureTokenStatus admin
2019-04-18 07:47:12.246 sysadminctl[1612:42740] Secure token is ENABLED for user Admin
sysadminctl interactive -secureTokenStatus jdoe
2019-04-18 07:44:30.937 sysadminctl[1610:42422] Secure token is DISABLED for user John Doe
sysadminctl -interactive -secureTokenOn jdoe -
2019-04-17 16:32:51.718 sysadminctl[1536:36268] Operation is not permitted without secure token unlock.
if anyone have any ideas??!!
Posted on 04-17-2019 11:07 PM
You need to provide token holder and password to “unlock”:
sysadminctl -adminUser admin -adminPassword addAdminUserPasswordHere -secureTokenOn jdoe -password addjdoePasswordHere
And then “diskutil apfs updatePreboot /“ to allow that user to unlock FV at boot
Posted on 04-17-2019 11:24 PM
@frederick.abeloos Tried, same result....
Posted on 04-17-2019 11:30 PM
@rblaas diskutil apfs listcryptousers /
Is the UUID you see in the list the same as the UUID of your admin user?
If “admin” is really an admin, and if he really has a token, your admin user UUID should be listed in the reply of thatiscryptousers command
Posted on 04-17-2019 11:33 PM
Posted on 04-17-2019 11:36 PM
@rblaas tried with sudo?
Posted on 04-17-2019 11:39 PM
@frederick.abeloos Yep :)
Posted on 04-19-2019 06:44 PM
What is the error output from the command @frederick.abeloos gave you ?
Posted on 04-20-2019 08:06 AM
I found my problem... I was using quotes (double quotes) and there was no need to use quotes.
This fixed my problem
Posted on 08-04-2019 05:14 PM
Additionally,
The sysadminctl command doesn't output proper return codes. So even if the command fails with the standard "Operation is not permitted without secure token unlock.", the exit code is still 0 and always is 0 which is bad. (At least in 10.13)
Posted on 04-24-2023 04:41 AM
@bsuggett am having the same issue, did you find a solution?
Posted on 05-12-2023 02:02 PM
Still running into the dreaded "Operation is not permitted without secure token unlock."
Secure token is enabled for the admin acct called in the script. Syntax is as below, admin user & password are defined as parameters 4 & 5, respectively.
#!/bin/bash
currentUser=$(who | grep "console" | cut -d" " -f1)
userPwd=$(osascript << EOF
text returned of (display dialog "Please enter password for $currentUser to allow FileVault encryption" default answer "xxxxxxxxx" buttons {"OK"} default button 1 with hidden answer)
EOF
)
echo "Enabling secure token for $currentUser"
sysadminctl -adminUser $4 -adminPassword $5 -secureTokenOn $currentUser -password $userPwd
Posted on 05-24-2023 06:20 PM
@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
Posted on 11-22-2023 03:21 PM
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.
Posted on 12-14-2023 10:08 AM
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.
Posted on 12-14-2023 11:17 AM
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.
Posted on 12-14-2023 11:18 AM
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.
Posted on 12-14-2023 11:20 AM
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.
Posted on 12-14-2023 11:21 AM
do they all have the same admin account password?
Posted on 12-14-2023 11:22 AM
They do, yes.
2 weeks ago
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.
Posted on 09-17-2024 08:25 AM
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.
Posted on 09-17-2024 06:39 PM
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...
Posted on 09-18-2024 07:13 AM
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.
09-18-2024 07:28 AM - edited 09-18-2024 07:36 AM
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