Jamf. I love your product but we have to have a talk.

Its your configuration profiles. Well, there’s no nice way to put this. They’re a bit bloated. Here’s an example of a Filevault encryption key escrow profile that I generated on my test server this morning.

So I downloaded this and pulled up the inspector window on the file.

It’s a bit big? 13Kb. Let’s de-sign this profile using Darren Wallace / Moof IT’s very useful xmlAutomator services and have a look inside. Sure enough, it’s full of preferences that you may not want set such as everything else in the Security & Privacy section. You may have these set elsewhere in their own profile(s) and you have a potential profile clash with probable unexpected results.

The trend in the Mac Admin world has been towards what I jokingly once referred to as “Artisanally Created Profiles” on the Mac Admins Slack aka building the things by hand. I normally just work out the keys, build the xml and upload as a custom profile inside Jamf.

Sadly the usual rules don’t work with FileVault 2 key escrow profiles (and a few others too). Well let’s see what we can do about this.

I’m going to work with the test profile I just created in Jamf and decrypted with xmlAutomator as mentioned. There are three very specific sections that I’m after in this file while literally consigning the rest to the trash bin deep. Things like this:

The entirely of the above picture can be safely deleted. You’re looking for the following PayloadType ‘s in the file. (and a brief explanation as to why)

com.apple.security.FDERecoveryKeyEscrow
Contains information for end users should they have to enable FileVault manually. You want them to know it’s all ok right? 😉

(note this is the one for macOS 10.12 and earlier. I include it because I like my profiles universal)

com.apple.security.pkcs1
This is the security certificate that macOS will use to securely send the FileVault key to your escrow server. We like secure communications paths 😉

com.apple.security.FDERecoveryRedirect
This is the address that macOS will send the FileVault key to. Always useful 😀

You want these three and no more. Everything else must go.

You might find duplicates, especially of the pkcs1 certificate. Delete them. They really are duplicates and we’ll deal with any consequences later. If you save your changes at this point then you’ll find your designed profile has just shrunk by about two thirds in size.

Smaller profiles = Happy MDM = Happier Life

However we are not done just yet. The reason why you can’t just extract the relevant keys and make Jamf custom profiles has to do with that certificate that’s in place. There’s a reference outside the raw preference keys that ties the certificate to the escrow info. If this is not correct then the profile will not deploy at all.

You are looking to match EncryptCertPayload UUID in com.apple.security.FDERecoveryKeyEscrow with the PayloadUUID of the com.apple.security.pkcs1 section.

Now that you’ve done that and made your considerably shortened mobileconfig file, there’s another issue to deal with.

Jamf Pro has a nasty habit of interfering with and changing even manual profile settings. In particular anything with FV2 keys. We must stop this. Rather than spell this process out, I’ll hand over to someone who’s already done it and done it very well: Matthew Warren.

https://www.macblog.org/post/signing-configuration-profiles

By the end of all of this you should have a re-signed mobileconfig file that you can upload to your JSS that ONLY sets keys to do with key escrow. One major source of profile conflicts and clashes dealt with and everyone is hopefully happier as a result!

Well you did test in non production right? You did? Cool!

Except your JSS because it now can only deploy your new profile and isn’t happy about it! I can live with that.