We have been seeing a similar issue, but it appears in a few different ways.

In some cases I can unlock the users account in JAMF through the account management section like you tried.

Other times we have to have them sign in with the Bitlocker recovery key.

And other times it seems to resolve if you hold the power button down to shut down, then start up again normally and the old password seems to work.

We have InTune also.

Have not found a cause. We notice that it seems to happen in waves of a few machines at a time, then nothing for a while.

This was also happening in Catalina.

I have run into similar issues on Catalina with users on local accounts. I have not been able to completely narrow down what causes it to happen. But it does appear to be related to the password policy config profile deployed, because on several systems after removing that config profile shortly after they were able to login in again. It doesn’t make sense since the password policy is deployed to 200 systems but only 5 or 6 users have run into this issue. I am wondering if it’s related to software updates being installed that need reboots/shutdowns and on start up don’t auto login properly or something?

I tried looking into the "locked" aspect a bit and the only thing I can find that relates on the JAMF side is the password policy section that mentions locking the account after x number of failed password attempts. But it doesn't appear that all of the cases are due to bad password entries. I was trying to see if there is something that may be attempting to enter a bad or null password multiple times automatically (like the keychain might do), and then locking out the account, unknown to the user and without their interaction.

I tried looking through logs and did not find anything conclusive.

If it's a password policy, it's proving difficult to track down. There isn't one in Jamf, so the only thing I can think is a possible policy being pushed from our InTune configuration, but I'm told no password policy is enforced there either. At this point, I'm wondering if renaming / retiring the profile and recreating it will work, but since it's linked to AD, I'm not sure how that will fly.

Still an issue

We are seeing this in our Organization. So far just two Macs (Knock,Knock)
One mac running 10.15.7
One just upgraded to 11.3.1
We do not have a password policy config profile that we deploy to our MacBooks

![optional image ALT text](

)

I don't suppose there is some way to disable the lockout all together?

I ran also in this Problem today - easiest fix for me was to convert the mobile account into a local account. Just delete the mobile account (don't delete his home folder) - rename the home folder to "whateverYouLike" and then create a new account with the "whateverYouLike" name and it takes over the home folder. Mobile accounts are just bad - but in the other hand the new local account isnt mdm-enabled so it doesn't get any user profiles (also not good in our environment).

Tried to turn off the secureToken for mobile account and turn on. Recently I faced that issue and got resolved after re-enabled the secureTokenOn for Mobile account on Mac running on BigSur.

sysadminctl interactive -secureTokenOff username -password -
sysadminctl interactive -secureTokenOn username -password -

have had this issue also, the Fastest way to resolve this i have found is the below. Works every time. and no DATA lost.

Removed User account, But kept the Home Directory the same.

Logged in as the users Network account to create this as new Account on the machine.

created mobile account.

then changed the new accounts Directory to then point to the old one.

Hello All, 

Jamftechelp's solution is working great. But I have more and more Mac users in my company who come to me for this issue, each time they change their password via their Outlook Web Access platform. 

Do you know how to face this ?

We are coming to a MDM solution, but not yet in place.

thanks

Anyone have any new info on this? Still seeing it in my org.

have had this issue also, the Fastest way to resolve this i have found is the below. Works every time. and no DATA lost.

Removed User account, But kept the Home Directory the same.

Logged in as the users Network account to create this as new Account on the machine.

created mobile account.

then changed the new accounts Directory to then point to the old one.

This seems to be the best way around it, I have found and the fastest

check my post above 🙂

Ran into this issue today with a user. Bound to AD, no local password policy/profile, upgraded from Catalina to Big Sur 11.6.2.
Turning secureToken off and on again fixed the issue.
Thank you!

Now that I've encountered this more frequently, I want to provide an update on what we're seeing with this issue.

While @andrewfaircloug's solution of deleting and re-creating the account does work, it's almost impossible to implement if you have AD-bound macs and remote workers, as it's difficult to get a VPN connection working at the login screen. Heck, I have enough trouble getting on-prem Macs to allow network account login. But I digress...

I've successfully used @Jamftechelp's solution of removing and re-adding secure token to resolve this issue with remote users. Although I often have to fiddle with the exact structure of the command; I can't seem to nail down something that works perfectly reliably.

Still no new insights on how to prevent this issue, but I haven't seen any new instances of it in a while. Now if Apple can just the new binding issue we'll be ok...for now!

I have this same issue. We have MS AD and the mobile account shows locked but not locked in AD just the mobile account on the BigSur Mac. I can login as an admin local account connect to our network via VPN. I leave it connected to VPN, log out of the admin local account then I can log back in as my user AD account.

Hi All, this issue has come up a number of times in my org. After some begrudging fixes via user account deletion/home folder saving, or straight up re-image/Jamf re-enrollment, I finally stumbled upon a possible fix. 

Basically, I used the local admin account to disable and re-enable the target user account's Secure Token via Terminal, all while directly connected to the corp network, (haven't tried this over VPN, but it should work as well):

sysadminctl -secureTokenStatus targetusername

If it states that the Secure Token is ENABLED for the affected account, then move onto the next command. If it states it’s DISABLED, then skip to the last command below.

sysadminctl -secureTokenOff targetusername -password (enter targetusername password) interactive

(Interactive flag will bring up a login box for authentication by the other local admin account; enter that acct password)

You should then get confirmation in terminal that the Secure Token has been DISABLED for the target user's account. If so, then run:

sysadminctl -secureTokenOn targetusername -password (enter targetusername's password) interactive

(Interactive flag will bring up a login box for authentication by the other local admin account; enter that acct password)

You should then get confirmation in terminal that the Secure Token has been ENABLED.

If all goes well, reboot and attempt to log into the affected user's account. If not, then I hope I didn't waste too much of your time