Newer Jamf Pro user here. We've got about 230 devices enrolled, 98% of which are existing machines from the field (mostly remote) that we're using user-initiated enrollment for.
We're doing pretty basic stuff, installing a few apps, issuing a password policy, and things like login screen message etc. One these machines, there is a local admin for our use, and the user is also a local admin.
We've had two instances recently where, a user has rebooted, done the user-initiated enrollment, and then upon rebooting, is asked to change their password at login to comply with the password policy, and then the next time they try to login after this, they are told their password is wrong.
I'm finding the same issue with the local admin, and the only way I can get in is if I push a new local admin account to the machine via a policy. But after I login, if I go to users & groups in sys prefs/settings, and I try to reset the password, I get "reset password failed."
We are not using FileVault, but have a policy to escrow the key if the user already had it enabled.
What is causing this? I've seen it on Monterey and Ventura, and all users so far are using M1 Air. I am trying to find a way to get these users back into their accounts and make sure to prevent this for future users.
For the password change thing, if the user has FV enabled you will need the old password to get into the device at least one reboot cycle. If the device is FV enabled before management you will need to tell the machine to reissue the FV key for escrow, it won't magically send it to you without doing that - there is a script to handle that. I would suggest that you do not push a password complexity profile until the machines are all onboarded and you have a good inventory of who is encrypted and who is not and then push some password policy changes, if you do it all at once you can have trouble pin pointing what caused this issue. For the machines you are getting the password error on, were they bound to AD at some point? if so you will need to demobilize the account before it can have the PW changed. Another thing you can check is what user has secure token as that can be playing into this equation.
Thank you for your response. As far as I can tell, these two users didn't have FileVault enabled, but honestly I don't know for sure. I will look at the script you shared, thanks for that. The most recent user this happened to, they enrolled, rebooted, were prompted to change password, and then later the computer woke from sleep and they were asked to login, and neither the new or old password worked. Even more odd, our local admin account which had been there prior wouldn't take the admin password, or the new one we tried to push from Jamf.
I think it is a good idea to probably remove the password complexity, or just have it setup for those that are coming through as pre-stage enrolled.
The machines were never bound to AD, they were issued new, only with a local admin of our own and then we'd create the user an account. It was the Wild West which is why we're trying to now inventory them all with Jamf to be able to enforce things.
Update on this:
The second user, who was on Monterey, we were able to use the fdesetup command in terminal after logging in as a local admin, and disable the user as "FileVault enabled", for some reason, this allowed us to then reset the user's password in users & groups.