After upgrading both of my Macs to High Sierra 10.13.4, I was greeted by several alerts saying that an extension was blocked. OK. Fine. I knew this was coming. The problem for me was that when I went to the Security & Privacy preference pane, and clicked the Allow button, nothing happened. I tried logging out and logging back in, and rebooting. Neither worked. I then logged into a different admin account, and I was able to allow the extensions. I just wanted to pass this on in case anyone else runs into this issue. I haven't figured out exactly why my normal login account could not approve the extensions, but at least the solution was easy.
I saw this warning after a reboot for these (2) third-party resources
This approval UI is only present in the Security & Privacy preferences pane for 30 minutes after the alert. Until the user approves the KEXT, future load attempts will cause the approval UI to reappear but will not trigger another user alert.
For clarification, is /usr/sbin/spctl the command to enable/disable them from command line?
Supposedly If a Mac is enrolled with an MDM solution, the new kernel extension authorization behavior is disabled. But on my test Macs (enrolled in Jamf - version 9.99) I was prompted (See screenshot above), which surprised me. Is this behavior expected on managed Macs? Should users be seeing this warning message?
Looks like @RobertHammen clarifies some of these topics in his post https://goo.gl/oHWUQQ
Sorry @dstranathan nothing that fancy. I simply upgraded one of my Mac VMs to 10.13.4, and then installed something that I knew would get blocked. My reason for starting this thread was partly a warning that users may not be able to allow the extensions. I wasn't sure at the time whether my personal situation was going to be seen with other people. I'm happy that's not going to be the case. I also wanted to let others know that logging in as another admin account was the solution if someone cannot get the extensions approved.
@ssmurphy We are seeing it on the machine as well when you attempt to do it via the currently logged in user. Switching accounts fixes it, but if you have a few thousand machines in your fleet that is a bit of a headache.
Going over some of the documentation regarding the change, I saw this:
For workflows that leverage mobile device management (MDM), all systems with a valid MDM profile installed will not require user approval to load any properly-signed kernel extension.
And Jamfs press release for 10.3 states this:
The 10.13.4 release of macOS introduces a new level of management capabilities for Mac, known as “User-Approved MDM." As the name suggests, this implies the user has willingly enrolled their Mac into management. New security-sensitive MDM controls now require User-Approved MDM. This is similar to how supervision works on iOS, but is not actually called supervision for the Mac. Existing Macs enrolled prior to 10.13.4 in MDM will automatically be considered "User Approved." Any DEP enrollments are also "User Approved." Automatically create User-Approved MDM enrollments through the new enrollment workflow in Jamf. This allows IT to remotely manage security-sensitive settings like User-Approved Secure Kernel Extension Loading. New profiles, like Approved Kernel Extensions, require a macOS enrollment to be User Approved.
Is anyone that is seeing these blocked kernel extensions running 10.3 yet? It looks like a config profile needs to created whitelisting the Team ID and Bundle ID in 10.3 per the aforementioned @RobertHammen post here
Another nice thing in 10.3.0 is the Approved Profile reporting.
Note: When you view the results of an advanced search or a smart group, the inventory information returns "Unsupported OS Version" for computers with macOS 10.13.1 or earlier
I'm amazed that (not really) even after giving explicit instructions to our non-DEP clients, about 50% have not approved their Profile...
If you don't have 10.3.0 and can't tell if the MDM profile is approved, you can always use kextstat to look for your critical kexts and nag the user if they aren't loaded.
With 10.3.0, I'll use that attribute to perform my own "conditional access" and deny access to all Self Service policies unless a user approves their MDM. I hate to use a carrot like a stick, but Apple leaves us few options since even DEP can't be forced.
I've also run into this kext approval after updating my iMac to 10.13.4. It was enrolled prior to update via DEP so I'm concerned that anyone updating is going to be running into this regardless of their MDM enrollment status/method.
We are currently on 9.101 and so can't use any configurations regarding kext but will begin playing with these in prep for our upgrade to 10.3 in a couple weeks.
To summarize what others have said:
To get the Team IDs, read the first half of this post by @grahamgilbert : Enabling Kernel Extensions in High Sierra. Stop reading at "csrutil" because you should be using a Configuration Profile if this is being deployed to more than a handful of systems.
It is NOT necessary to have DEP to use this feature. Using DEP gives you supervision (non-removable MDM) and bypasses the "user approval" for the MDM profile, but if your MDM is already approved (either manually, or because the system was grandfathered in during an upgrade), then just add the Configuration Profile from Jamf Pro and be on your merry way.
After re-reading the release notes, it looks like Apple intentionally decided not to automatically approve kernel extensions on MDM enrolled systems:
•No longer disables User Approved Kernel Extension Loading on MDM-enrolled devices. For devices with DEP-initiated or User Approved MDM enrollment, administrators can use the Kernel Extension Policy payload.
As @bradtchapman noted, it is time to start using the configuration profiles AND time to upgrade Jamf servers to 10 to do this (we are upgrading next weekend).
Been quite some time since I've been round these parts. I've moved over to Carbon Black and we're helping customers through this one. If you use a Cb product, feel free to reach out to me and I'll see what I can do. This one's taken some of us by a bit of surprise as well and I know some of y'all deal with our kexts.
<first initial><lastname> @ carbon black <dot> c0m
Cool! today we got our official GO within our organisation to move over to Carbon Black Defense 🙂 So moving out from pilot phase to all clients (in batches) and yeah we saw on the 10.13.4 pilot users the CBD Sensor got stucks "Bypass" because of the KEXT not approved.
So, created a configuration profile, and couple of secs later it all went fine and the sensor went active again 🙂
ps. please share to add the feature to run a full scan on a client via CBD, would be awesome!
@wmateo You can in theory do it in J9.9 by creating a custom setting in Config profiles and import a pre-made kext list (By using Franton's script https://www.jamf.com/jamf-nation/discussions/26583/kextpocalyse-2-the-remediation-blog-post-by-our-own-franton).
If you want to add them manually you'll need to upgrade to Jamf 10 which provides you with the "Approved Kernel Extensions" option.
Keep in mind that the approved kext list needs to be installed before the apps that require them so might need some re-arrangement in in smart groups and policy's.
I have a bundle_id a team_id.
6HB5Y2QTA3 | com.hp.kext.io.enabler.compound | Hewlett Packard | (blah blah blah...)
| com.ni.Fantom.nxtFwdl | 1 | Legacy Developer: N1 | 1
It's for the LEGO Mindstorm NXT software, which is old.
JAMF requires a team_id be input, and I cannot leave it blank. Does anyone have any thoughts?
I entered SKTKK2QZ74 as my missing Team_ID in my Config Profile and redeployed to affected devices.
I am getting the same symptom now as @howie_isaacks original post. I'll still get the pop up in regards to the specific KEXT for com.ni.Fantom.nxtFwdl, and nothing happens when clicking Allow. Redeploying the Config Profile did not resolve the issue either.