Hi all,

WARNING: long post – get some coffee!

As topic for this 2nd post of the year, I’d like to have a look at how to escrow and re-issue/renew a Personal Recovery Key (PRK) for FileVault with Jamf Pro. This is nothing new, and has not changed much over the last few Jamf Pro and macOS versions, but I sometimes see some discussion on how things really work. Hence I’d hereby like to clear out a few things regarding this matter, or at least elaborate how things should work in case you are experiencing a different behaviour.

The main two statements I’d like to make here are:

  • You do not necessarily need a script to re-issue / renew the Personal Recovery keys
  • You do NOT need 2 inventory updates to escrow and validate a new PRK.

Let’s have a look, this is going to be a fun ride!

Enforcing FileVault with a Jamf Pro Policy

Let’s start with how enforcing FileVault with a Jamf Pro policy works, and what it does with the PRK.

Amongst the payloads for a Jamf Pro policy we find our ‘Disk Encryption” Payload. This would typically be used to encrypt the drive via the Jamf Pro binary instead of via MDM with a configuration profile.

To use a policy to enforce FileVault enablement on our Macs, we would first create a “Disk Encryption setting” in the Jamf Pro settings…

… and then select this setting in the payload of our policy:

Executing the policy on our client Macs would defer the enablement of FileVault until the next login or logout (depending what we have chosen in the settings) and automatically escrow or submit the PRK to the Jamf Pro inventory of the device. Let’s try it out!

I start with an unencrypted Mac…

… and run my policy to enable FileVault:

But before I do so, I just want to show you that I do not have any FV profiles installed on this Mac…

… and there is no FileVaultPRK.dat file in /var/db/. I’ll come back to this later (as this is for configuration profiles only… stay with me).

So let’s run my policy:

At this point, FileVault is NOT enabled yet, and the encryption has not started! Remember that in order to enable FileVault one way or the other, a user (with a SecureToken, if there are SecureToken holders on the system) needs to authenticate! This means that we have to wait until the next Login/Logout depending our settings, aka deferred enablement.

At this point there is still no FileVaultPRK.dat file in /var/db/ but there is deferral active now:

And as you can see in the screenshot above, the deferral which has been enabled by the Jamf Policy defined an output path: /Library/Application Support/JAMF/run/file_vault_2_recovery_key.xml

Let’s have a look at that file:

Ah! It’s not there yet, but there is a file_vault_2_id.xml file… so, what’s that?

Wait for recovery key… ok not giving us much information, so let’s trigger the enablement of FileVault by doing a logout/login…

… and FileVault encryption starts:

But, wait a second… when I check those FileVault related files again in /Library/Application Support/JAMF/run/ … they are gone?

Yes! The Jamf binary on the Mac already picked it up… grabbed the PRK, submitted it to Jamf and did some clean up (as the PRK should not stay in clear text on the Mac):

This all without a single inventory update or even a configuration profile with the PRK escrow functionality. The Jamf Binary does take care of everything if you enforce FileVault with a policy! If you would have a look in the database you’d find additional details regarding those files I mentioned above (like the FileVault Key ID we saw in the file), but in view of this post this is all irrelevant. Important to understand here is that the Jamf Pro Binary automates the entire FV deferral & enablement and escrows the PRK.

No inventory update or config profile needed!

But wait a second! The Personal Recovery Key Validation still says ‘unknown’?! And the encryption state says… “Not Encryption”! Well, indeed… good catch! So ok, let’s do an inventory update… just one!

There we go, encrypted and valid! But remember, in view of my 2nd statement at the beginning of this post… only 1 recon (inventory update) was needed!

But what happened here? Obviously as part of the recon, the Jamf Binary reported the encryption status of the Mac to Jamf Pro, but how did it validate the PRK? Well, at the beginning of the recon process the Jamf Binary starts with “retrieving inventory preferences… which includes the PRK Jamf Pro has on file for this Mac. During the recon process the Jamf Pro binary validates the PRK (just like you would do with ‘sudo fdesetup validaterecovery -personal’) and submits ‘Valid, Invalid or Unknown’ to the inventory.

