kext approval fail

[llitz123]

Trying to get SEP 14.2 kexts approved.
I used the utility from here and added the identifiers for team IDs and Bundle IDs.
When I added the bundle IDs the SEP app would say it was offline.
When I only added the team ID SEP would say "protected" (fixed), yet would still be blocked in Security & Privacy.

In my tests that was sufficient to get the SEP Server/Manager to see the clients working.
Unfortunately, when I push to production clients - the 2 I have tested - they both have kernel panic'd. I was able to safe boot, login to user and manually allow the kext.
So I'm stumped why I can't get this to work.
Any help or insight into how others have had successes would be greatly appreciated.

[Matt_Ellis]

Have you tried just using the Team id's, when we first started if we used both it wouldn't works. When we switched to just team id's it worked just fine.

[llitz123]

@Matt.Ellis Yeah I tried just the team IDs and that worked, yet when I push to production it kernel panics (2x).
I also cant get rid of the Allow button in System Prefs as above.
I should mention we're on JAMF 10.4.1-t1525267633.
Could later versions affect/fix the process? I'm not sure if I want to upgrade yet as I haven't really had time to research version issues.
Thanks.

[Matt_Ellis]

@llitz123 Are you able reinstall the OS on one of the systems? About a week ago i had a system that got the profile but refused to use it so one item wouldn't be whitelisted properly. I tried everything but couldn't get it to go. So i ended up as a hail mary did a install in place and it fixed it. Might be worth a try for you.

[llitz123]

I have 40 machines with the issue. I can't do that.
I guess I'm going to have work with each client. What a pain.
Thanks,

[Matt_Ellis]

I wish you good, luck. post back here if you find another fix. im hoping i dont run into this again i have over 100 systems and cant do the install in place either.

[Hugonaut]

Are you not deploying a configuration profile to allow apps from anywhere? If Not I can understand..but if you have your end users locked down and aren't admins or you aren't too worried about it, I would recommend giving the Configuration Profile for Security & Privacy a shot.

Selecting only the Allow apps downloaded from 'Anywhere' Configuration as seen in my screenshot below might just be the finishing touch you need.

[llitz123]

@Hugonaut I didnt think of that for the the "allow" issue in security & privacy as I believed the "allow" for kexts was treated differently.
That's a good idea and an easy test.

[llitz123]

@Hugonaut Thanks again for the suggestion.
I tested your solution yet it didnt remove the Allow on my test machine.

[Hugonaut]

you're welcome, but i really wanna crack this now haha..

are the profiles approved?!

https://support.apple.com/en-us/HT208019

have you tried the following?!? did it work to get past the allow?

spctl --add /Path/To/Application.app

if that doesnt work, what about the following?

Try booting into Recovery Mode, opening terminal and running

spctl kext-consent disable

should return "Kernel Extension User Consent: DISABLED"

restart the computer and then see what happens - run the following command to confirm the changes were made from recovery terminal

spctl --status

should return in terminal "assessments disabled" directly below

On the brightside, you can enable it back via jamf to all the machines so you don't have to boot into recovery to enable with the following on all 40 machines

sudo spctl --master-enable

as for disabling THERES GOTTA BE A WAY but I can't figure it out...(BESIDES BOOTIN INTO RECOVERY)....if anyone has any input on this I'm sure it would help a lot of people lol. I'm about to read the man pages...driving me crazy

Terminal returns this when running in normal mode

Kernel Extension User Consent Usage: spctl kext-consent <action> Modifications only available in Recovery OS status Print whether kernel extension user consent is enabled or disabled. enable Enable requiring user consent for kernel extensions. disable Disable requiring user consent for kernel extensions. add <team-id> Insert a new Team Identifier into the list allowed to load kernel extensions without user consent. list Print the list of Team Identifiers allowed to load without user consent. remove <team-id> Remove a Team Identifier from the list allowed to load kernel extensions without user consent.

[MikeMcD]

Brother! I'm pretty sure I already know the answer to this, but I gotta ask... did you find a better solution than booting to recovery? I have a hundred machines I'm trying to roll our Phidgets kext out to, and have gotten down to this very spot. I don't want to have to go to each and do it via recovery.

