As part of macOS 10.13.2, Apple introduced the concept of User Approved MDM Enrollment (UAMDM). UAMDM grants mobile device management (MDM) additional management privileges, beyond what is allowed for macOS MDM enrollments which have not been “user approved”.
As of macOS 10.13.4, the only additional management privilege associated with UAMDM is that it allows you to deploy a profile which provides a whitelist for third-party kernel extensions. This profile allows a company, school or institution to avoid the need to have individual users approve the running of approved software.
Without the profile, third-party kernel extensions will need to be approved through the User-Approved Kernel Extension Loading (UAKEL) process. Here’s how that process looks:
1. When a request is made to the OS to load a third-party kernel extension which the user has not yet approved, the load request is denied and macOS presents an alert to the user.
2. The alert tells the user how to approve the loading of the kernel extension signed by a particular developer or vendor, by following this procedure:
A. Open System Preferences
B. Go to the Security & Privacy preference pane
C. Click the Allow button.
Note: This approval is only available for 30 minutes. After that, it disappears until the following happens:
i. The Mac restarts
ii. Another attempt is made to load the kernel extension.
While waiting for the kernel extension to be approved, a copy of the kernel extension is made by the operating system and stored in the following location:
/Library/StagedExtensions
Once approved, another copy of the kernel extension is made and allowed to load.
This process is relatively easy for an individual to manage on their own computer, but it would be very difficult to manage when dealing with more than a handful of Macs. To help companies, schools and institutions, Apple has made a management profile option available to centrally approve third-party kernel extensions. For more details, please see below the jump.
To help whitelist all kernel extensions from a particular vendor or whitelist only specific ones, Apple has made two sets of identifying criteria available:
- Team Identifier
- Bundle Identifier
Team Identifier
A team identifier is a alphanumeric string which appears similar to the one shown below:
7AGZNQ2S2T
It appears to use a developer or vendor’s Developer ID for Signing Kexts certificate identifier. This certificate would be used by a developer or vendor to sign all or most of their kernel extensions.
Whitelisting using the Team Identifier has the advantage of being able to whitelist multiple third party kernel extensions from a specific developer or vendor. This capability allows Mac admins to identify a particular developer or vendor as being trusted in their environment and have all of the relevant kernel extensions be allowed to load by the whitelist.
Note: The UAKEL process appears to use team identity when approving kernel extensions, which potentially allows multiple kernel extensions to be approved at once.
Bundle Identifier
The Bundle Identifier is specific to a particular kernel extension. It is contained in the Info.plist file stored inside each kernel extension.
Whitelisting using the bundle identifier allows the Mac admin to get very granular about which kernel extensions from a specific developer or vendor are approved and which are not. If using the bundle identifier as part of the whitelist, both the Team Identifier and the Bundle Identifier need to be specified in the profile.
To help Mac admins, a community-written Google Doc spreadsheet is available here which lists various team identities and their associated bundle identifiers:
https://docs.google.com/spreadsheets/d/1IWrbE8xiau4rU2mtXYji9vSPWDqb56luh0OhD5XS0AM/edit?usp=sharing
(Hat tip to Contains_ENG for creating the document and developing a script to detect the relevant kernel extension info.)
Using Team Identifier by itself in a third-party kernel extension whitelist profile
If you want to use only the Team Identifier when whitelisting kernel extensions, the profile should be written as shown below:
On the individual Macs which receive the profile, it should show up looking similar to this:
Using Team Identifier and Bundle Identifier in a third-party kernel extension whitelist profile
If you want to use both Team Identifier and Bundle Identifier when whitelisting specific kernel extensions, the profile should be written as shown below:
On the individual Macs which receive the profile, it should show up looking similar to this:
If you’re using Jamf Pro to deploy a third-party kernel extension whitelist profile profile, it should appear as a built-in profile option. Here’s how it should appear if using only team identifiers:
If using both team identities and bundle identifiers:
