Admin accounts on Ventura cannot decrypt FileVault

How is each account getting created?

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?

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.

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.

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.

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

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?

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

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.

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!

@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