macOS High Sierra 10.13 introduces a new feature that requires user approval before loading newly-installed third-party kernel extensions.

[donmontalvo]

My apologies, this is likely covered by NDA...moving to BETA forum.

Jamf: any way to mask subject to avoid wrath of Apple? :D:D:D

https://www.jamf.com/jamf-nation/discussions/24744/macos-high-sierra-10-13-introduces-a-new-feature-...

[donmontalvo · Accepted solution]

Hot off the press:

Prepare for changes to kernel extensions in macOS High Sierra
https://support.apple.com/en-us/HT208019

[emily · Accepted solution]

In macOS High Sierra, enrolling in Mobile Device Management (MDM) automatically disables SKEL. The behavior for loading kernel extensions will be the same as macOS Sierra.

The implication here is that if macOS sees MDM present, it disables SKEL. In a future version, it will be something that MDM can turn on/off/manage and allow whitelisting. I guess we complained loudly enough about it that Apple made some changes.

[KyleEricson]

@PhillyPhoto I totally agree this is pointless.

[beatlemike]

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.

[HNTIT]

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.

[beatlemike]

@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.

[HNTIT]

@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

[beatlemike]

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.

[allanp81]

@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?

[HNTIT]

@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

[ed_grof]

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

[HNTIT]

Odd, new builds via DEP are fine, still testing

[MatG]

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

[HNTIT]

I have found that applying the Kernel Extensions policy at build wont work for Non DEP, because of the User Approved MDM Profile issue, which I cannot automate.

I have had to use an Extension Attribute that shows when the MDM Profile has been approved, and then make a Smart Group based on that to trigger the Deployment of the Config Profiles with my Kernel Extensions in it. Seems to have fixed it so far for new deployments.
Any machine that tries to apply the Kernel Extensions Profile before MDM is approved always fails to apply even if you try to remove and re add the profile.

Annoying but at least its a sort of fix.

Extension Attribute posted below incase anyone needs it.

#!/bin/bash

# Jamf Pro extension attribution which reports if user-approved
# mobile device management is enabled on a Mac.

UAMDMCheck(){

# This function checks if a Mac has user-approved MDM enabled.
# If the UAMDMStatus variable returns "User Approved", then the
# following status is returned from the EA:
#
# Yes
#
# If anything else is returned, the following status is
# returned from the EA:
#
# No

UAMDMStatus=$(profiles status -type enrollment | grep -o "User Approved")

if [[ "$UAMDMStatus" = "User Approved" ]]
    then
        result="Yes"
    else
        result="No"
fi
}

# Check to see if the OS version of the Mac includes a version of the profiles tool which
# can report on user-approved MDM. If the OS check passes, run the UAMDMCheck function.

osvers_major=$(/usr/bin/sw_vers -productVersion | awk -F. '{print $1}')
osvers_minor=$(/usr/bin/sw_vers -productVersion | awk -F. '{print $2}')
osvers_dot_version=$(/usr/bin/sw_vers -productVersion | awk -F. '{print $3}')

if [[ ${osvers_major} -eq 10 ]] && [[ ${osvers_minor} -ge 14 ]]
    then
        UAMDMCheck
    elif [[ ${osvers_major} -eq 10 ]] && [[ ${osvers_minor} -eq 13 ]] && [[ ${osvers_dot_version} -ge 4 ]]
        then
            UAMDMCheck
    else

# If the OS check did not pass, the script sets the following string for the "result" value:
#
# "Unable To User-Approved MDM On", followed by the OS version. (no quotes)

        result="Unable To Detect User-Approved MDM On $(/usr/bin/sw_vers -productVersion)"
fi

echo "<result>$result</result>"

[jelockwood]

@HNTIT I found the same issue and a similar solution, however there is actually a built-in criteria you can use to create the smartgroup which is as below.

I therefore have a smartgroup with the above criteria and only deploy the Kernel Extensions policy to machines which match this criteria.

[allanp81]

