Admin password not working for Ventura updates on m1 Macs

[nkreeger]

When attempting to run software update on M1 macs currently at 13.0 or above, the admin password is not accepted.

End users do not have admin rights on our machines.  The same admin account is on every mac, both Intel and Silicon.  The admin password works all around except for updating Ventura.

Currently, we have machines on 13.0, 13.1, and 13.2.  When end users run the 13.2.1 update from Software Update they are prompted for admin credentials.  If I enter the local admin password it shakes like it is incorrect even though the same password works for other things that need elevation.  This only happens on the Silicon macs.

I have read other threads talking about erase install script for updating from Monterey to Ventura but we have no issues with that process.  We only have issues for machines already running Ventura and needing to do a supplemental update like 13.2 or 13.2.1.

Can anyone provide some insight?

[Utilizator]

Do you have any password policy applied to the admin account? If the account password has expired then you'll need to change it before you can use it.

[AJPinto]

Have you made sure your admin account has a Secure Token? On Apple Silicon, OS updates cannot be installed with a bootstrap token (admin access), they must be installed with a Secure Token holder.

You can run this command to see if you have a secure token. If you don't have a Secure Token, that is your problem.

sysadminctl -secureTokenStatus {account name without brackets}

Use secure token, bootstrap token, and volume ownership in deployments - Apple Support

I strongly suggest using JAMF to issue the updates. If you have your Macs managed correctly, JAMF should have a Secure Token to tell the Macs to install OS updates.

macOS Upgrades and Updates Using a Mass Action Command - Deploying macOS Upgrades and Updates with J...

[macservit]

Sorry for digging up an old thread, but we're dealing with the same issue. On new Apple Silicon machines, we're allowing the user to unbox and go through setup assistant, effectively taking on volume ownership and also grabbing the a secure token. We're adding our own admin later on via Jamf policy (create local account). What's odd is that it's the original user who cannot run Ventura updates. Our Policy-created user has no issues updating the OS. All other admin functions work as expected for the original user. Obviously this is a volume ownership issue. Is it possible that Jamf somehow removed volume ownership as a side effect of a policy?