Apple has introduced a new concept with macOS High Sierra, User Approved MDM Enrolment. This will only affect the management of settings that Apple deemed to be considered ‘security-sensitive. All other non-sensitive settings will continue to work, as previously, without User Approved Enrolment. This does not affect devices enrolled through DEP.
There are two aspects to this.
User Approved MDM Enrolment
Configuration Profile payloads that will require User Approved MDM Enrolment.
The first payload Apple has announced that will use these features is the Kernel Extensions payload.
Unlike other payloads, any ‘security-sensitive’ payload will be deliverable only by MDM and will rely on the MDM enrolment being User Approved.
User Approved MDM Enrolment
Currently, User Approved MDM Enrolment relies on the device being enrolled; the method of enrolment does not matter yet but will do in future releases. At this point, the enrolment must be either:
DEP enrolment (user approval not required)
User installing the enrolment profile manually
User accepts the enrolment profile through System Preferences > Profiles:
You will notice this approval box in 10.13.2, if the method of enrolment was hidden from the user, e.g. scripted. Devices enrolled on earlier versions and then upgraded will automatically be MDM enrolled as User Approved.
Apple introduced a halfway house with the release of 10.13. Apple has now released version 10.13.4 which has full implementation of this feature.
How does this affect kernel extensions?
Attempts to install a Kernel Extension with a device that is not enrolled into MDM will be greeted with the following message:
To approve the Kernel Extension will either require MDM enrolment or the user allowing the blocked Extension to run, via System Preferences > Security & Privacy > General:
What happens if I already have kernel extensions installed?
Any extension installed prior to upgrading to 10.13 High Sierra will continue to work, only newly installed kernel extensions will be affected.
Once a particular kernel extension is approved, subsequent upgrades to that kernel extension will automatically be user-approved.
Managing Kernel Extensions through MDM
Prior to version 10.13.4, there is no management beyond having the device enrolled into MDM. However, with 10.13.4, management is now available through the Kernel Extension Policy payload, allowing extension loading without user consent when enrolled appropriately; the payload can only be delivered with MDM, to devices that are User Approved MDM Enrolled. This could result in apps relying on kernel extensions to stop functioning properly (e.g. VPN clients, antivirus software).
As of FileWave version 12.7.0, the Kernel Extensions payload was introduced. To allow Kernel Extensions requires either:
Individually using the 'Kernel Extension bundle ID'.
These values are stored locally on a device after installation. Therefore, to find these values involves installing them on a device and then reading these values from a file, e.g., for a machine that has VMware Tools installed. One machine could have all Extensions installed prior to running the command to list all necessary Kernel Extensions.
This lists the Team Identifier followed by the Bundle ID for two Kernel Extensions that have been added with the installation of VMware Tools. Both have the same Team Identifier, but have differing Bundle IDs.
To just use Team Identifier, add the returned Team Identifier from the command for the Kernel Extensions you wish to approve, to the 'Allowed Team Identifiers' whtielist. All Kernel Extensions with this Team Identifier will be whitelisted.
To only allow certain Kernel Extensions, instead use the 'Allowed Kernel Extensions' whitelist and add both Team Identifier and Bundle ID. Note, legacy Extensions may not have a Team Identifier. For those that don't, just supply the Bundle ID and leave the Team Identifier empty.
There is also a community of users that are adding Identifiers and Bundle IDs which could save you having to instal in advance.
Community Kernel Extensions List
Data in this list is not checked in any way. As this is in place for security reasons and anyone can add information to this file, use with care:
N.B. This is stored in NVRAM. If you reset the NVRAM, you will lose the ability to use User Approved Kernel Extension loading with this method until the steps are retraced. A firmware password could be set to prevent unauthorized NVRAM resets.
The Extensions payload should not be confused with the Kernel Extensions payload.