All the above is only valid however if the Mac was online after the login where we enabled FileVault. So let’s do the same exercise again but before logging out (in order to log in again to enable FileVault) I’ll disable my wifi connection and see what happens.

Executing my FileVault policy and checking the FileVault related files in /Library/Application Support/JAMF/run/ :

As you can see, just like in the previous exercise, we get file_vault_2_id.xml file:

Now I disable the wifi, log out and log in again to trigger the enablement of FileVault:

Once logged in, with wifi still disabled, I now find the file_vault_2_recovery_key.xml, which has the recovery key!

But from a Jamf Pro Inventory side of things however… nothing is there yet. Expected as the Mac is offline and the Jamf Binary can not communicate with Jamf Pro…

Now, let’s connect the wifi again and let the Mac sit as it is, without doing any terminal commands! I do not have any additional policies active with recon (inventory update), and my checkin settings are set to 5 minutes. So we’ll just wait…

And there we go… without doing anything I get my PRK in the inventory!

Note: the 'last inventory update' you see here was from before we enabled FileVault! Proof of that is that the Encryption state is still saying 'Not Encrypted'. If an additional recon would have been executed... it would say 'encrypting x%')

Looking at our files in /Library/Application Support/JAMF/run/ we see that the binary indeed cleaned it up:

Yet again however, the validation still states ‘unknown’, so let’s run a recon now… just one! And there we go… the PRK in the inventory and reported as valid!

Conclusion: The Jamf Binary entirely automates the escrow and validation of the PRK if FileVault is enforced via a Jamf Pro Policy. Even when the Mac is offline when FileVault is being enabled (login/logout) the Jamf Binary is still escrowing the PRK later when it’s back online. And most important conclusion: only 1 recon is needed to validate the PRK.

Enforcing FileVault with a Configuration Profile

Now, before we look at how to re-issue/renew PRK’s, let’s have a look at how things work if we enforce FileVault via a Configuration Profile…

I’ll start with a clean unencrypted Mac again:

NOTE: I want to highlight that enabling FileVault via a Jamf Pro policy does not stop the end user from disabling it again. You need a profile to really enforce FileVault to stay 'on'.

When enforcing FileVault with a configuration profile, we have two features we can use:

  • Require FileVault 2 and set a PRK
  • Enable Escrow PRK

“Require FileVault 2” is what forces the Mac to enable FileVault. In se this can be done at login or logout according to Apple’s MDM framework but currently Jamf only implemented enablement at logout if you use a configuration profile. You can use a custom profile and upload it to Jamf Pro, but in view of the purpose of this post, let’s stick to the native Jamf Pro functionality. It does not change the behaviour of the topics in this post.

“Enable Escrow PRK” is what sends the recovery to the inventory of Jamf Pro via MDM.

Let’s scope this profile to my test Mac and see what happens.

The profile is installed, and FileVault has been deferred to the current user. At this point FileVault is not enabled yet, and we see that there is no /var/db/FileVaultPRK.dat file yet either.

We also see that there is nothing in /Library/Application Support/JAMF/run :

This is expected, as the file_vault_2_id.xml is only generated to be used with the Jamf Binary, and we are enforcing FileVault via MDM here now. MDM uses the /var/db/FileVaultPRK.dat (by default) to store the PRK instead. In order for this file to be created however, FileVault enablement must be triggered and a PRK must be set.

More info about this can be found here: https://developer.apple.com/documentation/devicemanagement/fderecoverykeyescrow

Let’s now enable FileVault by logging out with the current user to trigger the prompt to enable FV. I get my PRK and after logging in again I see that the FileVault encryption has started:

Now, because there is a configuration profile with the ‘escrow PRK’ payload installed on the Mac, and because a PRK has been set, we now have the FileVaultPRK.dat file in /var/db/ :

This FileVaultPRK.dat file contains the encrypted PRK.

