Changing Local Admin Account Password (Help!)

[GreatestJagras]

As a part of standard security audits, we like to rotate the local admin password we have on our mac computers every so often. This worked well enough a year ago, however I did notice some outlier computers where there was an error saying that the admin password could not be changed due to the Secure Token. When I most recently tried to run the same script that previously worked, not only did it not change the local admin password, it seems to wipe it completely where I can no longer login using either the new or old passwords.

I've tried many different workarounds to try and get the local password to change, including using Jamf's built in Local Account Management policy, and using scripts with the sysadminctl command and have thus far been unsuccessful. Some things I found in my reserach are that there must always be an admin account present on a mac, and one client must always have a SecureToken assigned before login. The most recent workaround I tried is listed below, wherein I created a new local admin account using Local Account Management (admintemp), and then tried to use that admin account to turn off the SecureToken for the administrator before changing the password and re-enabling it.

sysadminctl -secureTokenOff administrator -Password $LOCALADMINPASSWORD -adminUser admintemp -adminPassword $ADMINTEMPPASSWORD

sysadminctl -adminUser admintemp -adminPassword $ADMINTEMPPASSWORD -resetPasswordFor administrator -newPassword $NEWPASSWORD

sysadminctl -secureTokenOn administrator -password $NEWPASSWORD -adminUser admintemp -adminPassword $ADMINTEMPPASSWORD

My plan was to just delete the admintemp account once I was done, but I can't even get the local admin password to change no matter what I do. I also tried to just delete the local admin account and re-create it with the new password I want, but that didn't work either because the account has a secure token.

If anyone has suggestions, please help! Local admin password rotations are a standard IT practice and I refuse to believe that Apple has made it this complicated to do.

[AJPinto]

You cannot rotate the password on a Secure Token holding account with JAMF. When you are creating the "new" local admin account, it does not have a Secure Token. So, Your "new" admin account cannot rotate the "main" admin accounts password as it has a secure token.

You would need to acquire a tool specifically designed for account Maintenance like CyberArk EPM that can use a secure token (providing it is given a token) to rotate passwords. This kind of account maintenance is really outside of JAMFs wheelhouse. 

[GreatestJagras]

I checked the admintemp account I created via Jamf policy using terminal and confirmed that it also did have a Secure Token applied to it. Can an account with a Secure Token also not modify another account with a Secure Token?

[AJPinto]

An account with a secure token, can rotate the password of another account with a secure token. However, keep in mind. Anything you do in CLI is in plaintext, so the user name and password can be picked up by lots of network tools and on the device itself. 

[mschlosser]

I believe to properly fix this issue you'd need to a couple things:

-Determine which user accounts already have a securetoken; I'll include an extension attribute that I use to list secure token holders within the computers inventory record

----------

#!/bin/zsh

# Extension attribute to report all user accounts who have a secure token
# If a user is found to have a secure token, the results will be displayed as:
# Admins: user1, user2 (or "None" if none found)
# Non-Admins: user1, user2 (or "None" if none found)
#
# If no user is found to have a secure token, the result will be:
# "No Secure Token Users"
# If an unsupported file system is found, the result will be:
# Unsupported File System: (File System Type)

# Variable to determine File System Personality
fsType="$(/usr/sbin/diskutil info / | /usr/bin/awk 'sub(/File System Personality: /,""){print $0}')"

if [[ "$fsType" != *APFS* ]]; then
echo "<result>Unsupported File System: $fsType</result>"
exit 0
fi

secureTokenAdmins=()
secureTokenUsers=()

# Loop through UUIDs of secure token holders
for uuid in ${$(/usr/sbin/diskutil apfs listUsers / | /usr/bin/awk '/\+\-\-/ {print $2}')}; do
username="$(/usr/bin/dscl . -search /Users GeneratedUID ${uuid} | /usr/bin/awk 'NR==1{print $1}')"

if /usr/sbin/dseditgroup -o checkmember -m "$username" admin &>/dev/null; then
secureTokenAdmins+=($username)
else
secureTokenUsers+=($username)
fi
done

if [[ -z ${secureTokenAdmins[@]} ]]; then
stList="$(echo "Admins: None")"
else
stList="$(echo "Admins: ${secureTokenAdmins[1]}")"

for user in ${secureTokenAdmins[@]:1}; do
stList+=", $user"
done
fi

if [[ -z ${secureTokenAdmins[@]} ]] && [[ -z ${secureTokenUsers[@]} ]]; then
stList="$(echo "No Secure Token Users")"
elif [[ -z ${secureTokenUsers[@]} ]]; then
stList+="\n$(echo "Non-Admins: None")"
else
stList+="\n$(echo "Non-Admins: ${secureTokenUsers[1]}")"

for user in ${secureTokenUsers[@]:1}; do
stList+=", $user"
done
fi

echo "<result>$stList</result>"

---------

Once you know what if any users have a secure token, if you know. there password, you could use the commands that you reference abnbove or other scripting solutions to use the account that has a token to grant one to the accounts that do not.  

That said I don't believe it is necessary to turn the token off, if an account exists that has one. All that said, sadly you need to know both the account namer and the password.

Hope that helps.

[GreatestJagras]

Thank you for this tool. I've gotten to the point where I can get the script I run to "succeed" on the client computer, however it doesn't actually set a new password. The below script doesn't actually set a new password, it just wipes out the existing one without setting a new one.

sysadminctl -adminUser administrator -adminPassword $ADMINPASS -resetPasswordFor administrator -newPassword $NEWPASSWORD

 I'm thinking maybe just remove the reset portion and see if -newPassword alone will set a new password. It's really annoying as right now I'm having to re-image my test station after every attempt since the account keeps getting its password wiped out.

[GreatestJagras · Accepted solution]

Finally figured out a solution to this! After many attempts to get the sysadminctl command to work, I had zero success and it would always either wipe the password without changing it, give me the secureToken error, or just hang up and never complete. Using the Files and Processes payload though, I was finally able to rotate our local admin password. To do so, use the below CLI command in the Files and Processes payload.

jamf changePassword -username ADMINUSER -password 'NEWPASSWORD' -oldPassword 'OLDPASSWORD'

 My only caveat to the above command is that you need to know the pre-existing password, but for us that isn't a problem.

[Maclife]

does this also has the keychain password updated and what about FileVault ? is the user still FileVault enabled with a valid key ?

[GreatestJagras]

No this method does not touch the keychain password, and yes the user should still have a valid FileVault Key.