BigSur update won't accept password on M1 Machines

[mwu1876]

I have an issue that only affects M1 machines. When I click to update the machine to, let's say 11.2 (also happened to 11.1) it prompts "Software Update is trying to authenticate user. Enter the password...". It's for the user I'm logged in as. I type in the password and it won't accept it. I'm able to log in and authentication unlocking other areas of the system, just not update. It impacts any user (local admins) and all machines with the M1 processor. We've had 0 issues with all other deployments. Anyone else having this issue?

[genazzano]

Experiencing the exact same issue updating to from 11.0.1 to 11.2 but so far only for mobile network accounts (AD) with administrator access. A local administrator account performed the update OK.

[mwu1876]

So it works for local admins on M1 machines? I have 3 here and none of them work with any account. All stuck on 11.0.1.

[Nick1403]

Hello :) sounds to me like the users don't have a secure token. Your User need a Secure Token.

https://www.jamf.com/blog/reinstall-a-clean-macos-with-one-button/

[genazzano]

Hi @Nick1403 I think we are onto something here as we have always suppressed the Secure Token creation request on login. Have you escrowed a Secure token into your MDM solution?

[genazzano]

@mwu1876 yes a local admin account created at the prestage configuration works every time. I have since investigated the Secure Token bootstrap for mobile network accounts and our config applies a token to them too. So I am back to square one. My next thought is to get a machine to 11.1 via a factory reset, then enroll it and see if the issue persists going to 11.2.

[theelysium]

So far all versions of BS M1 when connected to our MDM can't update.

[BigTrouble]

@Nick1403

Hello :) sounds to me like the users don't have a secure token. Your User need a Secure Token. https://www.jamf.com/blog/reinstall-a-clean-macos-with-one-button/

Does this only apply if FileVault is enabled? We are not using FileVault and are still experiencing this problem.

[Strannik]

@BigTrouble, I can confirm that Secure Token is needed and FileVault status doesn't matter.
Somehow it happened that none of users on our test M1 MBA had Secure Token, so update did't accept user passwords. Even Admin account wouldn't work. I had to restore MacBook with AC2.

[cmarstaller1769]

On the M1's, I've found that if you're having trouble updating macOS Big Sur, you can boot into Recovery, open Terminal, run resetpassword command, reset the admin account, boot back into macOS Big Sur and the update will process with the admin username/password without issue.

[EliasG]

Has anyone figured out the fix for this? We are testing 5 M1 Mac's user's can't update at all

[EliasG]

@mwu1876 running into this issue, did you find a solution, we have 5 of those machines testing them out and its happening to the end user.

[mwu1876]

@EliasG Yes, it was a quick fix. see here: https://support.apple.com/guide/deployment-reference-macos/using-secure-and-bootstrap-tokens-apdff2cf769b/web

[EliasG]

@mwu1876 which part did you do?

[mwu1876]

@EliasG well, you need to read through it to determine which is your situation. Not everyone's is the same. but, see here:
Command-line tool usage
Command-line tools are available for managing bootstrap token, FileVault, and secure token. The bootstrap token is usually generated on the Mac and escrowed to the MDM solution during the macOS setup process after the MDM solution tells the Mac that it supports the feature. However, a bootstrap token can also be generated on a Mac that has already been deployed. In macOS 10.15.4 or later, a bootstrap token is generated and escrowed to MDM on the first login by any user who is secure token enabled if the MDM solution supports the feature. This reduces the need to use the profiles command-line tool after device setup to generate and escrow a bootstrap token to the MDM solution.

The profiles command-line tool has a number of options to interact with the bootstrap token:
sudo profiles install -type bootstraptoken: This command generates a new bootstrap token and escrows it to the MDM solution. This command requires existing secure token administrator information to initially generate the bootstrap token, the MDM solution must support the feature, and the Mac computer’s serial number must appear in Apple School Manager or Apple Business Manager and enrolled in that specific MDM solution.

sudo profiles remove -type bootstraptoken: Removes the existing bootstrap token on the Mac and the MDM solution.

sudo profiles status -type bootstraptoken: Reports back whether the MDM solution supports the bootstrap token feature, and what the current state of the bootstrap token is on the Mac.

sudo profiles validate -type bootstraptoken: Reports back whether the MDM solution supports the bootstrap token feature, and what the current state of the bootstrap token is on the Mac.

[TxAg]

We are in the same situation. When any of our M1 Mac users try to install updates, it will not take their passwords. I can use the administrator account that is created by policy (run on a smart group of users who do not already have this account) to authenticate. When I run 'sudo profiles install -type bootstraptoken', I get the error "Unable to save Bootstrap Token (-104)". When I run 'sudo profiles status -type bootstraptoken', everything comes back good but when I validate, I get this message "Bootstrap Token escrowed on server: NO".

