Skip to main content
Jamf Nation, hosted by Jamf, is a knowledgeable community of Apple-focused admins and Jamf users. If you like what you see, join us in person at the ninth annual Jamf Nation User Conference (JNUC) this October for three days of learning, laughter and IT love.

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

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-that-requires-user-approval-before-loading-newly-installed-third-party-kernel-extensions

Like Comment
Order by:
SOLVED Posted: by nwiseman

[http://blog.eriknicolasgomez.com/2017/07/25/Kextpocalypse-High-Sierra-and-kexts-in-the-Enterprise/](link URL)

I just sent in feedback to Apple and contacted our Apple TAM about this.

I'd say we all need to do the same. Relying on users to "Allow" something we as Admins are trying to install on their systems is a huge concern. If this is the direction Apple wants to go, that's fine, but there needs to be some way for us to continue doing our jobs.

I may not like SEP, but it has to be on my systems. This new feature is going to make that a much bigger problem than it already is.

Like
SOLVED Posted: by jhbush1973

@donmontalvo I don't think you are breaking NDA based on the location of this. Technical Note TN2459
Secure Kernel Extension Loading

Like
SOLVED Posted: by donmontalvo

Lots of folks are not happy about this...

Done...

Like
SOLVED Posted: by donmontalvo

Hot off the press:

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

Like
SOLVED Posted: by dgreening

So it sounds like if we have our devices already enrolled in MDM we are good to go? Or are we limited somehow to MDM based distribution?

Like
SOLVED Posted: by emily
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.

Like
SOLVED Posted: by bazcurtis

Sorry if this is a silly question. When you say "sees MDM present" does that mean just having the Casper agent installed or the Mac has to be DEP enrolled?

Like
SOLVED Posted: by bpavlov

I think it's relying on the MDM profile.

Like
SOLVED Posted: by bazcurtis

OK, is there a way in Casper to add these blocked Kernel Extensions via policy or script?

Like
SOLVED Posted: by Kaltsas

@bazcurtis

Clients enrolled with an MDM solution revert to 10.12 behavior, there won't be any blocked kexts in 10.13. 10.13 looks at the Mobile Device Management payload for this determination. Currently there is no management per se, other than disabling the functionality by enrolling with MDM. It is expected there will be more functionality added to the MDM framework in the future.

See TN2459 linked above for more information, [https://www.jamf.com/jamf-nation/discussions/24743/macos-high-sierra-10-13-introduces-a-new-feature-that-requires-user-approval-before-loading-newly-installed-third-party-kernel-extensions#responseChild150100](link URL)

Like
SOLVED Posted: by donmontalvo

(duplicate)

Like
SOLVED Posted: by alexjdale

This is absolutely infuriating. We can't be expected to rely on users to take these actions in order to secure our systems with apps that use kernel extensions. I'm mad enough about MDM being forced down our throats, now it has to be MDM installed by the user?

Like
SOLVED Posted: by gachowski

Yep,

Don't think this is going to be easy for Mac Admins.

http://www.openradar.me/35307623

C

Hopefully this will get some more dialogue going and people to reach out to Apple : )

Like
SOLVED Posted: by dmatth01

My apologies if the next question is stupid but after enrolling a Mac I see the JSS MDM profile in Profiles but installing McAfee ENS via policy still pops up the message that McAfee must be approved in Settings. Is there anything I have to do in JSS to disable SKEL or do I need to deploy Mcafee via MDM and not via JSS computer policy. If so, any hints on how to deploy a pkg via MDM?

Thanks,
Dirk

Like
SOLVED Posted: by emily

So long as the MDM is put in place prior to the installer running there should be no prompt… assuming you are on 10.13.1 or .0. There are changes to this behavior in 10.13.2. If you're unfamiliar I recommend reaching out to your local Apple SE and requesting access to the AppleSeed for IT program.

Like
SOLVED Posted: by alexjdale

It's kind of ridiculous they would have a workflow that provides a better result when you upgrade the OS after preparing the system. This entire thing reeks of poor planning and a lack of concern for Enterprise customers.

If I were implementing this, I would have a "first boot only" option where the OS could ingest a config profile file from a specific location and only during the first boot of the OS (so we could use programmatically built DMGs). This profile could disable SKEL (now called UAKEL, apparently) in the same manner as MDM while being secure, since I can only assume they are trying to prevent malware with root access from disabling SKEL silently through an MDM enrollment. Hence the user acceptance requirement.

Like
SOLVED Posted: by dgreening

I definitely reached out to our SE on this one. We aren't in a position (huge global company) where DEP is feasible at this point. We also can't have users essentially "opt out" of security settings distributed via Config Profiles. Please raise hell with your SE if you can! Poor planning indeed!

Like
SOLVED Posted: by dmatth01

Well, I don't have an Apple SE but I do have about 50 Macs and 5000 Windows computers. If the solution is to wait for 10.13.2 I'm fine with that and will just wait. The low number of Macs doesn't justify a fancy deployment process, so we are just wiping them and reinstall from USB in the field or a NetRestore in my case because it is so much faster. After a fresh OS install they enroll in JSS and get the standard software installed as part of the enrollment. The JSS MDM profile should be part of the enrollment but if a restart is required between installing the MDM and disabling SKEL then that would explain why McAfee still fails to install properly.

I will take McAfee out of the enrollment process and see what happens after the first restart. Is there a shell script that would tell if SKEL is enabled?

Like
SOLVED Posted: by alexjdale

I am not aware of a way to check the status of SKEL, but it is a topic I asked about last week: https://www.jamf.com/jamf-nation/discussions/26006/skel-monitoring-reporting-extension-attribute

What I did was create an extension attribute to use kextstat to check on our SEP kexts. If SEP is installed with the process running but the kexts are not loaded, I know there is a problem and it's almost certainly SKEL.

Like
SOLVED Posted: by jzeles

It appears that regular MDM is not going to work to disable SKEL, it must be DEP-initiated SKEL. In fact, MDM itself does not appear to be trusted or functional until the user approves it (unless, again, it was enabled by DEP). I have no idea how this will be supportable in an enterprise environment. Any MDM that is deployed by ANY method other than DEP appears to require user approval.

Like
SOLVED Posted: by howie_isaacks

This may sound stupid, but I keep reading and hearing about contacting my Apple SE. I have no Apple SE, so how do we get one? I was just told this by Jamf support, and the rep I spoke to was unable to elaborate. I am a managed service provider, not a member of an IT department of a specific company. My clients purchase their Apple products directly from Apple, and sometimes from resellers. Currently, none of them are using DEP, even though I have been trying to convince the larger clients to get on DEP.

Like
SOLVED Posted: by beatlemike

Yeah, this is a bit ridiculous, and clearly a power grab to try and make sure enterprise is only buying NIB machines, because Apple refurbs can not get DEP, and more than likely purchasing from Apple directly now.

I love DEP, but we have tons of machines already in use from before we began purchased with it and as a large university, I can't control where our departments purchase from, nor can I blame them for saving money on refurbished items. But now we have to handhold the setup of every non DEP machine beyond just convincing the unenlightened user to just install this "quickadd" thing without asking questions.

Fun stuff.

Like
SOLVED Posted: by gachowski

@beatlemike

I don't think it's about money at all... I bet in a year or so you will be able to add macs to DEP just like you can do now with iPhones... I think it's about security ... yes it's a pain but in a year or two the MacOS will be significantly more secure.

C

Like
SOLVED Posted: by beatlemike

@gachowski and in the meantime... we are left with this. This isn't a year or two in the future this is now. And just because I may be able to add Macs to DEP, won't change the fact that to do so to a deployed machine will mean I will have to wipe it, and even to attempt so means prying it from the cold dead hands of faculty and staff who already have them in the wild.

More secure, sure, assuming no more processor flaws or 0day kernel flaws rear their ugly head at that time lol.

You have far more trust in the intentions of corporate America than I, clearly, but this is an issue in the here and now, not the future. My Apple SE is great, but even he said there is nothing to really be done, that's just the state of security on the Mac now.

Like
SOLVED Posted: by howie_isaacks

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!

Like
SOLVED Posted: by beatlemike

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

Like
SOLVED Posted: by TexasITAdmin

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.

Like
SOLVED Posted: by cwaldrip

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)

Like
SOLVED Posted: by donmontalvo

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 [[ ${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

Like
SOLVED Posted: by alexjdale

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.

Like
SOLVED Posted: by PhillyPhoto

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.

Like
SOLVED Posted: by gachowski

@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

Like
SOLVED Posted: by dgreening

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

Like
SOLVED Posted: by gachowski

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

C

Like
SOLVED Posted: by kericson

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.

Like
SOLVED Posted: by allanp81

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

Like
SOLVED Posted: by kericson

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

Like
SOLVED Posted: by PhillyPhoto

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?

Like
SOLVED Posted: by kericson

@PhillyPhoto I totally agree this is pointless.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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?

Like
SOLVED Posted: by 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

Like
SOLVED Posted: by 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

Like
SOLVED Posted: by HNTIT

Odd, new builds via DEP are fine, still testing

Like
SOLVED Posted: by MatG

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

Like
SOLVED Posted: by 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>"
Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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!

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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

Like
SOLVED Posted: by 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!

Like