Big Sur M1 Mac + Filevailt 2 - Admin user = Big problems

[hkabik]

After configuring our first M1 machine we ended up with the attached error. "Recovery is trying to change system setting. No Administrator was found."

This happened after a reboot in which some system and kernel extensions were installed by policy and approved via config profile. Our machines have local admin accounts, but only the user account is FV2 capable and they are not an admin. That appears to be the crux of the issue.

Sadly I can't troubleshoot further because once you get this error, the only option is to erase/restore. And I was getting this error: https://support.apple.com/en-us/HT211983

and while I was able to restore it via the configurator approach yesterday, I cannot today because the boot key command will no longer get the machine into revive mode and recognized by configurator. Apple support is stumped and is just sending me a new machine... they believe this one is just bricked. I restored it probably 4-5 times yesterday. today it's a paperweight that can't install an os.

So... has anyone else seen this "No Admin" error? Any solutions I should attempt once I get my replacement M! machine? Need to look into reworking our workflow so our admin account is also a FV2 user?

Mostly I want to direct attention to both this "no admin" error's existence and just how absurdly easy it is to brick these M1s apparently. Tread carefully, but also be aware Apple is swapping these out pretty readily if you do.

[vailster-cc]

+1 for also getting this error in the same situation!

[hkabik]

So the “No Admins” issue on M1 Macs. It appears it is in direct relation to having a config profile approving kernel extensions on a machine where the only FV2 user is a non admin. If I do not include an config profile to approve the KEXTs then all is well, but if I add the config profile that whitelists them then on the next reboot I am kicked into recovery mode and get the error. no way out but revive/restore. If there IS an admin FV2 user they can then authenticate the change in recovery mode. but per https://support.apple.com/en-gb/HT211860#silicon that should not be the case. As my equipment is configured via automated device enrollment then the config profile should automatically approve the KEXTs without manual intervention.

[Phantom5]

I would stay away from kexts in Big Sur and M1 Macs. We are experiencing a lot of kernel panics with sec agents that still use kernel extensions in Big Sur to the point that we even have to reinstall macOS. I imagine Rosetta 2 is not going to provide the compatibility that some kernel extensions need.

[hkabik]

Indeed, I've simply disabled all of those profiles and the problem has ceased to be. But this still goes against the data that apple has put forward in https://support.apple.com/en-gb/HT211860#silicon, so I want to let people know if I can in advance.

[Wakko]

So I just ran into this issue. I've been using my machine for about a week and 1/2. No errors no issues what so ever. It' funny that that we are getting this error at the "same time". Now to be clear I have reboot my machine several times before this has happen. So what did Apple push that might've cause this. Everything was working fine, same setup similar to yours. This is no bueno at all. If I find any information that might help us out on this issue I will past it along.

Update:
AppleCare support was , well we all know how I'm going to end that sentence. Needless to say this link helped me bring back my machine. For me step 5 worked, sure it took longer but it was a clean nuke & pave. Hopefully this will help out other admins that run into this issue.

[dywane]

HI! I have seen this error before. I my case, the user booted to the optoin screen, navigaed to Disc Utility and erased the drive, and then tried re installing the OS from the Utilites menue. It was during the install process that mac produced the error "No Administrator was found."

[hkabik]

Please anyone who gets this, reach out to Apple enterprise support. My issue was escalated to engineering yesterday and they specifically said they are on the lookout for more instances of this error.

[kevin_v]

What version of Jamf Pro are you running?

[hkabik]

10.26

[daniel_blohm]

Just a thought without testing (still waiting for the first M1).
I just stumbled upon this:

In my understanding, if "Allow standard users" is checked the machine would not need an admin to approve the extension. Maybe you can circumvent the problem this way?

Regards
Daniel

[matthias_bretz]

Did you try to recover the M1 mac in DFU-Mode? Had to do this last week as any other attempt did not bring him back to life.

Another tidbit: my Jamf server just failed to install my profile with approved kernel extensions. So I made a smart group for all macOS 11.X (and newer) computers and excluded this in scope of my kernel extension profile to get rid of the failed installs in Jamf.

