Softwareupdate is trying to authenticate user - Authentication is disabled

pkleiber
Contributor

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.

Authentication is disabled.png

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

1 ACCEPTED SOLUTION

pkleiber
Contributor

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.

View solution in original post

27 REPLIES 27

SCCM
Contributor III

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

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

junjishimazaki
Valued Contributor

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. 

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.

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

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

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

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

pkleiber
Contributor

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.

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

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.

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
Valued Contributor

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

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

Doug

wwhite36
New Contributor II

Thank you sir. Huge help 

NeiSpe77
New Contributor III

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
New Contributor III

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
Valued Contributor

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
New Contributor III

@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
New Contributor III

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
New Contributor

Hi @pkleiber,

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

Kindly help on this

Thank you

pkleiber
Contributor

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
Contributor

@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

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
Contributor

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
New Contributor III

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. 

ColbyJones
Visitor

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.  

ColbyJones_0-1734044962521.png

 

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: 

  1. Open a Terminal window while logged into a local admin account.  

 

  1. I recommend making a new local admin account that's not your IT's account, because there will be passwords in plaintext on screen. Both the user's and the admin's password will be in plaintext on screen. I handle this by making a separate local admin with a simple user friendly password.  

 

  1. In Terminal, type  
     
    1. sysadminctl -secureTokenStatus colby.jones 
     
    1. This command checks what the secure token status is. If the secure token status returns as Enabled, move on to the next step. If the secure token status returns as Disabled, move on to the step after next.
     
    1. If you can't find the actual username of the affected user, go to system preferences, users and groups, hold control, and click on the affected user. Click advanced and it will show the username. 

  

  1. sysadminctl -secureTokenOff colby.jones -password WRITEPASSHERE -adminUser TestAdmin -adminPassword WRITEADMINPASSHERE 

 

  1. This command turns secure token off. We want to turn secure token off to clear the garbage password out of there.  

 

  1. Entirely replace colby.jones with the affected user's username and WRITEPASSHERE with the affected user's password. I hate plain text passwords as much as the next guy, but I can't find a way around it. I will type this whole command out with the user friendly local admins password and then leave the user to type their password in.  

 

  1. IMPORTANT NOTE – Some users may have characters in their password that terminal may interpret as a command. For example, someone had !ZbW in their password, and Terminal kept reporting that that command was not found, rather than completing the secure token off command. You can bypass this by surrounding the entire password in single quotes.  

 

  1. Entirely replace TestAdmin with the local admin's username that you are currently signed in to as well as WRITEADMINPASSHERE with the local admin's password that you are currently signed in to. 

 

  1. sysadminctl -secureTokenOn colby.jones -password WRITEPASSHERE -adminUser TestAdmin -adminPassword WRITEADMINPASSHERE 

 

  1. This command is practically exactly the same as the last, with the only difference being –secureTokenOn instead of –secureTokenOff. This of course turns secure token back on, populating secure token with the new, actual domain password and getting rid of all of our authentication issues. 

 

  1. diskutil apfs updatePreboot / 

 

  1. Not specifically sure what this command does in relation to this process, but it does not work if you do not run this command last. If you need to know what it does for whatever reason, I found this. 

 

  1. diskutil apfs updatePreboot takes an argument for the volume device (e.g. disk5s1) with further options given in its usage information. This will “examine the given APFS Volume for macOS and Open Directory (OD) database files, correlate the Volume’s APFS crypt(o) users with OD users, and update the related Preboot Role Volume’s Subject Directory with data such as EFI login graphics. Specifying “/” for its overrideODFullPath option will use /var/db/dslocal/nodes/Default. No crypt(o) passdata is needed, but ownership of the affected disks is required.” 

 

  1. Please be mindful of the space between updatePreboot and /. It will not work if you do not include a space. 
  1. Restart the Mac.  

 

  1. After restarting, the affected user should be able to log in and use their mac without running into that authentication error anymore. If the issue still persists, try removing the Mac from AD (be very sure that the user has a mobile account first) and reinstating the device.  

 

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 

https://eclecticlight.co/2024/04/22/apfs-command-tools/