Resetting local account password via policy is sporadically failing

Just noticed exactly the same problem, and came here looking for help. We're running via JAMF cloud version 10.8.0-t1539715549 and testing on MacOS 10.14.1. The only difference is it's ALWAYS failing for me, not sporadically. I could have sworn this was working fine a few weeks ago?

fwiw- our local admin account is created manually at startup (via MacOS splash screen). Additionally, applying the reset policy to a freshly created test account also fails with: "Error resetting the password for user test".

We're just beginning to deploy macOS 10.14.2 so I'll see if there's any improvement after updating.

I've experienced issues using the Jamf binary (or dscl) to reset user passwords since High Sierra. I would create a new policy to reset using sysadminctl (this will also create a new Keychain for the account). I'm using LAPS at my org to accomplish this, but here's an example:

sysadminctl -adminUser $AdminUserHere -adminPassword $AdminPasswordHere -resetPasswordFor $UserToBeReset -newPassword $NewPasswordHere

I reached out to our Jamf Support team last week about this on all our Mojave machines it fails every single time. The following is from support.

This issue is specifically on macOS 10.14 systems where the user has a secure token. The way the underlying macOS security framework currently handles this request, doesn't allow us to issue a password reset for accounts where they are FileVault enabled due to secure token. We are currently working with Apple on this issue, but we do not currently have an ETA on when a fix will be released.

Thanks sshort for the tip, also LAPS looks really cool!

I'd previously written off using sysadminctl due to the need for hardcoding passwords in a script, but the more I think about it, I suppose we could simply and quickly pass sensitive stuff to the script via parameters in the JAMF policy? We could even go a step further and create 'Encrypted Script Parameters' via this slick solution: https://github.com/jamfit/Encrypted-Script-Parameters

Does anyone see an issue with this methodology short of anyone with access to the JAMF policy having visible access to plain text passwords (or access to the encrypted string that pairs with a script's salt/passphrase)? Are JAMF policy scripts ever cached locally or transmitted unencrypted?

Thanks for the confirmation and brainstorm folks!

Yes, what I noticed today is that the local account created during system setup on 10.14.2 is fiercely protected by the OS. Another admin cannot delete this account, set the Secure Token status to DISABLED, or force a password change without providing the old password. This appears to be Apple's solution to the Secure Token problem: not letting any action disable that initial user's secure token. Even if you have the password for that admin account you cannot delete it by any mechanism I've found.

So, if you forget the password for that user and no other users have secure tokens, you're still hosed and cannot encrypt with FV. It in no way solves the problems we're facing, where we have to use that local admin password to encrypt with FV or grant another user a secure token. I'd like to not rely on that.

What we end up is ultimately less secure than the old FV auth system, and we end up with devices that we cannot encrypt without someone entering the first local admin's password.

Still no solution between Jamf and Apple I guess? It's been failing for me every time on Mojave machines.

A note in the policy that this isn't compatible with the initial Secure Token account would be nice at least in the meantime.

is this still an issue?

Anyone had any luck fixing this? Is there a scripted solution? One of our techs just left the organization and we need to rest the local admin account on a bunch of systems. We get the same error as the OP. Any help is much appreciated.

@jssmelser @tstott Looks like we're still in the same boat. We have tried as well and appears to be changed until we attempt to log in. Have not tried on machines running an os prior to Mojave though.

Did someone get into contact with JAMF yet?
I have the same problem @jssmelser has, a former employee knows some local admin passwords and we have to change them. I don't really see a way to change them remotely right now.
Did someone do something similar yet?

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)

I got in contact with JAMF support to understand the issue more. Changing the account password through a policy is no longer a viable solution. If the account is secure token enabled, Jamf cannot change the password with a policy any longer due to incompatibility with macOS 10.14 systems. The reason why secure token makes it so the policy can not run is that the previous password needs to be entered to change it. Jamf does not provide the current password as they do not save passwords.

Agree that it would be nice to have some kind of notice on the policy as some of our macs are now borked.

What we really need is for Jamf to be able to manage a secure tokenized local account, escrowing and rotating the password the same way it handles FileVault keys.

That will happen when Jamf allow bootstrap tokens with Catalina

I'm testing the following as a way to reset a known Local Account password, along with its ability to unlock a FileVault encrypted boot drive. This is working in my testing so far - all Mojave Macs. UPDATE: After some wipes and rebuilds, the script is no longer working.

