We are seeing the same thing with System Center Endpoint Protection. The account needs to be changed over to another admin and allow the extension. Kind of a big deal.It looks like we'll be blocking this update until there is a permanent fix

I saw this warning after a reboot for these (2) third-party resources

-Oracle (Java)
-Cisco (AMP)

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

As a temporary measure, I created a policy to ignore the 10.13.4 update.

Files and Processes -> Execute Command:

softwareupdate --ignore "macOS High Sierra 10.13.4 Update"

I did more testing, and I was able to allow the extensions on a test system. My case seems to be an isolated one, and not the norm.

@howie_isaacks Can you expand on how you did it? Is the allowance controlled via script/policy?

I agree with @dstranathan. It'd be great to know what you did @howie_isaacks. Thanks in advance!

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.

A fun thing to know. If your trying to clear the message in Security & Privacy. You will not be able to click on the button from a remote session. You must do it at the computer.

I saw this coming as part of the 10.13.4 beta, so I sent out an ignore command earlier in the week to block this update until I get our JSS upgraded to 10.2.2 so it can support MDM-based whitelisting.

@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

These two pages help understand where we are on this.
Jamf Pro 10.3.0 changes things too:

Jamf MDM

Apple MDM

So far, on 10.3 (Jamf Cloud) my 10.3.4 test Mac is not blocking the extension(s).

I've tested this on 10.2.2 and the 10.13.4 beta, and the whitelist worked as the native MDM payload for the kernel extension policy. I was not able to get it to work with a custom MDM payload on 9.101.4, so we're finally upgrading to 10.2.2 for this.

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.

After approving the extension for Google Drive File Stream, I had to quit and re-open the GDFS app before it would work normally.

If there aren't going to be programmatic means to handle these extension requests, I'm going to have to change strategy on a number of items.

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:

• The latest version of High Sierra won't automatically load any Kernel Extensions.


• A user has 30 minutes to accept the request, or the extension is not loaded.


• Restarting the Mac should bring up the prompt again.


• To bypass this limitation without disabling SIP, a new configuration profile is needed.


• The configuration profile must include a whitelist of "Team" IDs (unique per Apple Developer account)


• To find the team ID, you need to run a sqlite3 on a computer that has the KEXT installed.


• The configuration profile payload was introduced in Jamf Pro 10.2+

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.

Here the link to see exactly how to get the team ID through Sqlite
https://pikeralpha.wordpress.com/2017/08/29/user-approved-kernel-extension-loading/

Ditto. A bunch of users observing the message with Sophos (Central).

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

Thanks for the post @bradtchapman I followed the steps and I have five extensions that are now automatically approved. If I could give you a million likes for this, I would!

@howie_isaacks : you're welcome! Glad to be of service.

Hey guys-

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

@BradChapman. Nice to see your post here. We will have to upgrade to JAMFPRO 10 I see with this.

@jarednichols

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!

Cheers,
Thijs.