First of all, why would we need this?
Well, in view of all changes and differences between Mojave and Catalina, and the wide variety of deployment scenarios, troubleshooting FileVault can become quite complex. And while there are multiple other reasons why FileVault deployment could fail, Secure Tokens remain the king of the root cause list by far!
Hence my first step in troubleshooting FileVault issues is always identifying which account has a Secure Token. I think, for those who have been reading the saga of posts I’ve done on the topic so far, it’s clear that if a user tries to enable FileVault (by any means, going from sys prefs to Jamf Pro Profile/Policy), without having a Secure Token while another account on the system has one, it results in issues enabling FV…
Same goes for when, for one reason or another, there are ‘Ghost Secure Token Holders’ on the system, while no other account has a token (caused by scripted deletion of accounts or testing with local snapshots via ‘tmutil snapshot’).
Apart from that, while the recovery key (if correctly escrowed in MDM) provides a way to get into the Mac when needed, having an admin account with a Secure Token remains a requirement for many Mac Admins.
Next, we have Bootstrap in Catalina. So depending how you deploy your Macs, it might be handy to keep track of which devices have been Bootstrapped. For this I already created an Extension Attribute which I shared here.
Finally, there is this thing with ‘unwanted FileVault Deferral‘. So I feel like it’s a good thing to track this as well. If ever a user reports not being able to enable FileVault, it might be handy to check to who FileVault has been deferred. Yes, it’s perfectly normal to have Deferred FileVault Enablement active when you just pushed a profile to enforce FV, but it should clear out once it’s enabled. If it stays active, you might end up having to cancel it following the workflow from Der Flounder.
So, with this post I want to provide a few things which might make your life easier by correctly reporting the Secure / Bootstrap Token situations in your environment into Jamf Pro:
- Report if Bootstrap is escrowed in MDM
- List all Secure Token Holders
- Correctly report if there are NO Secure Token Holders on the Mac (see below for edge case differences with ‘FileVault Enabled Users’ in Jamf Pro ~ Ghosts ????)
- Report if your admin account of choice has a Secure Token
- Report if there are any ‘Ghost Secure Token Holders’ on the system ????
- Report if ‘Deferred FileVault Enablement’ is active
- Report the Deferred user
This should look like this with Smart Groups in the Jamf Pro Dashboard:
And if we look on the inventory record of this Mac:
On the above screenshots we see that our Jamf Admin has token (I used Jamf Connect Login to provision the Mac with a standard account and logged in with the Jamf Admin in Terminal -> Catalina = Jamf Admin gets a token because there was no token holder and Bootstrap was not enabled (~ Jamf Connect Login), see previous posts to understand why.
But we also see that Deferred FV Enablement is active… at first this seemed expected to me, because I just pushed a config profile to enforce FileVault…. but wait a second, this one is new to me… If we have look at my Extension Attribute which reports the Deferred user: UNKNOWN ?
My goal here was to show you the deferral on my logged in user, who received the profile to enforce FileVault. In that case this user would be deferred and on next log out it would enable FileVault. But here the profile was pushed prior to creating the user with Jamf Connect Login… resulting in an ‘unknown deferred user’? Well, I guess this give us an instant usecase for the Extention Attribute, because, indeed, log out… log in… nothing, no FileVault Enablement! Makes sense because my user is not the deferred FileVault user….
NOTE: I haven't seen this behaviour before, so I'll need to investigate. Nevertheless, the EA works and reports the rogue deferred user!
The rest of the EA’s, and Smart Groups linked to it, are straight forward I guess. For the jamf Admin Secure Token I added 2 different scripting logics (amongst other possibilities) to provide some redundancy in the reporting. Cleaner scripting could be applied I guess, but yeah, it does the job and I’ll class it under ‘proof of concept’ 🙂
Some additional screenshots to connect the dots:
I’ll share the actual EA’s here. You can upload them to Jamf Pro and adjust / tweak where needed:
Deferred FV Active:
ONLY Unknown Secure Token Holders:
REALLY no Secure Token Holders:
Bootstrap NOT escrowed in Jamf Pro:
Bootstrap escrowed in Jamf Pro:
Jamf Admin Secure Token using sysadmctl command:
Jamf Admin Secure Token (alternative scripting):
Jamf Admin NO Secure Token using sysadmctl command:
Jamf Admin NO Secure Token (alternative scripting):
That’s it! Let me know what you think and if this kind of reporting is handy to have or not.
Please don’t hesitate to let me know if you see any inconsistent or inaccurate results, and more than happy to take any suggestions to improve the coding in the EA’s!
That’s it! As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!