Last updated May 7, 2019
Deploying Kernel Extension or Privacy Preferences Policy Control profiles to your macOS devices? Read this article to ensure that these configurations are available immediately upon OS update.
When upgrading macOS, some previously installed configuration profiles may become effectively ignored. This article explains the behavior, the reason for it, and how we’ve designed SimpleMDM so that our customers can avoid this pitfall in their deployment.
Starting with High Sierra 10.13.2, Apple introduced the concept of Secure Kernel Extension Loading (SKEL). SKEL is a macOS service that acts as a security gatekeeper, only allowing the execution of third party kernel extensions that have been pre-approved. Kernel extensions can be approved by the user interactively or can be whitelisted by a SimpleMDM administrator via configuration profile. You can read more about kernel extension whitelists in our article What is User Approved MDM Enrollment? by scrolling to the section entitled “How do I Whitelist Kernel Extensions with SimpleMDM?”.
The kernel extension configuration profile, however, does not act as the source of truth on a macOS instance. Rather, when the profile is installed, the configuration is imported to a separate local database called the System Policy Configuration – Kext Policy (KPDB). macOS refers to this database when deciding if a kernel extension is entitled to run or not. This causes a complication in the following scenario:
This issue can be difficult to debug. macOS shows a valid kernel extension configuration profile installed, however, the settings in the profile are not actually being honored.
So, why not wait to install the profile once 10.13.2 is detected? While this avoids the problem of installing a profile that macOS cannot yet process, it does not ensure that the profile is available immediately upon OS update. We will address this issue in a moment.
macOS Mojave (10.14) introduces a gatekeeper for gaining access to cross-application data like Contacts, Calendar, and Photos, hardware like the camera and microphone, and important system files. This gatekeeper is a similar paradigm to the gatekeeper used for kernel extensions. Likewise, it has a separate database for tracking approved access. Despite this functionality still being in beta, Apple has publicly announced the change to provide a heads up for system administrators.
The same issue exhibited with kernel extension profiles and OS updates applies here as well. For instance, if a TCC whitelist profile is installed to an instance of macOS High Sierra 10.13.6 and then upgraded to Mojave 10.14, the profile is essentially useless despite remaining installed.
The FileVault configuration payload includes a feature called deferment, with which an admin can permit a user to delay the FileVault encryption process until the next boot of the OS. Additionally, the FileVault configuration can specify that the recovery key is to be escrowed or stored, with the MDM provider.
Between macOS Sierra (10.12) and macOS High Sierra (10.13), the mechanism for delivering the recovery key to MDM changed. As a result, the FileVault configuration payload format also changed. While the additions to the payload can be delivered to Sierra ahead of time, they will not become effective when the device updates to High Sierra or beyond.
This behavior and the deferment option conflate to cause an issue for admins. If the profile is installed on a Sierra instance, the user defers FileVault encryption, and then the user updates of High Sierra, High Sierra will not know how to escrow the recovery key.
In order to “reactivate” a profile, it must be reinstalled on the device. When SimpleMDM detects that the installed OS has updated, it will automatically reinstall any profiles that may be affected by an OS update. SimpleMDM is able to check for an OS update each time the device checks in for an inventory update.
However, a problem of timing still exists. macOS does not notify SimpleMDM, natively, when an update has occurred. This can cause a gap in time between an OS update and when the profiles become active. This introduces two problems:
To solve this problem, a script may be installed to the device that notifies the SimpleMDM service when an OS update is occurring. With this script installed, SimpleMDM will automatically reinstall any necessary profiles during the OS update process, before the login screen is displayed for the first time. Thus, subsequent automated processes and user interactions are not affected by inactive profiles.
If you are a SimpleMDM customer and would like to utilize the script in your deployment, please contact support. We have a packaged version that can be automatically deployed to your fleet using SimpleMDM.