macOS 10.13 High Sierra and Filevault Recovery Key Escrow in JSS 9.101.0

You will need at least 2 configuration profiles one for 10.12.6 and older and one for 10.13 and newer.
Make sure they don't overlap in their scoping.

For 10.12.6 and older you only need the FileVault Recovery Key Redirection: Automatically Redirect Recovery Keys to the JSS
I decided to add my Security and Privacy Settings in the Same config profile for 10.12.6 and older but this is not necessary.
Make sure you don't set any of the filevault settings in this payload.

For 10.13 and newer you only need to set the Security and Privacy Settings
Tick Enable Escrow Personal Key Recovery
Under the Escrow Location Description put some information that is friendly to the end user they will see this in System preferences when they try to enable Filevault. I put the hostname of my JSS as it has my company domain in it.

For Device Key leave that blank and it will use the systems Serial Number.

For More info check out the 9.101 Release notes and Config Profile changes.
http://docs.jamf.com/9.101.0/casper-suite/release-notes/What%27s_New_in_This_Release.html

Thanks @a.stonham - has it been confirmed that they need to be separately scoped Configuration Profiles since 10.12.6 and older won't do anything with the 10.13-specific Escrow management commands?

And by referencing the JSS in the "Escrow Location Description", is this user facing in any way so that they can recover their key by signing in to the JSS?

@a.stonham In that scenario, what happens when a computer upgrades from 10.12 to 10.13?

@dpertschi From what I've seen so far (2 upgrades) the key stays valid. Depending on your config the old profile gets removed and the new one installed, but since the disk is already encrypted and the key already available in the JSS it doesn't have to do anything.

The new profile ensures that any future key re-issues get escrowed, through mdm, to the JSS.

@sburt yes they need to be scoped separately, or you will get errors on the 10.13 machines when you try to enable FileVault.

@dpertschi The key will stay in the JSS from 10.12. When the Mac next inventories the old FV2 config profile will be automatically removed and the 10.13 will be installed.

Thanks @a.stonham,
I did the test on a Mac reinstalled clean with High Sierra.
I did follow your procedure, I see the profile configuration on the Mac but Filevault does not activate even after several restart.

@DSI Is FileVault enabled on the Mac, but not reflected in the JSS? If so, what happens after a couple of Recons?

Hi @dan.snelson, here is the result I take on my Mac after several Recon and reboot "FileVault is Off".
With OSx 10.12 the encryption started automatically at the next reboot, but this is not the case with OSx 10.13.
Is there still a rule missing?

@DSI I see your Configuration Profiles; what does your policy to enable FileVault look like?

Hey guys -

I wanted to point out a spot in Apple's Configuration Profile Key Reference in regard to this topic -

FDE Recovery Key Escrow Payload

If you scroll down to the FDE Recovery Key Escrow Payload section you will see the following:
...
The previous payload (com.apple.security.FDERecoveryRedirect) is no longer supported. It can still be installed, but it will be ignored. This lets servers send out the same profile to old and new clients.
...

I read this to mean that both profiles can be scoped to the same computer &, if so, the old profile will be ignored. Thanks!

@dan.snelson The only policy that relates to FileVault and the creation of a user who is allowed in FileVault so that the administrator can connect to recover files if the user loses his password.

@brock.walters If I understand correctly, we can leave the 2 Payloads (Security & Privacy and FileVault Recovery Key Redirection) for all OSx versions but also activate the Enable Escrow Personal Recovery Key?

I made a printscreen to better understand

@brock.walters I spotted the same, however the next line says -

If only an old-style redirection payload is installed at the time FileVault is turned on (by means of the Security Preferences pane), an error will be displayed and FileVault will not be enabled.

However @a.stonham maintains that sending the profile to both old and new clients causes an error on 10.13 clients. I wonder if there is some truth on both sides.

Possibly if you send the profile containing both new i.e. com.apple.security.FDERecoveryKeyEscrow and old i.e. com.apple.security.FDERecoveryRedirect to both 10.13 and older clients and via the profile enforce FileVault encryption it will work for both. Whereas if you only sent the old style one to new clients it would fail. However it looks like the GUI for Profile Manager or JAMF only allows one or the other depending on the version of MDM you are running. You would presumably have to hand edit a mobileconfig file to have both.

It would be helpful to have some guidance officially from JAMF regarding this. Or is anyone in the fortunate position of being able to get an answer from Apple?

