Skip to main content

We have one user with a Macbook Pro M1 Laptop. Big Sur is installed on the machine and the logged in user is a Mobile Account and has admin rights. File vault 2 is also enabled.

Deployment was some month ago and everything worked fine. Two days ago the user approached me as he was not able to login with his account credentials at home. He was in the office yesterday and after I logged in with my local admin account everything was fine and he could work. So told him to also to update his Big Sur installation from 11.2.x to the latest version 11.5.2. But as he tried to enter his password the following screen states that Authentication is disabled.

I grabbed this screenshot from the internet cause our dialogue is in German.

Anybody have seen this? Where does this come from and how can we fix this? I would greatly appreciate your help.

Thanks

Writing to say, just experienced this issue running Sequoia 15.2 Beta 3 on an M1 Max MacBook Pro and MacBook Pro M2 running Sonoma 14.2  A small portion of our fleet is still bound. Thankfully most of them are not.

@bwoods script worked great and I utilized Self Service to make it available when our techs need to help other end users. 


Added some osascript to prompt for creds.

#!/bin/bash username=$(osascript -e 'Tell application "System Events" to display dialog "Enter user username:" default answer ""' -e 'text returned of result' 2>/dev/null) password=$(osascript -e 'Tell application "System Events" to display dialog "Enter user password:" with hidden answer default answer ""' -e 'text returned of result' 2>/dev/null) adminUser=$(osascript -e 'Tell application "System Events" to display dialog "Enter admin username:" default answer ""' -e 'text returned of result' 2>/dev/null) adminPassword=$(osascript -e 'Tell application "System Events" to display dialog "Enter admin password:" with hidden answer default answer ""' -e 'text returned of result' 2>/dev/null) #Check if your account has securetoken enabled, (it probably does) # Disable it then reenable it. sysadminctl -secureTokenStatus "$username" sysadminctl -secureTokenOff "$username" -password "$password" -adminUser "$adminUser" -adminPassword "$adminPassword" sysadminctl -secureTokenOn "$username" -password "$password" -adminUser "$adminUser" -adminPassword "$adminPassword" diskutil apfs UpdatePreboot / sysadminctl -secureTokenStatus "$username" exit 0 ## Success exit 1 ## Failure

This worked for me in the past, but today the script worked, but the problem persisted. Has anyone run into that issue? 


This worked for me in the past, but today the script worked, but the problem persisted. Has anyone run into that issue? 


RJ52 and others who this may help: I found that using the interactive switch in the script below is what works on macOS Sequoia in our environment to fix Secure Token for a user. After running script below and signing back in as user, they are able to run macOS updates with no Touch ID errors.

Log in as admin and launch Terminal.

sudo sysadminctl -secureTokenOff <username> -password password interactive

Password prompt in Terminal: input admin password

Pop up authentication window: input admin password

sudo sysadminctl -secureTokenOn <username> -password password interactive

Pop up authentication window: input admin password

diskutil apfs UpdatePreboot /