M1 devices in the managed lab environment

Qwheel
Contributor II

Hello all,

Just trying to get an idea of how others are managing M1 MacOS devices in the lab environment.

We're potentially looking at some new lab machines this summer. Currently our intel devices get an Open Firmware password applied via a JAMF policy which is easy to enter and manage.

We do have staff M1 devices which are currently configured to enable FV and store Personal Recovery + Disk Encryption codes in JAMFcloud. Wiping one of the staff devices is a real pig though. Multiple restarts, multiple entries of the disk encryption password before we get to the point of an erased local disk + fresh install of MacOS.

How're other's managing this? Is enabling FV2 encryption the new 'normal' to prevent recovery from being openly available? Can't say I'm thrilled by the prospect of entering obscure disk encryption passwords multiple times... we're going into mind melting territory.

Any insight is very much appreciated!


10 REPLIES 10

YanW
Contributor III

For the new device, if you don't mind the user seeing the admin account showing on the login screen, then you can log in to the admin account first to get the secure token. So next time you can just log in to admin account to wipe it, delete the user account or whatever.

We don't do that, therefore, we just boot into the Recovery Mode and wipe it. Don't even need the Recovery Key to unlock the account. 

Qwheel
Contributor II

Thanks for sharing YanW

That sounds to me like you aren't using the FireVault Disk Encryption stuff. For example, on a staff Macbook, we have to long press the power key for options, but before it'll go into recovery, you've got to enter a 'Personal Recovery Key' which is 24 characters long.
At first, the 24 char password unlocks the disk and restarts, you then have to repeat the recovery steps and enter the 24 chars again to access recovery/disk utility. I'm pretty sure it asks for the string again when you go to erase the disk in Disk Utility.

So by the sounds of it, in your lab environment... a user could boot into recovery and wipe the disk without any requests for passwords?

Fluffy
Contributor III

Apple added a new password akin to the firmware password just for MDMs (after everyone yelled at them). Apple is calling it "Recovery password" and will prompt when going into Recovery Mode. I believe Jamf Pro lets you set this at enrollment, but not afterwords. I haven't been able to test this at all, since we use Jamf School and Jamf seems to be dragging their feet with this feature.

So, yes, someone with just a little research could mess up a machine. A combination of not using Recovery password and getting around DEP by saying you have no internet would let someone get the machine off of Jamf pretty easy. We're left in an awkward spot right now, and not very happy about it.

I agree with @YanW about signing into an admin account to get your tokens. Although, you should be able to hide the admin account that you create in your prestage with the checkbox for "Hide managed administrator account in Users & Groups".

junjishimazaki
Valued Contributor

Instead of booting to recovery mode to factory reset the Mac and entering the FV key. You can do this while logged in as a user using the "Erase All Content and Setting" option. https://support.apple.com/en-us/HT212749

Unless your org blocks that option. 

Love the feature. But it's worth mentioning that is only on Monterey and the user must be an admin.

I believe Jamf Pro should also be able to check if the option is enabled when you send the erase command, and will use Erase All Content and Settings if available.

Qwheel
Contributor II

Hadn't thought that this feature could be used and was intrigued to test it out.

I logged out of my M1 MBPs user account and in as the 'JAMF created' admin account. We've set JAMF to hide this account via DEP but had 'show other' configured in a config profile so I could still get in.

Curiously when I logged in as local admin, the 'Erase content and settings' option wasn't showing. I logged out and in again and it still wasn't there. Struck me as odd... compared groups between my user account (admin) and the JAMF created admin and couldn't see anything special about it.

I thought, maybe the JAMFadmin wasn't MDM enabled but saw people discussing online that if a user isn't MDM enabled, they can't use Self Service... so thought THAT probably wasn't what I was looking for.

I found this command:

sudo dscl . create /Users/username IsHidden 0
(zero meaning show, and one for hide).

I ran it and after logging 'in and out' a couple of times, I noticed the 'Erase content' option actually appeared for the local admin user.

This is pretty weird IMO.

I wonder if the option appears if I just go and create a new basic admin account (confirming the hidden attribute is related to why the 'Erase content' setting wasn't shown.

Out of interest - anyone noticed the 'Erase content' option not appearing when the JAMF local admin is hidden?

Qwheel
Contributor II

Well...
New visible admin account can see the option.
New account, that's then made 'hidden' can see the option.

Weird behaviour. Maybe something to do with the ordering that JAMF is creating the hidden local admin account (like, the username is created, then hidden, then permissions elevated, then home directory created). Just speculation though.

Fluffy
Contributor III

I've experienced the same bug and have no idea what causes it. But, if I remember correctly, I have fixed it previously by logging out of the admin and into a standard user, then back again, and the option showed. Very silly.

Qwheel
Contributor II

The Erase contents function made it really quick to troubleshoot.

We've unticked the 'hide local admin', and then added a manual command to run at the end of enrollment to hide it from terminal (^^^ up there somewhere).

Now the option appears immediately without any messing around.

junjishimazaki
Valued Contributor

I believe In order to see that option to Erase All Content and Setting, the user must have secure token