Posted on 08-26-2021 03:13 AM
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
Solved! Go to Solution.
Posted on 08-27-2021 06:18 AM
I was able to fix the error. It has to do with a corrupt secure token.
I told the user to login with the existing local admin account an then to execute the following script:
#Check if your account has securetoken enabled, (it probably does)
# Disable it then reenable it.
sysadminctl -secureTokenStatus <username>
sysadminctl -secureTokenOff <username> -password - -adminUser <adminusername> -adminPassword -
sysadminctl -secureTokenOn <username> -password - -adminUser <adminusername> -adminPassword -
diskutil apfs UpdatePreboot /
After that I told him to do a reboot.
Everything seems fine now. Logging in offline to his Mobile account also works again.
Posted on 08-26-2021 05:00 AM
Not seen that with the latest update, double check your login window > options / access settings and restrictions > application settings to make sure no ristrictions are enabled by mistake in any config profile
Posted on 08-26-2021 06:44 AM
Hi @SCCM , thanks for the tip. We don't use config profiles with this setting in our environment.
Posted on 08-26-2021 06:41 AM
It looks to me like the computer got kicked off the domain. Have you tried unbinding/re-binding the mac from the domain? Then have the user login again.
Posted on 08-26-2021 06:46 AM
Hi @junjishimazaki , was also my thought too. I did an unbind directly on his laptop then rebooted. After that our binding policy kicked in an automatically did rebind the client. Unfortunately this did not fix the issue.
Posted on 08-26-2021 07:03 AM
You did this when the mac was hard-wired to ethernet correct?
Posted on 08-26-2021 07:20 AM
Nope the user was on site with his laptop an we did this via wlan. Is there a difference?
Posted on 08-26-2021 07:31 AM
I would do this hard-wired. Sometimes it needs a physical connection to reauth properly.
Posted on 08-27-2021 05:32 AM
@junjishimazakiwe did the unbind and rebind via network cable. Unfortunately it had no effect.
Posted on 08-27-2021 06:18 AM
I was able to fix the error. It has to do with a corrupt secure token.
I told the user to login with the existing local admin account an then to execute the following script:
#Check if your account has securetoken enabled, (it probably does)
# Disable it then reenable it.
sysadminctl -secureTokenStatus <username>
sysadminctl -secureTokenOff <username> -password - -adminUser <adminusername> -adminPassword -
sysadminctl -secureTokenOn <username> -password - -adminUser <adminusername> -adminPassword -
diskutil apfs UpdatePreboot /
After that I told him to do a reboot.
Everything seems fine now. Logging in offline to his Mobile account also works again.
Posted on 08-27-2021 06:27 AM
Great job in troubleshooting. I'm glad you found a solution. Definitely a weird one
Posted on 08-22-2022 10:02 AM
Thank you very much for this - it helped fix a similar issue for us. Would you know if it is possible to grant a securetoken to a user that has no password? ie: most of our users are SmartCard only and we cannot get past the "enter password for 'user'" portion unless they have a password. For reference, we bind with directory utility and users login to mobile accounts. 99% of our users have no password.
Posted on 06-08-2023 07:47 AM
is the only way to do this to have someone login locally? Can it be automated at all? I have a remote user who will be a nightmare to walk through this process with over the phone? Trying to avoid a ship the laptop in situation
Posted on 06-20-2023 06:42 PM
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
Posted on 03-12-2024 12:10 PM
Thank you. I think this is gonna help resolve the issue faster for our techs.
Doug
Posted on 06-26-2024 10:39 AM
Thank you sir. Huge help
Posted on 04-03-2023 04:40 PM
I came across this today at my work. A user had updated her OS from Big Sur to Ventura. It broke her securetoken. Thank you for this!
05-02-2023 06:46 AM - edited 05-02-2023 06:47 AM
This solution has fixed the issue for me but it keeps recurring. Anyone else experiencing the secure tokens repeatedly becoming corrupt and having to reset each time there is an OS update? We are bound to AD and use mobile accounts.
Posted on 01-09-2024 07:13 PM
Hi @aprild yes we too have this issue and sounds like our environment is the same. Our machines are bound to AD. Also, we change the AD passwords via a web site, not on the actual machine. We've only seen the problem on Apple Silicon machines.
I finally put a few pieces together in December and realised that it's not a corruption of the Secure Token. The password that Software Update is expecting is the original password that the user had when they first logged in and their Secure Token was created.
I've tested this through multiple password changes now and it consistently fails after the password change but I can use the original password.
It looks to be an issue just for accounts that are AD accounts and where the password is changed elsewhere i.e. not at the machine.
I was not aware of this discussion but was directed to it by our Success Team. I had made a workaround similar to @bwoods for use in Self Service. It seems strange that you can log in with your new AD password and the machine is smart enough to recognise the change in password and prompt to change the keychain password but not fix the Secure Token
Posted on 01-25-2024 07:53 AM
@dlondon I worked this issue with Apple for awhile and was ultimately told that binding to AD is not a model they are going to support in the future and recommended we move to local accounts that care CAC paired if we wanted to ensure secure tokens for our users.
Posted on 01-25-2024 08:02 AM
I should clarify, they didn't specifically say binding was not going to be supported. They said that our model of binding, with mobile users who could perform OS Update actions (thus requiring a good secure token) was not following best practices and they recommend the following:
Recommendations Made:
- Push updates via the MDM vs. using the current workflow.
- Implement macOS Kerberos SSO Extension.
- Review this video which we released today explaining new options you will want to implement.
WWDC23 - What’s new in managing Apple devices.
https://developer.apple.com/wwdc23/10040
-Review the Declarative software update section of this second video.
WDC23 - Explore advances in declarative device management
Posted on 01-17-2024 06:19 PM
Hi @pkleiber,
I have tried re-enabling the token, Still facing same issue.
Kindly help on this
Thank you
Posted on 02-02-2024 08:17 AM
Hi @Md sorry for the late response.
So can you check the status of the secure token holders on the affected machine
To view the current list of volume owners on a Mac computer with Apple silicon, you can run the following command:
sudo diskutil apfs listUsers /
The GUIDs listed in the diskutil command output of type “Local Open Directory User” map back to GeneratedUID attributes of user records in Open Directory. To find a user by GeneratedUID, use the following command:
dscl . -search /Users GeneratedUID <GUID>
You can also use the following command to see usernames and GUIDs together:
sudo fdesetup list -extended
Source: https://support.apple.com/en-gb/guide/deployment/dep24dbdcf9e/web
Posted on 02-02-2024 08:26 AM
@dlondon you should not let users change their password over a website. This will work if the Mac is connected to your active directory for example onsite. But doing this without an active connection to AD will not update the password on the local machine for your secure token. To do this I would propose you use the Apple Kerberos Single Sign-On Extension and let the user change their password when connected via VPN to your Active Directory. We did this before we moved to local accounts.
https://www.apple.com/ca/business/docs/site/Kerberos_Single_Sign_on_Extension_User_Guide.pdf
03-12-2024 11:11 AM - edited 03-12-2024 12:12 PM
It's not up to some of us whether folks use a website or not. That's the system for password changes and preferred method put in place by this University. I could just as easily say folks shouldn't use local accounts (which happens to be my own opinion but that's mainly because I've never seen them managed before). At least with an AD or Azure joined environment, there is some control over people's passwords and when they change it through those type systems.
But apparently Apple wants to get away from mobile/domain joined and go with either local or third party authentication. I've got JAMF Connect on some systems and those don't have this issue. The accounts for those aren't mobile.
Posted on 03-12-2024 11:08 AM
I opened a ticket with Apple. They are aware of this issue. They however are going to do nothing about it.
Hi Doug,
I received a response from engineering with clarification about the expected behavior when changing passwords (away from the Mac) for mobile AD accounts. If you change the password (away from the Mac) for a mobile AD account, OpenDirectory cannot automatically sync the secure token password with the AD password because updating the secure token requires entering both the old and the new password. The old password is not stored in cleartext, so it cannot be read from a cached record on the Mac.
If FileVault is enabled, the user can reboot and they will be prompted for the old AD password to unlock the disk and then for the new password at the regular login screen. This process will sync the login password for the mobile account and also sync the SecureToken password to the new AD password.
If you don't have FileVault enabled (when changing mobile AD passwords away from the Mac), there is no mechanism to automatically update the the SecureToken password and you would need to update the SecureToken password manually with sysadminctl. This is expected behavior. Please let me know if you have any questions regarding this information.
2 weeks ago
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.
yesterday
I can't get formatting to work properly in this post. My apologies. Feel free to edit if you can get it to work properly.
If a Mac user ever gets this error, you may have a corrupted secure token. If the secure token is corrupted, the user will receive this error whether they are an admin or not.
I believe this error occurs when a user changes their domain password and the Mac does not sync up with your domains servers. This usually happens when the user changes their password outside of your domain's reach. My theory is that secure token is waiting for confirmation of the old domain password but the domain is waiting for confirmation of the new password, or something like that. Regardless of how it happens, secure token has a different idea of what the current password is than what it actually is.
**NOTE**
This only occurs on Macs that have been added to AD.
To reduce complication and mis-interpreting, I will be using colby.jones as the affected user, and TestAdmin as the local admin.
Be very mindful of spacing and case sensitivity.
To fix the issue:
Helpful Links:
https://ss64.com/mac/sysadminctl.html
https://community.jamf.com/t5/jamf-pro/softwareupdate-is-trying-to-authenticate-user-authentication-...
https://community.jamf.com/t5/jamf-pro/unable-to-remove-secure-token-from-a-user/m-p/297020