Existing Kernel Extension policy not respected on update to 10.13

Number:rdar://39209026 Date Originated:05-Apr-2018 11:18 AM
Status:Open Resolved:
Product:macOS + SDK Product Version:10.13.4 17e199
Classification:Serious Bug Reproducible:Always
Start with 10.12.6 enrolled in MDM and has a Kernel Extension Policy (PayloadType = com.apple.syspolicy.kernel-extension-policy) whitelisting approved Team Identifiers (including G7HH3F8CAK for this example) delivered via the MDM.

After upgrading to 10.13.4 (17E199) the MDM enrollment and KEXT profile are still installed and "Verified" per System Preferences->Profiles, yet when I try and load a KEXT from an approved vendor (Dropbox) I still get prompted by the system to allow the extension in the System Preferences.

In this example I'm signing into Dropbox and enabling the Smart Sync capabilities which use a KEXT. The Team Identifier is G7HH3F8CAK and can be seen in the whitelist. 

The prompt to allow the KEXT should not appear and the KEXT should load automatically which is not happening.

Steps to Reproduce:
0) Setup a computer with < 10.13.2 that has never run Dropbox before 
1) Enroll the < 10.13.2 OS into MDM and apply a Kernel Extension Policy (PayloadType = com.apple.syspolicy.kernel-extension-policy) approving just the Team Identifier G7HH3F8CAK in this example.  Choose whatever TeamID you have a KEXT for. 
2) Upgrade the computer to 10.13.4 via App Store update 
3) Authenticated restart signs the user back in after installing 
4) Sign into a Dropbox account that has Smart Sync capabilities to have it load the KEXT

Expected Results:
The Dropbox KEXT would load during the setup process without user interaction since it is approved via com.apple.syspolicy.kernel-extension-policy.

Actual Results:
The system prompts the user to allow the Dropbox KEXT in System Preferences->Security during the setup process

10.13.4 17e199

I setup a brand new machine using 10.13.4 as the starting OS, activating in DEP, enrolling in the MDM and getting the KEXT policy. 
KEXT policy _IS_ respected and does not prompt to allow TeamID whitelisted kexts.
I upgraded a 10.12.6 machine with UAMDM and KEXT policy to 10.13.4, logged in as a user
KEXT policy _NOT_ respected
I upgraded a 10.12.6 machine to 10.13.4. Before logging a user in I restarted the computer again to verify it was a clean restart and not an authenticated restart from the installation process.
KEXT policy _NOT_ respected
I upgraded a 10.12.6 machine with UAMDM and KEXT policy to 10.13.4. Before logging a user in I made a change to the KEXT policy in the MDM, verified that 10.13.4 received the new MDM payload changes, then logged in as a user
KEXT policy _IS_ respected
Even though the 4th testing workflow resulted in positive results the process of having to change the MDM payload to get there is not acceptable but sheds some light on the issue.



This is affecting us, as well.

By austin.culter at Oct. 11, 2018, 7:22 p.m. (reply...)

From Apple:

From Apple: At this time, I don’t know if Product Engineering will be able to address this in an update to the High Sierra product. Your workaround may be the best way to address this in the near term.

If your fellow Mac admins are also running into this, please ask them to submit cases via their Enterprise Support contract.

If they don’t have a contract, their SE’s may be able to provide them with an incident so they can submit a case.

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!