Admin accounts on Ventura cannot decrypt FileVault

[jjaimes]

Our Jamf environment requires that all Macs have FileVault enabled and we recently discovered that all of our Ventura systems can no longer unlock the drive with any administrator accounts. The only ones that can are standard accounts. We we're able to reproduce this issue on both an existing system that was upgraded to Ventura and a brand new MacBook Pro.

To clarify:

- FileVault is enabled on Mac OS Ventura.

- Administrator accounts are unable to unlock the drive at startup/reboot.

- Only Standard accounts are able to unlock the drive at startup/reboot.

- We were able to reproduce the issue on both an older Silicon Mac and a brand new Silicon Mac out of the box.

Any advice is greatly appreciated.

[patrickj]

How is each account getting created?

[AJPinto]

1. How is FileVault getting enabled?
2. Who is enabling FileVault?
3. Are these Admin accounts on the Mac before FileVault is enabled or are they being added after FileVault is enabled?

[jjaimes]

FileVault is being enabled via Configuration Policy in Jamf. The issue occurs for both accounts created before or after FV is enabled. Now one can assume that Apple has now changed it so that admin accounts can no longer unlock the drive, but there is no documentation of this anywhere. In previous versions of the OS this was not the case.

[AJPinto]

The only special thing Admin accounts have is a Bootstrap Token. Bootstrap tokens have never been able to unlock FileVault. To unlock FileVault you have always needed a Secure token, Secure Tokens allow a user to install OS updates and are tied to volume ownership to a degree.

The Configuration Profile does not actually enable FileVault. The Configuration Profile sets the requirements for macOS to prompt the user to enable FileVault. A Username and Password are required to enable FileVault to generate the Secure Token, even when a MDM is requiring FileVault to be enabled. Admin accounts that exist on the device prior to FileVault being enabled typically get a Secure Token, but not always; it depends on a lot of conditions. Generally speaking it is not a good idea to give your IT account FileVault access, but that is not the discussion at hand.

Apple frustrates me as much as the next guy, and I think we can all agree Apple is horrible with documentation. However, Apple has not made any significant changes to FileVault since MacOS Catalina. Apple typically only makes changes to their core functions like FileVault with major OS updates.There were some changes involving FileVault and MacOS13 but I dont think they involved how Secure Tokens were handled but I would need to fact check that.

Use secure token, bootstrap token, and volume ownership in deployments - Apple Support

Manage FileVault with mobile device management - Apple Support

FDEFileVault | Apple Developer Documentation

[mm2270]

It wouldn't make any sense for Apple to make it so admin accounts could not unlock a FV2 encrypted Mac. I'll need to run some tests, but I haven't seen anything like what you're describing before. I believe you when you say it's happening, but the likelihood of it being something Apple changed is exceedingly small. There has to be some other explanation for this behavior. Either that, or it's a bug? What specific version of Ventura are we talking about? Have these Macs been recently upgraded to a new release?

[Jsynotte]

For what I have experience in my case, I've an administrator account created during pre-stage. If I want to use it, I need to login once to make if available to unlock FileVault

[jjaimes]

One of them is a MacBook Pro 2021 that was upgraded to from Monterey to Ventura. Prior to the upgrade all admin accounts were able to unlock FileVault but then lost ability to do so once the upgraded to Ventura. The other was a MacBook Air 2023 that came with Ventura and same result.

[mm2270]

I read this post, and my reaction initially was "And??" To me, this is best practice. I'm not sure I understand why some people feel it's necessary to have their local admin account enabled to unlock FileVault encrypted Macs. This is actually bad practice, for the simple reason that most of the time, that local admin account uses a single password across all devices. By having it able to unlock FileVault, you've created a scenario where if that password becomes compromised, all your Macs are then vulnerable to being accessed by someone with that password. Until you manage to set a new password on them, which isn't always that easy to do.

If you really need to get into your Macs using a local admin account, my advice is to pull up the Personal Recovery Key for that device, use that at the login screen, and then when you hit the username & password fields, THEN you can use the local admin name and password to login to the account. This is what we do. Sure, it's one (or two) extra step, but who cares? Is it really so important that you can unlock them with the local admin that you're willing to throw away a level of security?

Edit: In taking another look, it occurs to me now that maybe what you actually mean is that even if the account is enabled for FileVault, if it's an admin account then it can't unlock it, unless it gets demoted to standard. If so, then that is a problem, and doesn't make sense. There's nothing I can think of in Ventura or other OS versions that would cause an admin account to be stopped from also being FileVault enabled.

[jjaimes]

Trust me, I understand your logic completely, but prior to Ventura it would allow unlock for all accounts created after FV was enabled. For existing accounts before FV being enabled you would still have the option to allow admin or standard accounts to unlock. In Ventura after trying all scenarios it only allows unlock for standard accounts. And yes, if you demote an admin to standard then it gives you the option to allow for unlock.

Now, using those best practices for security, if Apple decided to remove this for admin accounts on Ventura then it would be nice if they documented it somewhere.

We are just looking for clarification.

[shaquir · Accepted solution]

Are the admin accounts also Volume owners? https://support.apple.com/guide/deployment/use-secure-and-bootstrap-tokens-dep24dbdcf9e/web

"To view the current list of volume owners on a Mac computer with Apple silicon, you can run the following command:

sudo diskutil apfs listUsers /

The GUIDs listed in the diskutil command output of type “Local Open Directory User” map back to GeneratedUID attributes of user records in Open Directory. To find a user by GeneratedUID, use the following command:

dscl . -search /Users GeneratedUID <GUID>

You can also use the following command to see user names and GUIDs together:

sudo fdesetup list -extended

If the admin accounts are Volume owners, try switching the login option to "Name and Password" and try attempt signing in.  

[jjaimes]

Confirmed that the admin accounts were volume owners, but in my case I had to un-hide admin accounts from the Login Window and that did the trick and I'm sure doing Name and Password works as well. Thanks for your help!

[bcrockett]

@shaquir What do you think is the best way to automate the process of finding out which accounts are Volumn owners? 

In theory, the first user to log into a computer becomes the volume owner and has a token. That allows for FV and macOS updates. 

That is not dependable. For that reason, I am looking for a way to quickly see which accounts in my fleet are not volume owners. 

Thanks for any support ideas you can provide. ~ B