1

Edit for conciseness:

Macbook Pro Intel T2 from 2018, latest available MacOs 14.

2 Accounts existing, both admin.

My primary account has recently been changed from restricted to admin. This is not confirmed temporally related to the problem. After reboot one of the accounts can't be logged in. Only after another user was logged in first, I can use the password to login the primary account.

I thought it was related to Filevault. But even with Filevault off, it behaves the same.

Machine has never seen any MDM or special fiddling with user properties. No Icloud connected.

Changing the users password does not have any effect in this.

Newly created accounts do not have this issue. Only this one account.

Testing this is time consuming because of the imo very aggressive ratelimiter. Occasionally even on a reboot after a logged in session of the primary user, will that user be locked from anything from 15min to over an hour. Without even inputting a wrong password once.

What could be wrong with the account? How could I fix this without migrating to a new account.

Edit: Will copying the directories to a new user with same uid and name port everything? What about keyring, wifi credentials, vpn, dev certificates?

Yet another edit: A Yubikey was paired with the account. After unpairing it, reboot and the whole yadda. I had yet again got a 15 min wait until I could try entering the password. And then it actually worked.

Then I turned Filevault back on. And it does not work anymore.

Frustration 100

Old:

My Macbook suddenly stopped accepting my account password to first unlock the machine from filevault. Another account still works to unlock filevault. After unlocking filevault I can login to that user with the correct password. After login I tried changing the password. The correct password was accepted as correct password. It still won't unlock on fresh boot with the correct password. Now I had a ratelimit of half a day. It seems the filevault ratelimiter never got reset. Even tho I logged in using another account. So after FV unlock, pw works. Before FV unlock, pw does not work. Turning Filevault off and on again to rebuild the key wrangling machines' derivation data from the password again did not work. Changing the password because maybe just on/off doesn't rebuild the key derivation data did not work. I have got another account lock for quite a time again. Even with Filevault disabled, first login after reboot does not work with the weird user. I also never did any MDM like stuff nor manully screwed around with policy settings. The only thing special about the account is, that it was once restricted user and was upgraded to admin recently. I can't tell if the problem happened at the exact time of changing that. After last login with FV off after logging in to the working user, even tho not once failing input during that boot, the weird account still had a 15 min block on it before I could try. Even tho I rebooted from a logged in session of that account. What do?

Improve this question

1 Answer 1

Reset to default
1

This could go on for days, trying to track down some strange corruption in the user database (which I suspect was somehow caused by the Yubikey.) What I would do in your place, since newly-created users seem to be OK, is to create one with all the bad user's files. It's been years since I tried to do something like this and TCC will be something of a minefield. The easiest way would be to delete the problem user but preserve the home folder. Then create a new user with the same (short) name. If you're lucky, the new user will have the same numerical ID as the old one, and everything will just work. If not, you'll have to change the numerical ID of the new user, which you can do in the Directory Services application.

You must have good backups of all data before attempting this. Above all, do not delete your only admin account.

Improve this answer
17
  • To be prepared: Turning Filevault off is a policy only thing that does not need to decrypt the whole drive for half a day? Because its somehow always encrypted and some controller does store the key anyways? Commented Dec 15, 2024 at 7:42
  • No dice with FV on/off. Same thing happens. Commented Dec 15, 2024 at 17:06
  • So starting with FV off, you enable it and then are immediately unable to unlock it as the same user? How is the Yubikey involved in this? Commented Dec 15, 2024 at 17:53
  • FV on, reboot, login to working account after boot works. FV on, reboot, login to weird account after boot doesn't work, incurs high lock period on firyt try. I can't use the Yubikey for FV unlock. FV on, login after boot into working account, then logout and login to weird account using yubikey works. FV on, login after boot into working account, then logout and login to weird account using password works. The mentioning of the yubikey came from the last sentence not working but me unsure, because I may have typoed and could not check again often due to the aggressive ratelimit. Commented Dec 15, 2024 at 19:17
  • Thats why the yubi was the safer bet because its pin does not count agaibst the ratelimit but the yubis own ratelimit. Commented Dec 15, 2024 at 19:17

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.