Since I and my coworkers personally touch each Mac as it's being enrolled using a quickadd package, this has not been as horrible as I thought it would be. The only annoyance has been that I scope a configuration profile that blocks the Profiles preference pane from being opened, so we have to wait to deploy the configuration profile after we have approved the MDM profile.

I asked earlier in this thread how someone goes about getting an Apple SE. I would really appreciate it if someone could answer that question. People keep telling me to talk to my Apple SE and I don't have one!

@howie_isaacks We do the same with the preference pane blocking, and I had to change how it is deployed as well. With machines were my team sets them up, this is not an issue, however we could never get to all our older machines if that was the only way to enroll them.

Being an education institution we just have always had an SE. That's all I've worked for since I left Apple. I couldn't tell you were to start to get one, wouldn't hurt to call Apple yourself.

Any solutions on this?
I'm testing 10.13 now before we do a district wide refresh this summer and running across this problem that after imaging I have to log in and manually "Approve" the config profiles.
I tried DEP but for these graphic design computers we really need all the Adobe and video editing software PRE-INSTALLED before it ever gets to the students so a netboot and configuration task sequence is the best way to push this all at once.

You can manage them through an MDM profile. Not sure if Jamf 10 supports that just yet (I'm still on 9 and we're not deploying 10.13 yet)

Managing KEXT white listing isn't limited to JSS 10.x.

We're hoping Jamf Pro 10.4 (long ways away) will inventory KEXT across the macOS computer, so the data can be used to create a white list within Jamf Pro. #shinyButton

No need to wait though, since you're able to use a Configuration Profile with a KEXT whitelist using TeamID (vendor) or TeamID and BundleID (vendor and KEXT).

• If you whitelist by TeamID (vendor), then all BundleIDs (KEXT) for the vendor are whitelisted.


• If you whitelist by TeamID and BundleID, every KEXT from that vendor that you want to allow will need to be included in the whitelist. Every. Single. One. Else, any non whitelisted KEXT for that vendor will not load.

We've been working on...

1. Create whiltelist on a computer using @franton's awesome script, which creates an XML you can import into a Configuration Profile (Custom Settings).




2. Use @henryxyz's sqlite3 command to list of TeamID/BundleID for KEXTs that have been approved (User Approved Kernel Extension Loading) and save as CSV. From there, you'll have a way to collaborate/share the list with your colleagues, and Security who may be tasked with approving KEXTs now that it's a security thing.




3. Open a ticket with Jamf to see if we can import a TeamID/BundleID into a Configuration Profile using API...if so, we can update the CSV and re-upload to globally allow the KEXTs. #aGuyCanDream




4. Make a lot of coffee (Bustello por favor...varoom!!! ️ ️ ️ ), and try to come up with a script that can merge the CSVs in #3. Hoping it's as simple as I think it should be.

Script to pull a list of TeamID/BundleID for KEXTs that have been approved (User Approved Kernel Extension Loading):

#!/bin/sh

# Stealing @henry123's (Jamf Nation) command to compile list of TeamID/BundleID for KEXTs that have been approved (User Approved Kernel Extension Loading). 20180313 DM



# Create folder

/bin/mkdir -p /Library/Company/SearchResults/

/usr/sbin/chown root:admin /Library/Company/SearchResults/

/bin/chmod 755 /Library/Company/SearchResults/



# Get list



/usr/bin/sqlite3 -csv /var/db/SystemPolicyConfiguration/KextPolicy "select team_id,bundle_id from kext_policy" > /Library/Company/SearchResults/checkKEXTs.csv



exit 0

EA to display the CSV created by the above script...yea...we know line returns are bonked in EAs...but for what it's worth:

#!/bin/sh



folder=/Library/Company/SearchResults

file=checkKEXTs.txt

list=$( cat ${folder}/${file} )



if r  ${list} == "" ]]; then

    echo "<result>"NoResult"</result>"

else

    echo "<result>"${list}"</result>"

fi

The CSV would look like this (heavily redacted/sanitized) when you cat it:

# cat /Library/Company/SearchResults/checkKEXTs.csv 

4C6364ACXT,com.parallels.kext.hypervisor

4C6364ACXT,com.parallels.kext.netbridge

4C6364ACXT,com.parallels.kext.usbconnect

4C6364ACXT,com.parallels.kext.vnic

6HB5Y2QTA3,com.hp.kext.io.enabler.compound

EG7KH642X6,com.vmware.kext.vmci

EG7KH642X6,com.vmware.kext.vmioplug.15.2.1

EG7KH642X6,com.vmware.kext.vmnet

EG7KH642X6,com.vmware.kext.vmx86

GT8P3H7SPW,com.McAfee.AVKext

GT8P3H7SPW,com.McAfee.FMPSysCore

GT8P3H7SPW,com.McAfee.SFKext

GT8P3H7SPW,com.McAfee.kext.AppProtection

Jamf Pro would display that file (list) in an EA like this:

4C6364ACXT,com.parallels.kext.hypervisor 4C6364ACXT,com.parallels.kext.netbridge 4C6364ACXT,com.parallels.kext.usbconnect 4C6364ACXT,com.parallels.kext.vnic 6HB5Y2QTA3,com.hp.kext.io.enabler.compound EG7KH642X6,com.vmware.kext.vmci EG7KH642X6,com.vmware.kext.vmioplug.15.2.1 EG7KH642X6,com.vmware.kext.vmnet EG7KH642X6,com.vmware.kext.vmx86 GT8P3H7SPW,com.McAfee.AVKext GT8P3H7SPW,com.McAfee.FMPSysCore GT8P3H7SPW,com.McAfee.SFKext GT8P3H7SPW,com.McAfee.kext.AppProtection

