Has anyone found documentation for the new "Enable Escrow Personal Recovery Key" option in JSS 9.101.0 in order to support Recovery Key escrow in macOS 10.13 High Sierra? It looks like Jamf hasn't updated the documentation to report best practices for the "Escrow Location Description" or "Device Key for Escrowed FileVault Recovery Key" variables:
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.
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?
@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.
Hey guys -
I wanted to point out a spot in Apple's Configuration Profile Key Reference in regard to this topic -
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.
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 ?
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.
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...
Would love to have an EA that I can target for machines that need to reissue the FV key or that don't have the FV key in the JSS. Cant seem to find any way to actually get a clean report stating that Yes a key does in fact live in the JSS.. Cant find an API to pull for this either and all the FileVaiult options have nothing about if the key is stored or not in the JSS.