Doesn't accept new admin account password after changing it[BUG]

[RaananZemer]

Doesn't accept new admin user password after changing it saying Error - Password is invalid using older passwords does no work as well

[RaananZemer]

I found a way to bypass this issue I create another Admin account and use it to do the process and it works

[grahampugh]

Please supply logs.

[RaananZemer]

erase-install.log Hi, this issue happened again This is the log

[grahampugh]

Can you explain to me exactly what you did to get this issue? How exactly and when did you change the admin password?

Can you reproduce this when using startosinstall directly?

[RaananZemer]

I got this when I changed the user (admin) password password in 2 ways The first is when I reset it through recovery using a recovery key and immediately after that I installed and ran 'erase-install'.

The second change type was when I pushed for a password change through a JAMF policy - I can log in using that password so it is correct. I ran that policy a few weeks ago. *Even changing the password through the OS settings results in the same error

Running 'startosinstall' seems to be working after entering the password the process began and it updated the OS with no issues

[GabeShack]

Can I ask if this is only on Apple Silicon machines? My guess is it's the same issue we ran into using the JAMF laps feature that auto rotates the admin password. It locks the volume ownership to the original password and prevents updates from functioning correctly unless it's another user that has volume ownership. We got around this by mass changing the admin password back to what it was when it was originally created.

[RaananZemer]

Hi, Most of our fleet has Intel silicon Macbooks so you might be correct. But, this didn't happen for every Mac I formatted and did the same process. In any case, as this is an exception and not the rule I have a workaround. I create another admin account on the device and use it to format.

[grahampugh]

Don't forget this account does not need to be an administrator. But it does need to have a Secure Token. I wonder if your LAPS rotation is not updating the Secure Token? I believe this would be the case if the Jamf LAPS account was created via a PreStage Enrollment, but not if it was created as the Management Account.

[RaananZemer]

Making an admin account makes it easier for me but you are right, it's not necessary Currently, I don't have a LAPS configured for our pre-enrollment admin account

[GabeShack]

Don't forget this account does not need to be an administrator. But it does need to have a Secure Token. I wonder if your LAPS rotation is not updating the Secure Token? I believe this would be the case if the Jamf LAPS account was created via a PreStage Enrollment, but not if it was created as the Management Account.

Yes I believe this was the case for us. Jamf didnt acknowledge the issue, but once I made a script to auto change the laps password back to the originally created password, everything worked as intended. (funny that also while the laps password rotations were happening, other users were also not being granted secure tokens or volume ownership).

[RaananZemer]

I experienced this issue with older computers where the Admin account was the volume owner and had the secure token and I didn't know what the original password was (It was setup by another IT person who changed the password many times). The way I do it now the standard user is the volume owner and has the secure token and I use erase-install with JAMF self-service. Works flawlessly.