This has to be an MDM problem or, more specifically, a Jamf problem or else there would be a far greater number of people complaining about this issue in the greater community. Is there something I am doing wrong with my Prestage Enrollments? Is there someway to fix this issue without touching every M1 Mac? Is there a way we can prevent this moving forward? Has anyone talked to Jamf support about the issue?

[EliasG]

@TxAg I agree it sounds like an MDM issue. We are about to roll out 250 of these machines we can't be running around entering our passwords for each user to update.

[JYDP1]

Hello, we're in the same situation here, we couldn't find what we can do except reinstall with Apple Configurator 2.

Anyone, has tested the command line tools ? What are you returns ?

[Jason33]

Had this happen to a user yesterday. His account didnt get a secure token, however a secondary account that gets created during enrollment (its not part of pre-stage, but an account that gets created on recurring check-in) did get a secure token. I thought that was odd. So, I had the user log in with that account, promoted to admin via Jamf Policy, logged back in to his account, ran a policy to issue a SecureToken to his account, made him an admin and verified that his account had a token, updated preboot to add his account. Filevault got enabled properly and a recovery key escrowed, and he was then able to enter his password for software update. I had demoted his account and had him reboot. Very frustrating to deal with, but got it worked out in the end.

[JYDP1]

@Jason33 Which command line you used for this ? "ran a policy to issue a SecureToken to his account"

sudo profiles install -type bootstraptoken ??

[Jason33]

@JYDP1 I modified a script based on this https://github.com/Yohan460/Automatic-Secure-Token-Granting-Workflow

[P_Featherstonha]

Having the same happen with M1 Mac's, clients upgrading to 11.3.1 - the local admin setup with the MacOS out of the box works a treat but not any AD authenticated users (all of who have full admin access). No issues with Intel-based Macs upgrading OS. Is there any update from JAMF on this yet? I see 10.29 has just been released - is there any fixes for this behaviour in this new version? Is this an M1 issue only? Arhhh so many questions - typical Mac - always a pain to manage anything lol

[ewernicke]

Big Sur / M1 / Silicon

This is how we get a SecureToken for users who don't have it.

Requirements:
- We have at least one admin user who DOES happen to have a secure token
-- this user was an admin account jamf creates for us from a poilcy that runs during prestage enrollment

For whatever reason, the "user" (with NON-admin rights)... did not have a token.

you can see who has a token with this command (replace USERNAME with an actual username):

sysadminctl interactive -secureTokenStatus USERNAME

If you open a terminal as the "user" ... then:

login
sysadmin_username
sysadmin_password
sudo su
sysadmin_password

then 

run the following script

vi enabletoken.sh
# paste the actual "script"  below from the next code block

chmod ugo+x enabletoken.sh

./enabletoken.sh

# enter sysadmin_username
# enter sysadmin_password (it will be obscured/hidden)
# enter username
# have user enter their username_password (it will be obscured/hidden)

# the secure token will be enabled

# we can now run syspref > updates .... it will ask for admin creds... then username password
# it will at least update without a full reformat

# this is obviously a not an ideal solution for a fleet of macs... but if your stuck on one... it's a workaround

