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.
Kernel Extensions and High Sierra
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.
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:
Computer running macOS Sierra 10.12 receives and installs kernel extension profile. The profile is installed, but the whitelist is not imported into the KPDB as it does not exist in this version of macOS.
Computer is updated to macOS High Sierra 10.13.2 or later. The profile remains installed, however macOS does not import the whitelist data to the KPDB.
When trying to run software or automated processes after update, the whitelist in the configuration profile is not honored and either prompt the user, or worse, fail.
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.
TCC, Access Controls, Privacy Preferences Policy Control, and Mojave
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.
Learn more about TCCs in How to configure Privacy Preferences profile (PPPC / TCC) in SimpleMDM. |
|---|
FileVault Deferment with escrowed recovery keys and High Sierra
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.
How does SimpleMDM fix this?
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:
A user’s first experiences using the new OS is confusing when they can’t run their desired application, a new, unfamiliar permissions prompt appears, or some element of the application is rendered inoperable.
An automated software install, intended to run after OS update, is not able to run.
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.
