Posted on 12-23-2020 10:57 AM
We recently started our Big Sur pilot program so I lifted the upgrade restriction for a handful of my users. One of my users, after performing the upgrade via Software Update, is facing an issue where his AD-joined account is saying "Your account is locked" when trying to log in. He has 3 other local accounts on the machine that he can log into, but no luck with his main account.
The laptop is (was) domain bound and the account is a mobile admin account. The other accounts are local admins, so that is a difference.
I've tried an SMC reset, force unbinding the laptop, creating a new (post-upgrade) local admin account (per another forum). After these steps, attempts to switch user or use the Login window appear to authenticate, but then revert to the previous screen (either the previous user's desktop, or the Login window). Eventually the "Your account is locked" message returns. I tried sending the Unlock command via the account management section of Jamf. That appeared to do nothing.
I've read in other forums that it may be related to a password policy enforced via InTune (which we use for machine compliance) or a config policy in Jamf (which I haven't utilized). Although that makes me think I would see it on more than just one of the 12 pilot users. The next step I was thinking would be to convert it from a Mobile account, but that may be much more of a hassle than I'm anticipating, so I thought I'd post here to see if anyone else has come across this. TIA.
Posted on 12-23-2020 03:17 PM
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.
Posted on 12-23-2020 03:17 PM
This was also happening in Catalina.
Posted on 12-27-2020 01:08 PM
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?
Posted on 12-28-2020 12:30 PM
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.
Posted on 12-29-2020 10:07 AM
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.
Posted on 04-29-2021 03:06 PM
Still an issue
Posted on 05-11-2021 11:25 AM
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](
)
Posted on 06-16-2021 07:46 AM
I don't suppose there is some way to disable the lockout all together?
Posted on 06-16-2021 07:53 AM
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).
Posted on 07-01-2021 01:23 AM
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 -
Posted on 01-20-2022 02:52 PM
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!
Posted on 08-04-2021 03:54 AM
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.
Posted on 11-19-2021 12:27 AM
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
Posted on 12-13-2021 04:37 AM
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
Posted on 12-06-2021 02:03 PM
Anyone have any new info on this? Still seeing it in my org.
Posted on 12-13-2021 04:38 AM
check my post above 🙂
Posted on 02-22-2022 11:11 AM
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!
Posted on 04-08-2022 03:29 PM
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.
Posted on 05-04-2022 04:31 PM
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