Let’s have a look at Jamf Pro now!

Nothing? No PRK? We are escrowing via MDM here, so why don’t we have the PRK in our inventory?

Well, the way it works is that, in order for the MDM server (Jamf Pro) to get the PRK, it has to ask for it! So a command needs to be send to the Mac to ask for the PRK which is stored and encrypted in that /var/db/FileVaultPRK.dat file. This command is the ‘SecurityInfo command, and is pushed out by Jamf Pro after each SUBMITTED inventory update. Whenever a Mac submits the reconform after completing an inventory update, Jamf Pro does send out a few MDM commands like CertificateList, ProfileList,… and SecurityInfo.

If I have a look at the Management History for this test Mac, I see that Jamf has indeed sent the SecurityInfo command, but this was before enabling FileVault. So in order to force Jamf to send out that command again we need to do a recon…. just one. Just 1 recon after setting a new PRK.

To make my point here, I’m going to kill the wifi connection split seconds after I see the Mac submitting the inventory update. Just to show you exactly what happens!

Ok, there we go. We start with my Mac which has still this information in the Jamf Pro inventory:

And I force a recon, and disconnect the wifi ASAP after the recon is submitted to Jamf pro:

The inventory update (reconform) has been submitted to Jamf and the status in the inventory changed to ‘Encrypted‘. However, there is no trace of the PRK, nor has it obviously been validated…

But if we have a look at the pending commands… we do see indeed that Jamf Pro has send a SecurityInfo command. Currently pending… because I quickly disconnected the wifi after the recon.

So this means that the recon is NOT doing anything with the PRK at this point, because we enforced FV via MDM and not via the Jamf Binary. The PRK has however been set and is encrypted in the /var/db/FileVaultPRK.dat file. Waiting for the MDM server to ask for it. Only the SecurityInfo command will trigger the Mac to provide the PRK.

Let’s connect the Mac to the wifi again and let that command complete.

The SecurityInfo command has completed, and there we go! PRK in Jamf Pro and Validation Status instantly flipped to ‘Valid’!

Conclusion: When enforcing FileVault with a configuration profile and escrowing the PRK, the PRK is stored (encrypted) in /var/db/FileVaultPRK.dat and we need 1 inventory update to trigger the ‘SecurityInfo’ command. Once the MDM server receives the reply to the ‘SecurityInto’ command it escrows the PRK and Jamf Pro automatically set the key to ‘Valid’. 1 recon, 1 SecurityInfo command !

Re-issuing / renewing the PRK

Now, what about re-issuing existing or missing PRK’s?

Well, that brings me back to my first statement I made at the very beginning of this post: you not necessarily need a 3rd party script to re-issue the PRK.

Without using a script, you can issue a new PRK with a Jamf Pro policy, but only if one of the 2 criteria below are met:

  • Jamf Pro already has a valid PRK for the Mac in the inventory
  • OR, the Jamf Management Account has a Secure Token
NOTE: There is currently a bug in macOS Big Sur (still present in 11.1) which does not allow the PRK to be renewed by using the current VALID PRK as password. See below, but allow me to first explain how things should work.

The first condition may be true in scenario’s where you need the re-issue the (currently still valid) PRK because it got compromised, or because you have an internal policy to cycle such security keys every x months.

However, if the Mac was already encrypted prior to be enrolled in Jamf, this would not work as there would be no key escrowed in Jamf at all. Or another situation would be one where something went wrong and the key was changed on the Mac without being escrowed correctly.

Without a valid PRK, your options to avoid a script are becoming limited, but there is still one possibility: a Jamf Management Account with a SecureToken!

Ok, looking at how the Jamf Management account could potentially get a SecureToken, this option is indeed not straight forward. First of all, since Jamf Pro 10.24, the Jamf Binary creates the Management Account with the ;DisabledTags;SecureToken flag. This to avoid race conditions in Big Sur where the Management could potentially get a SecureToken before the end user creates an account on the Mac (leading to FileVault enablement issues).