Feel free to provide feedback, as I've cobbled this together from a few other Jamf Nation posts. For example
- It seems there should be a way to create a directory with the touch command (UPDATE - touch doesn't create directories)
- I wonder if there should be a time delay after changing the local admin password before passing the SecureToken using this new password

What doesn't work:
I get the following error:
""Script result: 2019-10-28 09:20:16.552 sysadminctl[3915:47179] ### Error:-14090 File:/BuildRoot/Library/Caches/com.apple.xbs/Sources/Admin_sysadminctl/Admin-716/addremoveuser/main.m Line:373<br/>2019-10-28 09:20:16.552 sysadminctl[3915:47179] Operation is not permitted without secure token unlock.<br/>2019-10-28 09:20:16.783 sysadminctl[3916:47185] ### Error:-14090 File:/BuildRoot/Library/Caches/com.apple.xbs/Sources/Admin_sysadminctl/Admin-716/addremoveuser/main.m Line:373<br/>2019-10-28 09:20:16.783 sysadminctl[3916:47185] Operation is not permitted without secure token unlock.<br/>""

I've added what I think should be the SecureToken Unlock (-secureTokenOff)

I've added set -e in an attempt to prevent the creation of the pw_updated.txt file, though the above error does not cause an immediate exit.

HOW I'D LIKE THINGS TO WORK
Extension Attribute (paired with a Smart Group for Scoping)

#!/bin/sh
# Jamf Extension Attribute to determine the presence of the "admin_pw_updated.txt" file
if [ -f "/usr/local/pwstatus/pw_updated.txt" ]; then
    echo "<result>PW Updated</result>"
fi

Script, part of a policy, running at check-in, ongoing, with an inventory update, scoped by the Smart Group above (so that the policy only runs on only the Macs whose password was not yet changed. The script itself also has logic so that it only runs on the Macs whose password was not yet changed)

#!/bin/sh
# Exit immediately if any part of the script is unsuccessful
set -e
#Check to see if password was already changed
if [ -f "/usr/local/macops/pw_updated.txt" ]; then exit
else
admin_user_name="ADMIN_ACCOUNT"
new_password="NEW_PASSWORD"
old_password="OLD_PASSWORD"

# Unlock the Administrator SecureToken
sysadminctl -adminUser $admin_user_name -adminPassword $old_password -secureTokenOff $admin_user_name -password $old_password

# Change the password
sysadminctl -adminUser $admin_user_name -adminPassword $old_password -resetPasswordFor $admin_user_name -newPassword $new_password
sysadminctl -adminUser $admin_user_name -adminPassword $new_password -secureTokenOn $admin_user_name -password $new_password
mkdir /usr/local/pwstatus
touch /usr/local/pwstatus/pw_updated.txt
fi

Hey, quick follow-up from my side: I managed to get the password changed by using scripts to do the following steps (only viable if you want to "change" admin accounts PW and if there's no local data needed on the admin account):

1) create a new Admin user with the permissions of the current Admin user (with a new password obviously)
-> new Admin user has a secure token because it's created by the old Admin user
2) check with smart group if both Users exist (Old Admin User + new Admin user) and if they both have a secure token
3) If that's the case, delete Old Admin user

Please keep in mind that you don't really want to put the new password in plain text in your script. For encrypting it I was using https://github.com/jamf/Encrypted-Script-Parameters

If someone needs any of the scripts I was using, feel free to ask :)

I am aware that this is by far not the best practice, but it worked for ~400 MacOS devices. I am also aware that this does not solve all the problems in this thread, but I hope I can help some of you at least :)

I would love it if you could send me the script you used @leonwun . I am trying to do this exact same thing (create new admin user, and use that admin user to remove old admin user that we are locked out of), and am struggling to get it working.

Hey Paul,

what do you mean by "locked out of"? Do you still have access to the old admins password? Because the old password is still needed for this to work.

Yeah, that is the part where I am stuck. I have a hidden user that is an admin that I can use when I need to manually install something on a user's laptop. However, the password for that admin user suddenly stopped working on 6 of our 30 machines about a month ago, and now there is no way that I can find to gain access to that admin user again.

@leonwun you mind sharing your script?

I have no issue with being able to provide the previous password to the local admin. Im just currently getting the Error:-14090 (operation is not permitted without secure token unlock

• First you set up a policy. Local Accounts -> Create New Account -> Fill in Name etc. + Password (this creates the new Admin account WITHOUT SecureToken, Checking "Enable user for FileVault2" won't change anything.)

• In this same policy, you put the following script with the Priority "after" so the Account gets created first.

#!/bin/bash

function DecryptString() {
    echo "${1}" | /usr/bin/openssl enc -aes256 -d -a -A -S "${2}" -k "${3}"
}
adminOLDpassword=$(DecryptString $4 'HIDDEN' 'HIDDEN')
adminNEWpassword=$(DecryptString $5 'HIDDEN' 'HIDDEN')

# Give SecureToken to new Admin account
sysadminctl -adminUser adminOLD -adminPassword $adminOLDpassword -secureTokenOn adminNEW -password $adminNEWpassword

For Information on the "DecryptString" stuff please refer to https://github.com/jamf/Encrypted-Script-Parameters.
You have to encrypt the old and the new Admin password and insert it (and a part of it into the Parameter Values).

In order to delete the old Administrator account, I just created a Smart Group that checks if the new Admin exists - every device in this group will have the old Administrator account deleted automatically.

i been trying to change the password on an admin account which have secure token enabled using the encrypt script above mentioned but i keep having the same error

sysadminctl[22146:395596] Operation is not permitted without secure token unlock

i also try to disable the secure token with a different admin user, but same error...

sysadminctl -adminUser otheradmin -adminPassword $otheradminpass -secureTokenOff target -password $targetadminpass

is it possible to change the password though a policy (without user intervention) if the user is filevault enabled?

If you are able to access the machine try running it in interactive mode like this:

sysadminctl interactive -resetPasswordFor "accountToReset" -newPassword "adminNEWpassword" -passwordHint "Password Hint" -adminUser "adminKnownAccount" -adminPassword "adminKnownPassword"

That should prompt you to authenticate with admin details. If that works then try using this command:

sudo sysadminctl -resetPasswordFor "accountToReset" -newPassword "adminNEWpassword" -passwordHint "Password Hint" -adminUser "adminKnownAccount" -adminPassword "adminKnownPassword"

For both remember to replace all the placeholder values in quotes with the actual values!!

This worked for me providing the user had been enabled for secure token.

Going to add this here because I just tracked a similar error down and it seems like it could be related.

If you are enforcing password complexity requirements and you create an account using the JSS with a password that does not meet those requirements, the account ends up in a limbo state. MacOS will insist the password for this account is wrong, and trying to do anything to this account via the JSS (delete, reset password, anything) will fail with a nondescript error. The only remedy I've found is to log in as an admin and manually change the password for the affected account. This even affects accounts that are not filevault enabled, not sure if it's a JAMF bug or a MacOS bug but if it's on the Mac side it's existed at least since Mojave.