Have you (or anyone else) found another way to whitelist or allow from JAMF?

[llitz123]

@Hugonaut and @MikeMcD Sorry for the late reply. I ran out of time for my process.
I worked with each individual user to allow the kext and sent instructions to those who were unavailable. It sucked yet I cant have remote staff with kernel panics in infinite boot loops.
I did check randomly as I was working to verify profiles were approved. Every client I checked had approved profiles.
The way I know its working is that SEP Manager no longer shows errors on SEP clients.
I don't have time to test and retest as I don't have a robust test environment.

[jmahlman]

We ran into this issue ourselves and opened a ticket with Symantec the day it happened. They identified a race condition and at first were not able to replicate the issue until I gave them my step by step.

The details with troubleshooting:
Before upgrading the following kernel extensions (KEXTs) were whitelisted in our MDM and pushed with a configuration profile:
Team ID: 9PTGMPNXZ2
com.symantec.ips.kext
com.symantec.internetSecurity.kext
com.symantec.nfm.kext

The 14.2 upgrade was pushed out to macOS clients using the SEP Manager, we did not use Jamf to push out the upgrade.

All systems were booting fine with the above KEXT settings and the 14.2 upgrade in place; however, the SEP manager was showing issues with nearly all installations. The error was “Component is Malfunctioning” and it was showing mainly on Network Intrusion Protection as well as Auto-Protect Status. On a test machine I installed 14.2 standalone with our whitelisting profile and noticed that I was prompted to accept a KEXT again, I ran a tool we use to find all installed KEXTs and found that there was a new one from Symantec; com.symantec.SymXIPS. I added this to our whitelist and pushed it out and ran a Live Update on systems to see if they would change status. The “disabled” status did not change so I tested a reboot on one of our computer labs which contains 15 computers. The machines never came back online. After sending one of our techs to investigate they found that all systems were off and when they were powered on would boot about 60% of the way and then show the macOS Prohibitory symbol or constantly stuck in a reboot loop. The only way we could boot those machines or stop them from rebooting was to boot to safe mode.

After booting into safe mode we ran some troubleshooting steps. First we whitelisted the entire Symantec Team ID and rebooted; this seemed to help but when we tested on another machine in a different lab the system never came back online. We then removed Symantec from the whitelisting entirely in hopes to block the application from starting, this did not help either. We finally decided to completely remove SEP from all systems using the SymantecRemovalTool provided. This fixed our reboot issue and we are now able to get machines booting normally.

----> If you whitelist the TEAM ID only BEFORE pushing out the update, 14.2 should work fine. I assume you can also just be sure the new KEXT is whitelisted before installation.

I think it's annoying that Symantec is adding another KEXT instead of moving away from them. Really frustrating.

[llitz123]

@jmahlman that is exactly my install experience - minus contacting Symantec as they are rarely any help with Mac issues...
So you removed all SEP clients and then pushed the whitelist via JAMF and THEN pushed the update from SEP Manager and it worked?
Thanks.

[jmahlman]

No, we removed SEP on all clients that were 14.2 completely. We left everything in the Management Console.

We then re-whitelisted everything and installed the old version (14.1?) using jamf pro just to be sure. We're going to wait until Symantec updates us to push the newer versions out.

[tjhall]

Don't know how if it's the same with Symantec but for Sophos it's imperative that the kext is approved before the installation happens.
So in theory; the Symantec policy should use a smart group that checks that the approved kext config exist before it installs.

[jmahlman]

Apparently it is the same ;)

[Lotusshaney]

Yeap can confirm the KEXT Whitlist MUST be inlace Before the installer fires off

[mhegge]

Sophos Endpoint is worthless to us because of this issue. And Sophos is not much help.

[trlatimer]

mhegge, my organization recently purchased Sophos and have been able to get it pushed without requesting to be allowed. I made the mistake of unchecking the "Allow users to approve" checkbox but was finally able to get that corrected as well. If you are still having this issue, let me know and I can try to assist.