But even before 10.24 and Big Sur it was very unlikely to have a workflow where, by default, the Jamf Management Account would automatically get a SecureToken. Only logging in with this account as very first account doing so, on a SecureToken-less system would give this account a SecureToken. Without doing so (which I would indeed really recommend to avoid in general workflows), there is only one way to give the Jamf Management Account a SecureToken, which is by scripting a token grant via another user while providing or prompting usernames and passwords.

That all said, it is technically possible! So if you are in a situation where the Jamf Management account does indeed have a SecureToken… good news, the policy payload ‘Issue New Recovery Key’ will work just fine. Even if there is no valid PRK stored in the inventory already! At least it should,… see my note above about the macOS Big Sur bug which I’ll elaborate further here below.

Ignoring that Big Sur issue for a moment, the way to issue a new PRK via a Jamf Pro policy, without a script would be like this:

But how does this work?

Well, in order to understand how Jamf renews the PRK, we need to look at how we do this manually in Terminal.

To change a recovery key you would use the ‘sudo fdesetup changerecovery -personal’ command. After authenticating for the sudo, you will then be prompted for a username and password of a SecureToken-enable user. Just like this:

This immediately explains why Jamf can cycle the PRK if the Jamf Management account has a SecureToken, as Jamf Pro knows the password of the Management Account (if not changed without updating the inventory).

However, resetting the PRK by using the current valid PRK is a bit different. It’s actually doing the exact same manipulation of the PRK, but by using a ‘special account’: the Personal Recovery Record.

What’s that? Well, let’s have a look by first of all checking our extended list of cryptousers with fdesetup:

EBC6C064-0000-11AA-AA11-00306543ECAC                 Personal Recovery Record

This ‘account’ or record is the same on ALL FileVault Encrypted Macs! Yes, the UUID is the same on each Mac on this planet, and we can use that account to renew the PRK, by using this UUID as username, and the current valid PRK (which we want to change) as password:

As my current test Mac is running Big Sur, this is currently erroring out with ‘Unable to change key’, but believe me, this does works on macOS Catalina and should, in my opinion, also work in Big Sur.

That all said, this is exactly what Jamf Pro does when you use the ‘Issue New Recovery Key’ payload. It tries to use the current valid PRK (if known), and if not successful it tries to use the Jamf Management Account to cycle the PRK, which only works if that account has a SecureToken.

Now to continue my statement of ‘you do not need 2 recons’ to escrow a PRK, let’s have a look at what happens if we use the Jamf Pro policy to issue a new PRK. In my first test I do NOT have a FileVault profile with escrow installed on my Mac. Hence there is no /var/db/FileVaultPRK.dat file for the SecurityInfo command to fetch it from.

To make the policy work on Big Sur however, I gave my Jamf Management Account a SecureToken:

Jamf Pro Policy:

I start with this valid PRK:

I run the policy:

And I immediately get this:

A new PRK and immediately VALID, changed and validated just by running that policy! Not even 1 extra recon (as you can see the last one I did was 13 minutes ago) and not even a profile installed to escrow the key! The last SecurityInfo Command sent out was just after that previous recon by the way and has nothing to do with running this policy.

Ok, it says 16 minutes ago, and not 13 like the screenshot showing the last inventory update, but that is because I realised 3 min later I needed that screenshot. You just have to believe me that I’m not playing a timing game here. Im not trying to fool anybody on my blog 🙂

So my statement about the fact that you do not need 2 recons to escrow a PRK still stands right? Here we don’t even need one! And if you do add a FileVault profile with escrow to the mix… it does not change a thing. Running this policy to renew the PRK does not do a recon. Hence it does not trigger the SecurityInfo command so the escrow functionality of the profile is not leveraged at all here. All is taken care of by the Jamf Binary!

Finally, one last thing to test: using a script to renew the PRK! It doesn’t really matter which script you are using, as long as it works for the the OS you are running it on and it does not do any crazy things, all should be good.