[jgaitherccu]

Just got off a chat with Apple Support and this worked for me: https://support.apple.com/en-us/HT211983

Specifically Steps 1-9 under Prepare Your Mac. For some reason wiping it from resetpassword in Terminal made the difference and we were able to reinstall the OS after that.

[hkabik]

The "Allow standard users" option for legacy KEXTS doesn't change the outcome. You still are booted to recovery and get the "no admin" message.

Only option to get back into the os is a wipe restore at that point.

[Wakko]

@hkabik I just got a call back from Apple. Engineering is call a few questions that I"m just gonna copy and paste from JAMF. This is something that they "seem to be aware of". I basically also told then if they need more info that they should basically give us machines to test. Since this is finished and paid for product, why should I spend time beta testing it for them. This is starting to not feel like a finish product and if so then it should be full price. Time = $, $= time in IT simple equation.

[lassekivikas]

In my case, I had this exact same problem. I got through first boot that was automatic after jamf enrollment, but the next one got me the same "Recovery is trying to change system setting. No Administrator was found." error. I also had Kexts deployed from Jamf, but removing them didn't do anything.

What I found out, is that the first authenticated account got the SecureToken but we create hidden admin account in prestage enrollment, and that hidden account doesn't get SecureToken before you sign in with it. I checked it with sudo sysadminctl -secureTokenStatus username. After signing in and checking that both accounts have the SecureToken, I got through the boot normally.
For the reference, I am using Jamf Pro 10.26.

[kmathern]

I am having the issue as well. I'll follow this thread and hopefully Apple fixes this.

[tjosey]

We are running into the same issue here. We recently have received 10 M1 Mac Book Airs and we actually tested out one of them and now its bricked on the same Recovery is trying to change system settings. We do have a hidden admin account automatically created during preinstallation. We will call apple to to escalate and hopefully get a new Mac

[maurits-pro]

@hkabik Can you give us more details on which kernel extension you are using?

Here is my line of thought on your issue: There can be two limitations: - macOS 11 has deprecated any kernel extension, but can run if (see below)
- any extension (system and kernel) should be designed for Apple Silicon

