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

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>"

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

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

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

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

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

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

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

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.

@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

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!

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

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

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

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