FileVault, Big Sur, M1 and network accounts

[jhaff]

i'm looking for clarity around filevault and network accounts (not AD!), mostly on big sur and m1 models.  until the introduction of silicon macs, i've been using a firmware password to provide some protection on machines that go walking for one reason or another.  now with our new m1 macs, it seems that my only option for any kind of hardware security is filevault.

my issue is on shared laptop machines (school setting, laptops are in carts); i don't see a way of enabling filevault while allowing network users to consistently log in without making every potential network user a mobile account and enabling them as a filevault user - which is ridiculous and defeats the purpose of hardware security - if everyone can decrypt the drive, then encryption is worthless.

with filevault enabled, after a reboot, the only user(s) who are able to log in are the filevault enabled users.  it would appear my 8021x/scep profile is ignored and i have no network access either (although wpa2 joined networks seem to work?).  once i log in/log out of a FV account, network users are able to log in, but in a cart setting, that is hardly reasonable and not at all feasible to have a user log in before everyone else.  carts are constantly unplugged, the laptops die, people shut them down or reboot them.

it would seem that my only options are to leave encryption off to enable network users or create a shared FV enabled account that every student logs into.

am i missing something? 

[garybidwell · Accepted solution]

macOS Monterey will bring new methods of securing the M1 hardware, as these options where removed in the move to Apple Silicon. The firmware password option is gone for good, but there new ownership options so that you can control which users can change these hardware and security options in recovery mode
But what your seeing with FV is by design, as there no point in enabling encryption if there's not a mechanism to control who has or doest have access to decrypt the drive.

However your 802.1x issue will be unrelated, as the device will function then same whether FV is enabled or disabled (perhaps what your seeing is that until someone with a secure token has logged in to unlock the device (from a restart or cold boot), then it will not be visible on the network as it will still be waiting in the FV pre-boot stage waiting for FV enabled user to log in?)

[garybidwell · Accepted solution]

macOS Monterey will bring new methods of securing the M1 hardware, as these options where removed in the move to Apple Silicon. The firmware password option is gone for good, but there new ownership options so that you can control which users can change these hardware and security options in recovery mode
But what your seeing with FV is by design, as there no point in enabling encryption if there's not a mechanism to control who has or doest have access to decrypt the drive.

However your 802.1x issue will be unrelated, as the device will function then same whether FV is enabled or disabled (perhaps what your seeing is that until someone with a secure token has logged in to unlock the device (from a restart or cold boot), then it will not be visible on the network as it will still be waiting in the FV pre-boot stage waiting for FV enabled user to log in?)

[jhaff]

thank you for the insight.  i believe the network behavior is by design as well.  the drive needs to be unlocked for configuration profiles to be read.

[DBrowning · Accepted solution]

In macOS 11.5 and later you'll be able to set a Recovery Lock Password.  This will require a password in order to boot into Recovery working similar to how the firmware password works on Intel devices.  Jamf has (yet) to provide the ability to do so via MDM commands but I'm pretty sure they are working on it for the release of Jamf Pro as this is a big win for helping lock hardware down.

[jhaff]

this is super helpful, thank you!  i confirmed with jamf support that this feature will be included in the next release (10.32, i think).