The enabletoken.sh below ... NOTE it will update your apfs preboot ... should be safe... but use at your own risk. (we've used this on 50+ computers successfully)

#!/bin/bash

read -p 'Admin Username: ' adminuservar
read -sp 'Admin Password: ' adminpassvar
echo
read -p 'Username: ' uservar
read -sp 'Password: ' passvar
echo
sysadminctl -adminUser $adminuservar -adminPassword $adminpassvar -secureTokenOn $adminuservar -password "$adminpassvar"
sysadminctl -adminUser $adminuservar -adminPassword $adminpassvar -secureTokenOn $uservar -password "$passvar"

sysadminctl interactive -secureTokenStatus $uservar

unset adminuservar
unset adminpassvar
unset uservar
unset passvar

history -c

echo cleared

diskutil apfs listcryptousers /

diskutil apfs UpdatePreboot /

Side note: careful on the "$adminpassvar" and "$passvar" variables in the above script if there are crazy chars in the password you may need single quotes or whatever.

FYI our MDM "download and install updates" command is useless on jamf pro cloud 10.29

Therefore... while we can at least workaround the "BigSur update won't accept password on M1 Machines" ... we still don't have a solid programmatic way to update our fleet.

[wakco]

We are planning on implementing LAPS (Local Administrator Password Solution) in the near future, however it was noticed that the password of the only admin account with a BootStrap/Secure Token cannot be changed. This means to implement LAPS, I needed to change how we are managing admin accounts on our Macs (especially Apple Silicon Macs).

Here is what I have done:

First to be clear, PreStage Enrolment is configured to disable all setup screen tasks after the Remote Management screen.

#!/bin/sh
JAMF_BINARY="/usr/local/bin/jamf"

# Install Rosetta 2 for Apple Silicon Macs. We have a policy scoped to Apple Silicon Macs that
# does /usr/sbin/softwareupdate --install-rosetta --agree-to-license
"$JAMF_BINARY" policy -event InstallRosetta

# Create LAPS admin account, note the password, it can be plain text here because LAPS change it later.
# It should be noted the policy before the script runs resets managed admin account password to the same,
# so we can use it as the second admin account required by BootStrap/Secure Tokens to allow the admin password to change.
# this being the first admin account created, gets a Secure Token and enabled escrowing the BootStrap Token.
"$JAMF_BINARY" createAccount -username lapsadmin -realname "LAPS Admin" -password passwordforscript -home /private/var/uowadmin -shell /bin/zsh -admin -hiddenUser -secureSSH -suppressSetupAssistant

# Escrow the BootStrap Token, at this point I also have a test for if it is a PreStage Enrolment or not,
# I'm only covering PreStage here, so I've skipped it.
 /usr/bin/expect<<EOF
  spawn /usr/bin/profiles install -type bootstraptoken
  expect "Enter the admin user name:"
  send "lapsadmin
"
  expect "Enter the password for user 'uowadmin':"
  send "passwordforscript
"
  expect "profiles: Bootstrap Token escrowed"
EOF

# jamfadmin is the managed admin account, here we activating its secure token.
# Note the use of the same password which will be changed later.
/usr/sbin/sysadminctl -secureTokenOn jamfadmin -password passwordforscript -adminUser lapsadmin -adminPassword passwordforscript

# At this point we can reset passwords, which is when it is time to manage security of those passwords, so for jamfadmin
# we can use a policy to randomise it...
"$JAMF_BINARY" policy -event CycleThePassword

As for lapsadmin I currently have a package that is installed with the password, and use jamf changePassword to reset it's password and then delete what was installed by the package, This step can then either stay or be completely replaced by LAPS when we implement LAPS later.

The important thing here is two admin accounts get activated with Secure Tokens, and the BootStrap Token gets escrowed to the MDM.

If you are wondering about that test, I check if someone is logged in, and we have a policy for IT support staff to create a specific account with a specific password that the script can then use to manage the Secure Tokens, and escrow the BootStrap Token (we are also interested in eventually adding FileVault, as well as LAPS, but one thing at a time). That account is created after resetting the passwords of each admin account, (if we are not already logged into it) and used with DEPNotify to provide further setup screens and ends with Migration Assistant, so user profiles can still be moved. And lastly, as we still bind to AD, I have a policy checking for that account and deleting it, if it is not logged in, Migration Assistant isn't running, and the computer is bound to AD (happens as part of our customised setup screens).

Lastly none of those usernames or password are what I use, this is an example script.

Also fdesetup list -extended provides the same information as diskutil apfs listcryptousers /, however it includes the usernames attached to each UUID.

@ewernicke FYI, it should be diskutil apfs updatePreboot / (I was curious and checked it out and discovered your typo, but otherwise thanks for that I've added it to mine).

[RedWings]

We have this issue on one M1 iMac. The Mac is a test Mac of ours and only has local user accounts and is not yet bound.

[beeboo]

@RedWings our macs arent bound either, we just jamf connect.

while i cant speak to the user's perspective since they all have a token since FV2 is enabled, we had a similar issue for the zoom room mac minis and all I did was use a bit of code from a previous comment

sysadminctl -adminUser $adminuservar -adminPassword $adminpassvar -secureTokenOn $adminuservar -password "$adminpassvar"

it may be different in your case but I know the hidden account credentials and also the zoom room credentials.

Once that policy got kicked off I was able to authenticate for software updates without issues. 

[dugnl]

Having this same issue now with Big Sur 11.5.1 and ARM Macs enrolled in JAMF DEP prestage.  System Preferences, software updates, An update is available for your Mac.  Download it and click Restart Now.   Get prompted Software Update is trying to authenticate user.   Enter user password and immediately get a pop up, some updates could not be installed.  Happening on our fleet of (25ish?) ARM computers.    Secure token is enabled and the bootstrap token is cached on the server.    

Intel Macs don't have this issue at all.   ARM Macs not in JAMF don't have this issue.  I've opened a ticket with Apple Enterprise and JAMF but as of this writing no response.

[ASaldana]

Yes, just reboot in safe mode and the update will run.

[P_Featherstonha]

Safe mode boot will not help non-technical end-users lol - needs to be addressed by Apple I think

[ehstein]

Still no update on this?  Happing to our new M1s.

[JYDP1]

No, not for me, still using the command line for Secure Token. By the way, if you're using password beginning with "-" it wont work.

[EliasG]

The only workaround I have found is when I make the user and admin I run inside terminal command sudo profiles install -type bootstraptoken and that fixes the issue.

[mitof]

This is by far the simplest solution. Thanks! 

[erickj]

So from the user's profile, you:

1.  Make a standard user account into an admin.

2. run in Terminal:  " sudo profiles install -type bootstraptoken " 

, and that fixes the issue where you no longer have the password mismatch?

[mitof]

Yep. That did it for me. 👍