Getting the Team ID of kernel extensions in macOS 10.13 (and higher?)

Why do you need Team IDs?

Beginning with macOS 10.13 (High Sierra), Apple is now blocking kernel extensions unless you, in recovery mode (or recovery mode–like environment), change the policy on the machine itself or use an MDM profile to approve certain KEXTs by Team ID.

How do you find these Team IDs, though?


One way is to install the KEXTs on a 10.13 machine, user approve them, and then check the sqlite database to see what the Team IDs are:

sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy
SELECT * FROM kext_policy;

Here's an example of some of the output you might see:

EQHXZ8M8AV||1|Google, Inc.|8
In this example, EQHXZ8M8AV is the Team ID and is the bundle ID.

You can use Control-D to exit the sqlite3 session.

Acknowledgements: Got commands from Enabling Kernel Extensions in High Sierra


Another way is to run this command on an existing bundle from the vendor:

codesign -dv --verbose=4 /PATH/TO/

For example, if you run

codesign -dv --verbose=4 /Applications/Google\ Drive\ File\
you should see in the output a line like

This approach can be helpful in fringe cases (you just need the Team ID and not the bundle ID, which may be the case, and the KEXT you're looking for has an associated bundle you can run codesign on.

Acknowledgements: Got command from MunkiReport-PHP extensions module

Isn't there a list somewhere of all these Team IDs?

There is a list, actually. There's a spreadsheet that a bunch of Mac admins are sharing with each other. Unfortunately, at this point, it's a spreadsheet that anyone with the link can edit, so I wouldn't really count on that. At this point, I don't see anything malicious in there (and I haven't verified every single Team ID, of course), but I would probably play it safe and just get the Team IDs yourself. Chances are that you'll have to do it only once or twice a year at the most.

askForPassword and askForPasswordDelay in macOS 10.13 (High Sierra)

Update: Apparently 10.13.4 just breaks this completely (defaults write commands won't do anything any more). Thanks to tristan on the MacAdmins Slack for pointing this out.

In macOS 10.12 (Sierra) and earlier, you could go to System Preferences > Security & Privacy > General > Require password ________ after sleep or screen saver begins, and that would populate the askForPassword and askForPasswordDelay keys in ~/Library/Preferences/ for the user.

In macOS 10.13 (High Sierra), setting that preference in the GUI will not make it appear in the relevant .plist file. However, setting the preference with

defaults write askForPassword -bool TRUE
defaults write askForPasswordDelay -int somenumber
will make the change reflect in the GUI, and setting a .mobileconfig profile will also override what's set in the GUI.

Oddly enough, Apple's own documentation makes it sound as if those two keys exist only in 10.13 and later:

Dealing with third-party kernel extensions in macOS 10.13 (High Sierra)

If you upgrade to macOS High Sierra, third-party kernel extensions you had previously installed will be fine.

But if you didn't already have those installed and want to install them, you'll get an error like this:

There isn't a way to script that away—the user must actually click Allow.

Probably the most practical way to deal with this for large deployments is to make sure your client machines are all enrolled in an MDM.

The MDM doesn't have to do anything to the client or push any special profiles. The clients just have to be enrolled. If they're enrolled, there won't be a prompt to allow installation of third-party kexts.

Troubleshooting faded-looking icons in Managed Software Center on 10.13 clients

Update: Apparently, a real fix for this is on the way.

Acknowledgements: thanks to elios and bochoven on MacAdmins Slack for figuring out what was going on.

If the icons in your Munki repo looked fine on your 10.12 and 10.11 clients, and then a few of them suddenly look sort of faded (for example, Word and Excel in this screenshot) in 10.13 clients, it's apparently because of a change in the way 10.13's Safari webkit displays .png files missing the ColorSync profile in the Get Info context menu (you'll still see the ColorSync profile if you open the .png with the ColorSync Utility).

The simple fix is to do the following:

  1. Mount the Munki repo share using a Mac running macOS 10.13.
  2. Delete the offending icons from /PATH/TO/MUNKI/REPO/icons/
  3. Regenerate new icons with
    /usr/local/munki/iconimporter /PATH/TO/MUNKI/REPO

Note: Icons generated using MunkiAdmin or sips will be fine, too, even if generated using a machine running macOS 10.12.