Random local account password corruption?

[quip_MDavison]

This issue has literally plagued our environment since we first rolled out JAMF over a year ago and it's driving me so far up the wall.

Seemingly randomly, local accounts will just stop taking the user passwords. It's 110% the correct password, but MacOS insists its wrong. Sometimes it will still let the user account unlock filevault, then tell them their password is wrong for loggin in to the system. Sometimes it happens to our local admin account that we create via JAMF! It's happened on workstations that were enrolled for 6+ months with no issue, and its happened to workstations right after a reboot as part of enrollment.

Sometimes if you log in with an admin account and manually change the password for the affected account it takes it and everything's great. Most of the time MacOS gives a nondescript "password change failed" error and the account is seemingly corrupted forever.

Happens on Catalina, Big Sur, even Mojave. No AD binding or anything like that, just regular old local user accounts.

We just had three more pop up this week right in a row after not seeing it for months, we'll get a couple of these in a wave then nothing for a while before it suddenly comes back at the worst time. Both JAMF support and Apple support haven't been able to figure it out. Has anyone else experienced anything like this?

[quip_MDavison]

Giving this one a bit of a bump for new visibility. Just had this happen to another two workstations in the past week, still no rhyme or reason to it. Even using the Filevault recovery key to reset the password on the login prompt it will change the password, then restart and wont take the new password! Such a mess.

[Espaay]

Hi Folks, we have also experienced this issue. We have JAMF PRO in the cloud our macOS are not joined to AD nor bind. We saw a video from a user sharing their experience. After user types usernamepassword the screen flash's white. Now stuck in a loop, not taking the password, keeps repeating itself. Seems that even the admin accounts were impacted as well.

Local standard accounts created manually, while our admin accounts by design created using JAMF policies to push. 4/19/21 & 4/20/21 in the mornings, we got calls from users telling us their accounts are not allow them to login. This happened to users whose devices were shut down or locked overnight. I explainedshared to others that we didn't make any changes.

We have a password policy: hitting half of the nodes that were affected, not hitting all the nodes in scope of the policy. Sharedexplained on calls with others we don’t have set password history nor password age therefore that tells us this is not the cause. Reason; seems the user account and admin admins not taking the existing password?

Defined below:
Require PasscodeEnforce setting passcode on the computer.
Complex PasscodePasscode cannot contain repeating, ascending, and descending character sequences.
Alphanumeric ValuePasscode must contain at least one letter and one number.
Minimum Passcode LengthSmallest number of passcode characters allowed
Minimum Number of Complex CharactersSmallest number of non-alphanumeric characters allowed
Maximum Grace Period for Computer LockPeriod of inactivity before the passcode is required to unlock the computer
Maximum Number of Failed AttemptsNumber of passcode entry attempts allowed before the computer is locked

Got on a call with JAMF support and shared how we have JAMF defined; via email response they didn't find any root cause as to how we have JAMF set to cause the issue the users are experiencing. None of the steps JAMF support sent worked.

Called Apple support after telling them we have MDM and JAMF tied in they really can’t offer much help; we can pay $$ per device as an Incent to put the device back to out of the box state; which we didn’t want as we wanted to know what caused this issue.

Therefore, internally we agreed add a macOS copy to resolve; it worked.

Unfortunately, this has reverted weeks of work updating devices from 2020 to match 2/9/2021 (19H524) lost as devices are back to the Nov 9, 2020 build 19H15.

[rpayne]

We are also seeing this. We manually create local admin accounts. It seems completely random. We will weeks without it then boom a few in a few.

[bradrod]

We are also experiencing issues with devices not accepting correct passwords at random. Like the people above, they seem to come in waves. We don't bind device to AD and all accounts are local. I have seen the issue first hand and even after resetting the password in recovery mode and rebooting it still accept the password. It accepts the filevault password unlocks the drive and then takes you back to a login screen. Only fix we have found so far is to do an OS reinstall which seems to work, but is very inconvenient. Anyone have any leads as to what might be causing the lockouts?

Also, our password policy doesn't have a password history or age requirement and we haven't modified any of the associated jamf policies in nearly a year.

We have also confirmed from the affected users that they have NOT changed their passwords prior to the lockout issues presenting.

[Espaay]

We haven't heard from anyone as to what is causing the issue. In the past when we were updating the Catalina build Nov 2020 19H15 to Feb 9, 2021, 19H524 within weeks we experienced this. Lucky, we have experienced it anymore. We will stay away from using the 524 build and go straight to 5/24/21 19H1217.

[tlarkin]

Boot into recovery and make sure the user record exists. I have seen a nasty old bug that will remove the local user account (but not delete the home folder) and I have seen on Slack someone else recently ran into this as well. If the user record is still there (check by doing like a dscl . read /Users/user-name) it will output data, if you get a user not found then you may have hit this old bug.