What I read in documentation : macOS 11 can support kernel extensions, IF approved by MDM, BUT if the extension is designed some older way ('deprecated KPI' as mentioned in HT211860' ) need 'approval' , which would not surprise me if that approval requires admin rights. (this line: You can use MDM to modify default policies to not show dialogues periodically and to allow the kernel extensions to load. )
So it may be that the exact type of kernel extension is important. ( I am not tech enough to be able to understand the deprecated KPI's)

[user-vjnZfpiMRy]

Thanks for the update and quick reply. I'll be sure to keep an eye on this thread. Looking for the same issue. Bumped into your thread. Thanks for creating it. Looking forward for solution.

[toster1532]

the way i have used to fix that issues is from this site
https://mrmacintosh.com/reinstalling-big-sur-on-apple-silicon-macs-with-11-0-20a2411-error/

"I was just given the steps below to follow by an Apple chat tech that oddly worked.

1. Boot to recovery
2. Launch Terminal
3. Run terminal command: resetpassword. (Ignore errors about users if it comes up)
4. Click on the background to the side of Reset Password window , then choose Recovery Assistant in the menu bar then select Erase Mac.
5. Click Erase Mac in the window that opens, then click Erase Mac again to confirm. When done, your Mac restarts automatically.
6. If they are on 11.0.1 it will automatically reboot after the erase is complete. After the reboot select wifi appears, and prompts the customer for activation. When activation completes, they need to choose the option of [Exit to Recovery Utilities] which brings us back to the main recovery screen.
7. If the activation fails, make sure they are connected to the internet via their Wifi icon. (Some ethernet dongles are not detected in recovery, use Wifi)
8. Once activation is completed. You will see the normal restore options. Choose reinstall macOS Big Sur."

[jgaitherccu]

@toster1532 That was my post, lol. Confused me seeing it reposted here

[macmanmk]

This is insane. It shouldn't be this easy to brick a machine. I don't even have FV2 enabled on my test machine and am getting this error on the first reboot. Not to mention that every time I have wanted to erase the machine and reinstall the OS while testing workflows, I have to restore using DFU through AC2.

[alexkaye]

Indeed It is insane. I have found on M1 Mac Minis the issue happens regardless of whether I enable FileVault or not. On my M1 MacBook Air the issue does not occur so long as it is on 11.01 and I do not force reboot through Jamf. I have also reported to Apple. On the plus side I am now a master of restoring Macs through DFU mode

[Wakko]

Well if anyone is on Appleseed IT they'll see that a new installer has been cut. Time to start testing agin.

[UbiquitousChris]

I don't know about the rest of you, but this is still happening with 11.1.0. In fact, for me it seems to be even worse.

[mconners]

Is there any way of smart grouping the M1's and excluding them from any previously known approved KEXT's?

[hkabik]

Processor Type - Not Like - Intel

Should work for now.

[kmathern]

@Hkabik confirming that does work for anyone out there testing the M1 chips

[matthias_bretz]

Or you check especially for ARM-CPUs: Architecture Type is "arm64". Works for me.

[cornwella]

We've had this happen with several M1 Macbook Air and Pro devices both with and without Jamf enrollment. From what I can tell there's a firmware build these ship with that's essentially a silent time bomb; anywhere between unboxing them and 2+ weeks of regular use it'll suddenly boot up with the "Recovery is trying to change system settings. No Administrator was found" error. The only way to get them running again at that point is a DFU restore using Configurator.

We haven't seen it reoccur after updating the firmware and letting them install all available OS X updates as the very first step, but sometimes it happens before one even gets a chance to search for and apply any pending updates. Very frustrating.

[ThierryD]

+1 same problem in our environment. The only way is to restore the Mac in DFU mode but it doesn't resolve the issue.

[timlarsen]

Unfortunately we're right there with you guys in our environment. And whoever said it is absolutely right that this issue is almost like a "ticking time bomb" since the issue sometimes doesn't occur until the second or subsequent reboots. We've also opened up a case with ACE.

Has anyone found success with excluding your KEXT whitelist profile(s) from M1 Macs prior to enrollment as preventing this issue from occurring, or no?

Thanks! Good luck everyone.

[hkabik]

In my experience, excluding KEXT approval profiles does seem to stop this issue from occurring. But I have heard from others that even when they have done so the issue has still seemed to randomly pop up on a subsection of machines. So my experience, yes that is the bandaid... but it seems there are still unkown circumstances that can trigger it.

[ravisgupta]

it appears to do with managed local admin account not having the secure token as it has not logged in (we create standard accounts for users). When I elevated standard user to local admin on system, which in turn allowed it to add secure token on managed local admin account, this issue did not occur for me then, though upon first restart it did as for user's password to unlock the drive to boot the machine.
Looks like will have to prompt user to allow adding secure token for local admin account after elevating user's privileges

[ThierryD]

@hkabik Same for me. Excluding KEXT seems to have resolved the issue. I hope it won't trigger for other processes.

[tjhall]

In my experience the problem with M1's doesn't just rear it's head with kext config profiles.
Using an DEP enrollment; any policy with a package containing a kext will either kick up a dialog prompting for password for "Security Certificate" or fail and potentially cause issues (for example, the Google File Drive Stream package contains a kext and will prompt for password to approve it but will still fail since it's trying to install a kext).
I'm still working my way through our policies and adding exclusions (based on BigSur + ARM architecture) but a good place to start is the inventory of an enrolled M1 Mac and inspect any packages of policies which have failed.

[Jason33]

I got hit with this today on a MacBook Air

[Key1]

Got this today with all the KEXT profiles excluded. Its really intermittent though.

[matthias_bretz]

@tjhall: do you mean such a dialog (as attached)?

I noticed this while installing Avast Antivir Business with policy triggered on the command line (jamf policy).
If I just wait for the recurring checkin this won't show up and the install will fail.