For this test I’ll use this one, which works fine: https://github.com/jamf/FileVault2_Scripts/blob/master/reissueKey.sh

As we are not using a Jamf Policy which has its own logic to submit the PRK to the inventory (as explained above in this post), we DO need a FileVault profile with escrow installed on the Mac PRIOR to running any reissue-PRK script! Without such profile, there is not /var/db/FileVaultPRK.dat file to store the new PRK and no way for the MDM server to fetch it!

To fully simulate a situation where we need to re-issue an invalid PRK I start with this:

And as you can see, I even disabled ‘relative dates’ in my Jamf Pro settings to give you the exact time of the last Inventory Update.

Let’s run the script!

After running the script… waiting for a few minutes (even after the next checkin – set to 5 min in my test Jamf Pro – if someone would doubt that this impacts it or not)… nothing changed:

And the last SecurityInfo command which was sent out is still the one from the 11:50 inventory update:

Let’s now (00:00) run a recon, yes, just 1!

A new PRK, instantly validated! This following 1 recon which triggered just 1 SecurityInfo command:

That’s it! 1 inventory update does all we need!

The goal of this very long post was to elaborate how the escrow of PRK’s into Jamf Pro works, and to clear out a misunderstanding about the need for 2 inventory updates to escrow and validate the key in Jamf Pro!

Am I saying that it is impossible to create a situation where you end up with invalid PRK status in Jamf Pro? NO! However, 1 recon, 1 SecurityInfo command should be enough. If not, there is something else going on, and the culprit is most likely going to be the SecurityInfo command which did not complete correctly, was cancelled or failed for whatever reason. As long as that 1 command completes correctly after setting (a new) PRK and you do have a profile with the escrow feature enabled on the Mac, the current PRK – stored in /var/db/FileVaultPRK.dat – should always be reported correctly in Jamf Pro. The validation status should be valid after completing that 1 SecurityInfo command. Whatever the Jamf Binary and the recon did before that.

After reading all this you may wonder if there could be a race condition in play here where the inventory update starts, triggering a SecurityInfo command to go out, which completes before the inventory update (reconform) is submitted to Jamf.

This could, hypothetically, explain why the new PRK is escrowed into Jamf, but an inventory update which took some time to complete validated the old PRK in the mean time. Submitting the reconform after completion of the SecurityInfo command, resulting in an ‘invalid’ status.

This is however NOT the case. When an inventory update is initiated, it gets the current (or OLD) PRK from the Jamf Pro database, and uses it to validate it against macOS. Because the new PRK is not escrowed yet (if it changed) this will indeed result in an ‘invalid’ status, and will be reported as such to Jamf Pro.

However, the SecurityInfo command is not triggered at the start of the inventory update, instead it is only triggered after the reconform has been submitted and the inventory update succeeded. If you want, test this out by running a recon, and AFTER it “retrieved the inventory preferences” (starting to run things like: ‘Finding Extensions Attributes’….) cut the internet connection.

You will see that the inventory update continues, and obviously ends with a connection failure when trying to submit the results.

The SecurityInfo is not triggered… hence there can be no race condition in play here!

Even if you do add more subsequent inventory updates, it should always clear itself out. Imagine you do a recon… it submits and triggers a SecurityInfo command. But imagine that this SecurityInfo command is delayed, and before it completes (for whatever reason), another recon is executed… If the first SecurityInfo command completes before the 2nd recon is submitted, the second recon may flip the validity status back to ‘invalid’… When you check the inventory you could then think that the new PRK validation failed…. but what really happens is:

Invalid key -> reissue -> recon -> SecurityInfo command -> other recon starts before the SecurityInfo commands completes and this recon gets the old PRK to validate again -> first SecurityInfo command completes and puts the key to Valid -> second recon submits an ‘Invalid’ status again (because it validated the old PRK)…. but guess what!!! That second recon triggers… a second SecurityInfo command => BOOM Valid.

So that said…. have patience and check the pending management commands before you make an assessment on the status of the PRK!

As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!