@jelockwood @HNTIT I've seen instances here where my config profiles with kext whitelist fails to be delivered to a machine and sits as a failed command. It then never applies to a machine without manually clearing this failed command.

Have you seen anything similar? I've got a method using the API to easily identify any machines affected like that but it's a pain nonetheless.

[jelockwood]

@allanp81 Yes we just had that happen today - we are still in the early days of using this particular feature.

There does not seem to be an option to clear the failed command, the solution is to edit the Configuration Profile but not to make any changes and then click the save button, when you click save you get the option to push it out again to devices missing the profile. This then in my case was successful on the Mac that had previously failed.

[allanp81]

@jelockwood We can clear them easy enough manually, but I don't think the API has the capability to do this otherwise it would be really simple. They can probably be cleared via the DB but that's obviously a bit drastic.

[jelockwood]

@allanp81 I am not seeing the need to do this via the API. You can see in the JSS console if there is a failure and if there is you can as I describe trigger a new attempt by editing the Configuration Profile, not making any changes but then saving and re-pushing the Configuration Profile.

[allanp81]

@jelockwood what do you do if you have 100s or 1000s of machines though, potentially with quite a few showing the issue? I've always seen issues with updating config profiles and always wary of making any changes to them!

[jelockwood]

@allanp81 If there are lot of failures then the problem needs to be investigated, in this case it might be down to trying to push the Kernel Extension whitelist profile to a machine that has not done User MDM Approval - this is solved by scoping the profile to only machines that have done User MDM approval via a smartgroup.

It is possible to trigger an attempt to re-push the profile as previously described. This does not need a real change to be made to the profile - the mere action of saving it is enough.

Again I am not sure how using the API in this case is relevant or helpful. I am sure in other cases it is, I use the API myself to implement LAPS - Local Admin Password Solution to randomise, rotate and store in JSS local admin passwords. See https://github.com/unl/LAPSforMac.

If the concern is making a change to a Configuration Profile and worrying about it going wrong then you should first create a new Configuration Profile and scope it to a single test machine, once you know it is working properly then you can replicate this for the rest of your fleet.

[allanp81]

I have it scoped to a smart group based on enrolment status, that part works fine but sometimes in my testing I'm still seeing failures where the inventory status of the machine shows approval is yes when in fact it isn't.

[donmontalvo]

@HNTIT excellent script, thanks for sharing.

Is there a way to identify computers that were enrolled as macOS lower than 10.13.x?

Those computers would be "grandfathered in" and won't show an MDM Profile allow button.

FWIW, opened a ticket with Apple Enterprise Support (100524749425), to see if there is additional criteria we can use to exclude grandfathered in computers.

Thanks,
Don

[bearzooka]

Hey guys!

I'm at a loss here, looking for a way to "remove approval" of already user approved kexts.

This is something I've been asked to figure out in order to test a Config Profile based workflow as well as to have a way to revert potentially damaging changes that users may do.

Thanks!

[bcbackes]

@HNTIT I see your post about the Kernel extension, however, I'm not that experienced with Apple products or Jamf. How do I create a profile in Jamf that uses that information?

Thank you for all the help!

[donmontalvo]

@bearzooka ran into this yesterday. When a computer is Thin Provisioned (*), and McAfee is installed before the technician gets a chance to approve the MDM Profile. The user is prompted to manually accept the McAfee KEXT.

I'm opening a ticket with Jamf to see if manually approving a KEXT may case any problems going forward (race condition since we are whitelisting it). Will post response.

(*) A computer is enrolled in Jamf Pro, then a bunch of policies kick in to enforce CIS/MSB/SCS, install software, etc., leaving the installed macOS intact.

[donmontalvo]

@bcbackes would suggest calling Jamf, or hiring someone who is experienced and certified...not worth the risk trying to wing it. :)

[mark_mahabir]

@donmontalvo We have the same issue with Sophos. We don't do DEP yet and our techs approve the MDM Profile on delivery with the customer. I haven't seen any issues with this as yet.