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?
@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.
@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.
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?
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.
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
Big Sur / M1 / Silicon
This is how we get a SecureToken for users who don't have it.
- 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.
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 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.
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.