Off to do #3 and #4...I'm good until the Bustelo wears off...

HTH
Don

Has anyone successfully managed the kext whitelist using a custom profile payload? I've only been able to do it with 10.2.2 since it offers it natively, but 9.101.4 just won't work. The profile is installed by user-approved MDM but it just isn't taking effect.

I'm just trying to wrap my head around this issue. So 10.13.* now requires users to let kernel extensions to be enabled. This behavior can be bypassed by enrolling the device in an MDM, or installing a config profile with a payload whitelisting teams or specific Kexts, but you don't need both, correct? I've had no need to install the white list profile and my AV software installs fine when building devices. So my question is, the whitelisting would only be for devices you don't want to enroll completely in the MDM for some reason?

When I run the script @donmontalvo posted above, I don't get any results, since they were installed via policy on an MDM-enrolled device. Even looking directly at the kext_policy DB, it's empty:

If I run the script from Richard Purves' blog, I see all my kexts that are actually installed.

For those of us enrolling our devices in the MDM, is this just to prepare us for when Apple finally transitions everyone over to having to whitelist kexts regardless of MDM enrollment? I just want to make sure I'm not misunderstanding the issue and not configuring devices correctly.

@PhillyPhoto

The only "bypass" for this (SKEL) is DEP. Jamf's new 10.3 Profile enrollment process still require a whitelist config profile. I think most places are going to need both DEP and a whitelist config profile as DEP won't work everywhere.

C

@gachowski
In my testing it looks like non-DEP MDM profile based (instead of QuickAdd) User Initiated Enrollment (in 10.3) produces UAMDM, and as such the SKEL config profile is allowed to be installed like any other profile would be at enrollment, and before any apps which need it are installed.

Yep, that is what I was trying to say... : ) sorry while english is my 1st language typing and writing are not . : )

C

I created a profile for Sophos AV and it doesn't do anything. This is a non-DEP mac where I approved the MDM profile.

@kericson Have you checked on the management for the device in the JSS? In my environment it fails to install the kext policy because the MDM profile needs user acceptance. Even after approving MDM the config profile stays under a failed status and therefore never applies to the machine until I go in and manually clear the error.

As it is I can't see how we can roll out High Sierra in this state. We don't use DEP and are unlikely to for general imaging of our mac rooms.

I checked and it installs fine without any issues just doesn't do anything.

I've tested upgrading a device to 10.13.4 and then installing the kext profile. Even with approving the MDM profile and seeing the correct whitelist profile get installed and finally rebooting, I still get prompted to allow kernel extensions. What's the point of this whitelist profile if it doesn't actually work?

@PhillyPhoto I totally agree this is pointless.

Weird you all are having issues. Mine just seems to work.

You do need to approve the MDM profile on non DEP systems, but we have been doing that since we began deploying High Sierra 10.13.2, we have found a couple we missed admittedly since pushing the kext profile. But we approved them and no issues.

We can complain to Apple this is dumb, securing the system, but it's really these third parties that have not heeded Apple's warnings about the impending change that we should complain to. It's not like they were blindsided by this, I'm just glad we have a temporary fix to allow our AV software and video conferencing software to work.

Having the same Issue.
@beatlemike It is APple we need to complain to, not the 3rd Parties, basically any software that requires a Kernel Extension (AV software etc) will need to be whitelisted, the only exception ? ......... Drum Roll please ........ Apple.

It's not that the 3rd Parties were blindsided, there is just nothing they can do without a ground up rewrite of their software, if even that would get around the problem. Apple haven't bothered to rewrite their own software that requires extensions, they have just excluded themselves from the issue, which is actually more worrying as they themselves are now the least secure company using a kernel extension.

@HNTIT Do what ever makes you happy, don't let me tell you how to live your life.

But, yes, High Sierra introduced a new feature that requires user approval before loading newly-installed third-party kernel extensions. With Jamf 10.3 I can enroll my new non-DEP 10.13.4 and systems without needing to do that extra step. My kernel extension whitelist works as it should based on what Apple now allows. I just followed what everyone on here has mentioned so far.

An Apple OS with only Apple kernel extensions would be great, a world with no kernel extensions would be ideal.

@beatlemike apologies if my previous post caused any annoyance or offence. Ever since High Sierra appeared on the first device in our estate it's been making our lives hell, possibly on a bit of an Apple bashing kick right now.

I am confused as to why it is not working for me.

I have test Machines on 10.13.4 both DEP and Non-DEP (but MDM Profile Authorised)
My JAMF Pro was updated to 10.3.1 over the weekend, and I have removed and Re-Applied the Kernel Extension Policy (Image Attached) and yet even after multiple reboots, users are being prompted for this (and other) Kernel Extensions

No worries, tensions are high on the subject, we shall overcome lol

I know it says the bundle IDs are optional, but I include them. That's the only difference in mine. I actually was asked to approve one when I left one out of the 3 that ESET installs.

@HNTIT Have you confirmed under the profiles section in system preferences that it's been applied? Or under the management tab on the tab device on the JSS?

@allanp81 Yep the profile is deployed successfully.

I will try adding the bundle ID's as @beatlemike suggests, I did have them in before but not 100% I had it all correct back then so will re-test

I noticed no references as to how to do this with Jamf 9.101.4. Am I right to assume I would need Jamf Pro?

If you are wondering why we are not on Jamf Pro, we tried, but a number of features we rely on are not implemented/buggy on Jamf Pro which prevents us from making the leap.

Ed

Odd, new builds via DEP are fine, still testing

@ed_grof I believe you need at least Jamf 10.2.x