All credit to the writer of this guide but just followed it and it works perfectly for ONLY managing FileVault Recovery Key Redirection in 10.13.

How to manage ONLY FDE Recovery Key Escrow in Jamf Pro 9.101+

Thanks for the shoutout @iJake!

If anyone has trouble with my guide I'm on the macadmins.slack.com team @haircut – just shoot me a DM.

@DSI ,

If you're seeing issues with the Configuration Policy not kicking in at reboot, it may be because you're connected via Wireless and not a hard wired ethernet connection. I've noticed that login/logout policies do not always trigger at reboot.

Hope this helps.

Once upon a time we used
JAMF "Disk Encryption Configurations"
Any advice on that?

I have used the method to make 2 profiles: for ≤10.12 : FileVault recovery key redirection, for 10.13+ FileVault key escrow (part of Security)
Using the script from Elliot Jordan (link) and Rich Troutons extension attribute for APFS encryption status (link) I can now get users to re-new the Recovery Key.

The smart group criteria 'Individual Recovery Key Validation: (is not) Valid' does not work reliable, some of my 10.13.x mac's show here 'Unknown' while at the Management - 'FileVault 2 ' is 'Configured' and I can get a valid recovery key. Jamf Pro 10.0.0 and 10.1.1.

Now my question: Which smart group criteria to use to scope the policy ?

@maurits did you find a way to make a reliable smart group?

@maurits @int-corpit

This is an ongoing issue that I've working through as well. I'm not able to trust a smart group based on "Individual Recovery Key Validation: Valid". Same behavior as @maurits described, periodically computers will submit inventory and the computer record will show "unknown". At next inventory (recon or Update Inventory policy) this will revert back to "Valid".

Hi. Once the configuration profile containing the Security & Privacy > Enable Escrow Personal Recovery Key (as in the screenshot provided for macOS 10.13 devices) is installed on the Mac (visible in the Profiles System Preferences), is there any action to trigger the Filevault encryption ? On a test device, we have the configuration profile successfully installed but no FileVault encryption is at least suggested to the logged-in user. Thank you for any advice ! Franck.

@maurits @int-corpit @mottertektura Same here on Jamf Pro 10.1.1
Usually the 2nd recon and some time shows 'valid' and the key info.

Tough when replying upon Smart Groups, but at least it's mostly working...

I have the 10.13 escrow config profile on a test computer but FV2 is not enabled. Who or what enables FV2 at this point?

@int-corpit No I have not found a way, so we do no scoping on this smart group. We do alerting by email on montly basis. All company data is supposed to be in Box, so if users forget password, it should not be disasterous for company data (we hope :-)

Commenting on this in case @maurits , @int-corpit , @mottertektura , or @scottb have a breakthrough, since I'm in the same position (using Elliot Jordan's script, Individual Recovery Key shows as unknown and needed to be Valid for the existing Smart Group to work properly). I get that that Criteria is probably not going to work in High Sierra, but hopefully someone can come up with a second Smart Group for High Sierra computers (maybe after creating @haircut 's Config Profile, create an EA of computers with the Profile installed and then create a Smart Group off of that for computers that have that profile and assume if they have that Profile then it can recovered?).

@el2493 - the way I'm doing it isn't perfect, but the FV2 status continues to evade me.
I am creating Smart Groups for macOS ≥10.13. and one for ≤10.12.
Each look for the macOS Version, Boot Partition is Encrypted, and FV2 Individual Key Validation is Unknown.

Two config profiles - one scoped for each group above.
Then, the policies for the Macs once they get the Profiles. Set to run once. At any time I could change that to run more often.

So far, on about 200 Macs of 10.12.x and 10.13.x, all but three have run successfully. They get an error like this below.
Sometimes just re-enrolling them fixes it as the passwords being used are correct. Since they are almost all remote, I can't connect to them to do any troubleshooting other than that.

Script result: [WARNING] This script is still in BETA in High Sierra, because the fdesetup binary has changed significantly. Please use with caution.
Alerting user ivicamicev about incoming password prompt...
Prompting ivicamicev for their Mac password...
Prompting ivicamicev for their Mac password (attempt 2)...
Prompting ivicamicev for their Mac password (attempt 3)...
Prompting ivicamicev for their Mac password (attempt 4)...
Prompting ivicamicev for their Mac password (attempt 5)...
[ERROR] Password prompt unsuccessful after 5 attempts. Displaying "forgot password" message...