Password Policy profile disables user account

A bit more background:

• The Password Policy payload sets maximum number of failed attempts, as well as minimum requirements for length and complexity.
• Prior to the initial enrollment, the two user accounts had passwords that didn't meet the criteria of the policy, and were prompted to be reset on first login after enrollment.
• Because of this issue, I ended up removing the MDM profiles (via the JSS), and resetting the passwords to meet the criteria, then re-enrolling.

Anything else I'm forgetting?

Are you encrypting your machines as well? I've been troubleshooting this issue in my environment and all indications of lockout point to FV2 not syncing the password properly which locks the user account out in certain scenarios.

https://jamfnation.jamfsoftware.com/discussion.html?id=11120

Yes, we're using FV2. I suspect the initial error occurs when trying to update the passwords while syncing with the FV2 pw. FWIW: all users are local. We don't have AD or any directory service.

Interestingly, when the problem is occurring, the user can get past the FV2 prompt, but then gets to the login screen and receives the error. When the MDM profile is removed, they get the FV2 prompt, login and go straight to the desktop.

This implies to me that the FV2 pw and user pw are correctly in sync, but that the failedpasswordattempt part of the policy is somehow not getting cleared or reset.

@emax: what version of the OS are you running? There is a bug that causes this issue in Yosemite when the passcode policy has the 'minutesUntilFailedLoginReset' and/or 'maxFailedAttempts' keys configured. When the configuration profile is applied, the count for maxFailedAttempts increases by 2 (no idea why) upon each reboot, and depending on that setting will disable accounts on the system. We had to remove those keys in order to apply a passcode policy via a configuration profile.

If you are able to log in with the admin account, you can see the values of maxFailedAttempts by using dscl:

/usr/bin/dscl . -readpl /Users/<affectedUser> accountPolicyData failedLoginCount

@dbrodjieski : What you're describing sounds like exactly what we're experiencing! Is there a JN thread on this or Apple KB with more details? This machine is 10.10.5 (when the first enrollment happened, it was at 10.10.3, I believe; I removed MDM, updated to 10.10.5 in hopes of some magic).

Will going to 10.11 resolve this?

Right now the user is functioning since the password policy is scoped to excluded her machine.

So a couple of questions for you:

• Do you have a separate passcode policy scoped for 10.10 machines, or have you simply given up on trying to enforce maximum number of failed attempts and/or delay after failed login attempts?
• How do I go about resetting the users failedLoginCount value?

@emax: I have not seen any discussions on JN that talk about this issue, and the only thing I have from Apple is a bug report that we filed back when this first affected us. Good news is that 10.11 addresses the issue, but it's doubtful that Yosemite will see an update to fix it.

We have decided to remove the offending options from our passcode policy (maxFailedAttempts and minutesUntilFailedLoginReset) as we rely on our directory service to lock out accounts if needed. We use smart cards as well, which adds a layer of complexity to the mix, but lessens the need for the passcode policy. We also limit the use of local accounts to hidden emergency administrator accounts. We rotate those passwords regularly, and restrict who has that information. I know it's not the best solution, but it has been working for now. Going to 10.11 is going to help a lot!

You can reset the users failedLoginCount value by just deleting the entry altogether. However, after subsequent reboots, the account could get locked out again. Setting the failedLoginCount to a higher value should buy you some time, and you could have a launch daemon clear those values upon reboot (but kind of defeats the intent of the setting).

/usr/bin/dscl . -deletepl /Users/<affecteduser> accountPolicyData failedLoginCount

Hello,

We still have the issue with Sierra ...

So I did the same and disable the policy to lock the account after 10 wrong password.
But I still have users who get lock.

Is there a command to see the value on the mac and know when it's should be lock?

Also having the same issue with Sierra. Upgrade goes through, device reboots, user prompted for FV2 password, disk unlocks, device begins to boot, user presented with login and password window. Account locked out.

We are having to get users to boot into recovery mode, unlock their disks with the FV password in disk utility and then reset their own user password via terminal

Logged a call with Apple Care Enterprise, they have advised to remove any password policies from Jamf and test again - in the process of working through this

Weirdly, users randomly get locked out as well where the above happens... FV OK but login halted with login prompts (password protected screen saver initiates and then users come back to being locked out)

The account lockout issue still persist in Mojave and Catalina as well.
Unable to do a root cause analysis as there is no trend seen, it’s just random.
Any help with this issue is really appreciated.
JAMF support was of no help pertaining to this issue.

We had been baffled by this and it also lock out via FV.
We had to login via the recovery key
Cancel the reset password for the user
login as other and our hidden admin account
run the below

/usr/bin/dscl . -deletepl /Users/<affecteduser> accountPolicyData failedLoginCount

Then switch user or run login username in terminal to test.
Then a reboot to check FV and all was ok

You may need to reset the users password if they have no idea what it was. I found the reset after putting in the recovery key at FV worked. Using dscl . passwd didn't work for me..

Hope that helps someone

+1 Here. About 20-30% of the time if a user tries to change their password, they are immediately locked out of the device.

We use FV2 with a disk encryption config in JamF that has both an institutional and individual recovery key. We've considered going to an institutional only key, but as a remote company if somebody gets locked out fully, that individual recovery key is the only way we can get them into their computer, so we haven't had the courage to experiment with this.

The resolution we have found works is that we push an unlock of the local user account from the computer management record.

At its root, what appears to be the cause is that a password change properly changes the user record but the FV2 password does not get updated until after a successful login.

Because a password change results in the user now having two passwords (the old one which they have to use for the FV2 unlock) and the new one, the user invariably tries their new password a few times on the FV2 unlock screen. FV2 failed attempts increment the failedLoginCount.

We're CIS1&2 compliant so we have a failedLoginCount max of 3.

Sadly this appears to be an Apple problem not a JamF problem.

We found a Stack Overflow article that correctly describes the behavior:

Just bumped into this issue too, if you change password via Settings > Users & Groups > Change Password ... you will be prompted twice, once for the File Vault original password and again for the new account password. However if you change the password via Settings > Security & Privacy > Change Password ... both will be updated, noting that you will be required to enter the account password not the File Vault original password, so you can reset the Filevault password by entering your new password three times.

We're evaluating creating our own dialogs to prompt a password change and then using bash to change both passwords simultaneously.

Very frustrating that core functionality around password changes has been broken in OS X for 5 years.