Softwareupdate is trying to authenticate user - Authentication is disabled

[pkleiber]

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

[SCCM]

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

[pkleiber]

Hi @SCCM , thanks for the tip. We don't use config profiles with this setting in our environment.

[junjishimazaki]

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. 

[pkleiber]

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.

[junjishimazaki]

You did this when the mac was hard-wired to ethernet correct?

[pkleiber]

Nope the user was on site with his laptop an we did this via wlan. Is there a difference?

[junjishimazaki]

I would do this hard-wired. Sometimes it needs a physical connection to reauth properly. 

[pkleiber]

@junjishimazakiwe did the unbind and rebind via network cable. Unfortunately it had no effect.

[pkleiber · Accepted solution]

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.

[junjishimazaki]

Great job in troubleshooting. I'm glad you found a solution. Definitely a weird one

[eportillo1]

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.

[jamiesmithJAX]

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

[bwoods]

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

[dugnl]

Thank you.  I think this is gonna help resolve the issue faster for our techs.

Doug

[wwhite36]

Thank you sir. Huge help 

[NeiSpe77]

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!

[aprild]

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.

[dlondon]

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

[aprild]

@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.

[aprild]

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

https://developer.apple.com/wwdc23/10041

[Md]

Hi @pkleiber,

I have tried re-enabling the token, Still facing same issue.

Kindly help on this

Thank you

[pkleiber]

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

[pkleiber]

@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

[dugnl]

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.

[dugnl]

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. 

[red_beard]

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.