Unknown Keys in Configuration profiles after 10.31 update

[RPA_Sma4]

After our server was updated to 10.31 the unknown keys feature is presenting itself in a number of profiles. At first all unknown keys were "payloadenabled" which per the release notes can be safely removed.

However, now a number of the profiles have more keys showing as unknown, and I can't find any documentation on what they are or whether they can be removed or not.

All of these profiles are standard Jamf profiles created within JSS.

Keys include:

1. allowKeyboardActivityContinuation in Mobile Device Restrictions profile

2. com.apple.MCX.FileVault2:

• UseKeychain
• UserEntersMissingInfo in Computer Security & Privacy profile

Is anyone familiar with what these keys do, and if they can be removed without affecting the profile? No changes have been made to these profiles, and they were all created in Jamf.

Thank you

[ljcacioppo · Accepted solution]

This Apple article defines those keys:
https://developer.apple.com/documentation/devicemanagement/fdefilevault

I ended up creating a new fielvault profile after upgrading to 10.30 since they changed it where it could be separated from the other security and privacy profiles

[jtrant]

@ljcacioppo, I'm assuming you un-scoped the old profile and then scoped the new one? Any impact on your endpoints?

[ljcacioppo]

I wasn't using many keys in the profiles I recreated because I like to keep them as individualized as possible. But I did recreate the ones enforcing filevault and key escrow, removing the old one and applying the new without any issue on my endpoints.

[bradtchapman]

Some people with old Jamf environments might have a problem if they merely edit / reuse the existing FileVault profiles. (Remember when you had to do this in 2017 for the new keys in 10.13?).

I've just discovered that an 'original' FileVault profile has a serious problem. The Security & Privacy payload refers to a FileVault Recovery Key Escrow Certificate.  When examining this profile deployed to a Mac, that certificate appears to be expired.  The duration was 1827 days, or 5 years + 1 day. 

An expired FV2 escrow certificate will prevent a Mac from starting or enforcing FileVault encryption, even if the profile as a whole is verified and installed properly.

Meanwhile, if I go to create a brand new FileVault 2 profile in Jamf Pro today, that workflow adds a new certificate payload with "FileVault2Comm.cer," a very clear expiration date.  In our case, that certificate won't expire for about 4 years from now.

For context: our on-premises environment was first built and activated Tuesday, January 24, 2017.  A premium / custom migration to Jamf Cloud would not have helped any legacy environment, because that process is tantamount to a database transfer, new SSL certs, and some new DNS records to point your clients to the cloud.  The old profiles would have persisted.

Keep in mind that macOS happily accepts the whole profile as "Verified" because it's been signed by the Built-in CA that has a 10-year lifespan.  There's also no obvious warning in the Jamf policy or profile logs about the certificate being expired, since it's not a condition that macOS would summarily reject.  I don't know if this was an oversight by Jamf—that customers needed to ditch their FV2 profiles and create new ones—or something we missed in the upgrade documentation for 10.31.  There were very clear notes about unknown payload keys — lots of people had those.

Thanks to the MacAdmins Slack, I have discovered that the expired certificate is a known Product Issue:

PI-008323 - Configuration profiles created before the signing certificate expiration are not updated with a new FilevaultComm2 cert

---

There is another issue with the Jamf UI that might have prevented even the most careful admin from spotting the problem...

If you have an existing FileVault 2 profile created pre-10.31, when you inspect it in the console you might not see any Certificate payload, even when clicking [Edit] and saving changes to it.  If you click the "Certificate" payload, it appears empty and unconfigured.  I had to actually click the Configure button as if I were adding a new certificate.  Once the page reloaded, I could now see the existing FV2 Escrow Certificate AND a slot for a new blank certificate.  Here's where it gets extra weird: if I delete the new blank item, the payload reverts to an "unconfigured" state —even in the Edit view.  So the FV2 Escrow Cert remains invisible.

I've opened a support case for this.