McAfee Endpoint Security PPPC

[MikaelDez]

Hey everyone,

I would like to create a PPPC config file to allow McAfee to install without macOS blocking its system extension. Following this link: https://kc.mcafee.com/corporate/index?page=content&id=KB91109
it tells me the PPPC profile key needs to be "SystemPolicyAllFiles". Using PPPC Utility, has anyone successfully accomplished what I'm trying to do?

Essentially I want to push Endpoint Security and it not prompt the user to allow the extension.

Thanks,
Mike

[sdagley]

@mikedesmarais That KB article is for the PPPC settings necessary for McAfee ENS. For the prompts regarding the McAfee kernel extensions (it's not currently using system extensions) you need an Approved Kernel Extensions payload. And you really should try installing ENS in kextless mode (although firewall still requires a kext)

[jtrant]

You don't need to use the PPPC utility for this, it's available in the Jamf GUI, providing you're on a supported version.

The Team ID you want to whitelist is GT8P3H7SPW. From there it's a case of adding each of the components and granting them SystemPolicyAllFiles, per the KB article. They also have a sample PPPC file that you can upload directly to Jamf Pro and distribute, if you wish.

You will also need a kernel extension whitelist profile, separate to PPPC.

[MikaelDez]

@jtrant Forgive me because I'm pretty fresh to Jamf, could you explain where I need to whitelist that Team ID? I'm assuming under "Identifier" I would enter the path of the component and select "Path" under identifier type. We already have Mcafee's kernel extensions whitelisted in a separate profile. Also, what is required in the "Code Requirement" box? If I try and save this it highlights in red.

[jtrant]

If you take a look at the bottom of the page you linked, McAfee have actually provided an example configuration profile, although they don't have the VShieldScanManager part for ENS 10.7.0 included. The code requirement is the same as VShieldTaskManager in their example profile but the code requirement would change slightly.

I'd be happy to share my configuration tomorrow if you still need help. A reminder that you also need to consider kernel extensions, as PPPC are not the same thing.

[MikaelDez]

@jtrant I downloaded the example configuration profile and added VShieldTaskManager, I'm still getting that System Extension Blocked pop up, which I think might be causing McAfee to install without enabling Threat Prevention. Currently an end user would have to allow the extension in Security & Privacy and then enable Threat Prevention under McAfee's preferences. I have also whitelisted McAfee's kernel extensions, I've attached screenshots of the pop up and the kernel extensions I'm whitelisting in case there's something I'm missing.

[jtrant]

Can you share the whole KEXT profile?

McAfee Team ID: GT8P3H7SPW
Bundle IDs:
ENS: com.intelsecurity.FileCore, com.McAfee.AVKext, com.McAfee.FileCore, com.McAfee.FMPSysCore, com.McAfee.mfeaac, com.McAfee.SFKext
DLP: com.McAfee.driver.DlpUSB, com.mcafee.DLPKext

I know with true system extensions they must be applied before the software in question is installed, but I didn't think this applied to kernel extensions.

[MikaelDez]

This is the entire kext whitelist profile in Jamf Pro, it looks like I need to add some based off your list.

[MikaelDez]

I was able to get McAfee installed now with no security prompts with your kernel extension list, no PPPC profile involved. The only problem I have now is Threat Prevention is disabled by default, do you have any ideas on how to enable that, whether it be by script or anything else?

[jtrant]

You'll still need a PPPC profile so that McAfee ENS/DLP can scan the machine (SystemPolicyAllFiles), but as for Threat Prevention being disabled I'm not sure. Do you have a valid license key entered in ePO, and do you have a policy in place to enable threat prevention?

[sdagley]

@mikedesmarais Are you restarting after install? It's been my experience with installing recent versions of ATP is that it requires a restart to start running.

[jtrant]

Good call @sdagley.

[MikaelDez]

There is a valid license key and I have restarted, the only thing I haven’t verified is if there’s a policy in place (I’m not the one person that manages ePO, and they insist that the default behavior of McAfee should have Threat Prevention enabled after installing, which is not the reality I’m experiencing)

[Musicmaker]

I'm having the same problem that Threat Prevention is disabled, also after a restart. I have created a Kext profile for McAfee and also created a PPPC profile for the full disk access.
Hope someone has a solution for the Threat Prevention being disabled.

[kgam]

Are you able to enable it manually in McAfee's preferences?
Not sure if it's native to the application or something we control in ePO but our McAfee Threat Prevention will enable itself after a specified time if it get's disabled. Maybe that would be worth looking into if you can actually enable it manually in preferences.

[Nix4Life]

What ended up working for us, was to run the McAfee install.sh script that sets the framework. Then the RTW Package. I am not sure if the script is on the McAfee site, but I can check next week. the product_deployment_sh ( I think that is right) did not work correctly for us.

[Musicmaker]

@kgam Yes, it is possible to enable it manually but, as you know, you need to do this as an admin.
@Nix4Life That's the exact order I use to install McAfee

If you take a look at the following article from McAfee you can see that you will need 6 bundle identifiers. I've set all of them and also created a PPPC to give McAfee Full Disk acces:
End-user experience when installing Endpoint Security for Mac on macOS High Sierra 10.13 and later
But so far, no luck that it will automatically change from "Disabled" to "Enabled".

[sdagley]

If anyone else prefers to deploy the McAfee agent and ENS components via Jamf Pro rather than ePO here's the postinstall script for a unified .pkg that bundles all the installers ePO will spit out: McAfeeENS10.7.1postinstall.bash

Note that it installs the modules capable of it in kextless mode so you don't have to switch from kext to kextless mode post install

[kgam]

@sdagley Have you found significant performance boosts in running McAfee in kextless mode? Our Mac clients are running in kext mode and I've just started testing kextless to see if we should switch. My biggest problem with McAfee is when our Macs power on or reboot. At the login screen imput will be unavailable for up to 30 seconds while McAfee is starting it's services and after the user has logged on they'll still get spinning-beach-balls-of-death for the first several minutes until McAffee is fully launched and updated. I'm hoping kextless will improve this.

[sdagley]

@kgam We haven't seen the behavior you describe on startup, but in the past some users would experience apps taking almost 2 minutes to launch until the Mac was restarted. That's not something we've seen withMcAfee in kextless mode, and it has definitely eliminated crashes in com.McAfee.mfeaac which was our most common kernel panic trigger.

[kgam]

Thanks @sdagley. Initial testing seems to have improved startup performance but it's still too early to tell. We'll also have to weigh any performance boosts against the lack of Self-Protection in kextless mode.

[Musicmaker]

Just ran another test and macOS came with a pop-up that software was blocked.
I already pushed the Kext profile to this client and I verified that it actually had the profile installed.
But still in "Security and Privacy" there was the notification:
System software from developer "McAfee, Inc." was blocked from loading

[sdagley]

@kgam If you're not ready to deploy kextless yet, and your environment has been upgraded to macOS Catalina, you may want to look at the upcoming release that will support the System Extension replacement for kexts. I believe it'll install the System Extension version on macOS Catalina as well as Big Sur, but you'll want to check with your McAfee rep to confirm.

[kgam]

Thanks @sdagley, that's an excellent recommendation. Most of our Macs are on Catalina waiting for Big Sur so I'll definitely check this out.

[freshmacman]

@sdagley Hey, what would you recommend I do? I'm very new to Jamf and only recently started updating my Approved Kernel Extensions config profile to also include a system extensions payload with the team identifier for the software that will be using system extensions instead of kext. I'm running mojave and catalina machines which is why i have both Approved Kext and Approved system ext. Is this a good way of preparing for the change?

[sdagley]

@freshmacman Don't deploy a Configuration Profile with a System Extensions payload to a Mojave system. Since Mojave doesn't support System Extensions it won't install that payload, and when you upgrade that Mac to Catalina the profile won't re-deploy. Technically you could just clone your existing Configuration Profile and have one version targeted at Mojave and the other at Catalina or higher, and when a Mac upgrades from Mojave to Catalina the applicable profiles will be removed/installed but if that'll happen before a user upgrading gets a prompt to approve the System Extension is something you'd have to test.

[freshmacman]

thank you for the quick response, I think I'm going to clone the profile and scope one to 10.14 and one to 10.15 with system extension AND kext since most software on my 10.15 still use kext for now. I'll have to test if like you said. Thank you for the heads up, I have all my 10.14 clients with sys extensions payload configured!!!! @sdagley

[kgam]

How would you go about upgrading a Mojave to Big Sur with McAfee already installed and the Mac NOT being enrolled in Jamf?

For example: I have a Mojave with McAfee 10.6.8 already installed and kernel extensions manually approved. I want to enroll the Mac into Jamf in order to automatically approve everything needed for Big Sur and McAfee 10.7.5 but I'm not sure about the order of the workflow.

If the Mac is upgraded to Big Sur, without enrolling it first, I'm bound to get prompts from PPPC on first restart since this feature is not implemented in Mojave but is in Big Sur so the configuration profiles are not in place.

If I enroll Mojave into Jamf before upgrading to Big Sur I can scope the PPPC profiles to Big Sur but I am still bound to get the prompts for PPPC right after I have upgraded because the configuration profile wont be applied until the Jamf agent sends the next inventory back and Jamf Pro discovers that this Mac is now on Big Sur and hence assigns the PPPC configuration profile.

If I upgrade to Big Sur first and then enroll I'm bound to get prompts to configure PPPC as well right after the upgrade as McAfee is already installed and the user hasn't had a change to enroll the Mac into Jamf yet...

Maybe there is no pretty way to do this. Or maybe it will work if I scope the configuration profile to Mojave as well so, even though it doesn't need it itself, it would have it at the time of being upgraded. It just doesn't seem like the proper way of scoping or applying configuration profiles.

[sdagley]

@kgam How are you running your upgrade process? If you use macOSUpgrade it will trigger a recon at startup (via a LaunchDaemon) so Jamf Pro will get the notification of the new OS as quickly as possible.

[kgam]

@sdagley The plan was to just use the regular update process where the end user initiates the update from Software Update. As we are yet to go live with Jamf in the organization the plan is to enroll our Macs as part of the Big Sur upgrade. But not sure if the enrollment should happen before or after the upgrade. My main concern is to get as clean an upgrade as possible without too many prompts for the end-user to have to deal with. And as you recommended in an earlier post I'm trying not to scope configuration profiles to macOS versions that don't have the targeted features implemented.

But it seems near impossible to get everything done in the right order so everything is scoped and allowed before services like McAfee and AnyConnect launch after the upgrade. Any maybe it's not possible without e.g. macOSUpgrade (thanks for that link!). I've always just preferred to keep workflows as simple as possible and use native procedures if available - especially when just starting out.

I've also thought of removing McAfee before the upgrade, then upgrade to Big Sur, scope all thats needed and then install the latest McAfee. Perhaps compiling this into an "Upgrade to Big Sur" script and make it available in Self Service. I guess this should keep the upgrade process pretty clean from prompts.

[sdagley]

@kgam Your thought is basically what we did for the High Sierra -> Mojave upgrade. I modified macOSUpgrade with a "Last Call" option that would trigger a Jamf Pro policy immediately before calling startosinstall and used that to remove the version of McAfee installed. When the Mac checked in post-install the lack of an installed McAfee Agent triggered re-installation.

[kgam]

@sdagley I'm actually very glad to hear that. The thought of having to remove McAfee before the upgrade seemed "inelegant" but everything else appears to be a catch-22 situation.

In your experience: is a clean upgrade without user-prompts, using only standard Jamf Pro workflows and user-initiated upgrade through Software Update not possible? Without uninstalling McAfee first, that is.

If not I'll stop chasing this a look into either uninstalling McAfee before the upgrade or using macOSUpgrade - or a combination of both.

[sdagley]

@kgam You could build something that runs the update process on your own, but my motto is if someone has already written most of what you need don't re-invent the wheel, and that's where macOSUpgrade comes in.

For removing McAfee you can try this script: https://gist.github.com/sdagley/77096ebd45f7479c4ba0da83d9722f08

[rstasel]

Hey All,

Curious if anyone else is trying to do this. We're installing ENMS and then immediately uninstalling the Firewall and Web Filter. So we JUST have Threat Protection. This worked great in 10.6.8 for macOS 10.14 and 10.15, no issue. But with ENMS 10.7.5, no matter what we do we can't get the Firewall uninstall process to not prompt for admin username and pass, seemingly because of this note in McAfee's docs:

When uninstalling ENSM Firewall: When uninstalling ENSM Firewall, the user is prompted to enter the administrator credentials to uninstall the system extension. This statement applies to both ENSM Firewall standalone and ePO managed. Also, it does not matter whether the system is MDM-managed. If the user does not provide credentials or provides incorrect credentials, the ENSM Firewall uninstallation does not continue. To uninstall ENSM Firewall successfully, the user must try the uninstallation again and provide the correct credentials. Apple designed the uninstallation of system extensions this way. User intervention can't be avoided even on MDM-managed systems.

https://kc.mcafee.com/corporate/index?page=content&id=KB93600

Anyone have some way to accomplish this, or do we just give the firewall a whirl? Way back when, the ENMS firewall would break all kinds of stuff... including Jamf!

[sdagley]

@rstasel This is a current limitation of System Extensions, not something McAfee is intentionally doing. If the full ENSM installer doesn't support a choices.xml file to choose which modules will be installed you can just package and install the components you need rather than installing everything and then ripping stuff out. I haven't updated it for 10.7.5 yet, but the postinstall script I wrote for my packaged deployment of ENS 10.7.1 should get you started: https://gist.github.com/sdagley/76e167fe32a60265dda8d761d2bc75b4

[rstasel]

Hi @sdagley

Thanks. I guess I’m confused where you get the components. I’m just grabbing 10.7.5 off the McAfee site rather than out of our ePO.

But this is super interesting. Would mean we could skip installing managed agent over the top of unmanaged (after ENMS install).

Do you have some documentation somewhere on this? Will admit, not a mcafee expert. And our ePO admin isn’t very familiar with the Mac side.

You also say kext-less. Which I assume is how 10.7.5 is by default, or is it something different? Last documentation I saw said kextless only applied to unmanaged.

Thank you!

[kgam]

@rstasel I have tested McAfee ENSM 10.7.5 and it does support the choices.xml so I'll definitely recommend trying this out.

You basically create an XML file specifying which modules you would like to install (e.g. only Threat Prevention) and then call the install package from McAfee's site with the XML file as a parameter similar to this:

installer -applyChoiceChangesXML mcafeeChoices.xml -pkg McAfee.pkg -target /

All this can be put inside your postinstall script.

More information can be found here:
https://sneakypockets.wordpress.com/2017/07/26/using-installer-choices-xml-to-modify-anyconnect-and-mcafee-deployments/

[sdagley]

@rstasel Sorry, the script is basically all the documentation for itself. It is fully home grown except for the removal code (which is based on a post in the #mcafeee channel on the MacAdmins Slack) and is the result of my packaging all of the individual McAfee ENS installers into a single .pkg for the past couple of years to simplify deployment. The individual module .pkg files were extracted from what the ePO spits out.

I believe you are correct that 10.7.5 is fully kextless on Catalina and Big Sur since it will use a System Extension on those OSes. For ENS 10.7.1 and earlier (or at least going back to 10.6.something) it was an option, except for the firewall module. If you're installing on a Mojave system the kextless flag is still needed since a System Extension support didn't arrive until Catalina.

[snowfox]

Some helpful lnks for new people coming into the thread:

McAfee Support YouTube Channel Mac Videos
How to install ENS Threat Prevention 10.6 in kext-less mode on macOS
How to deploy ENSM to a Mac running High Sierra with ePO

Supported platforms for Endpoint Security for Mac
McAfee compatibility with Privacy Policy Preference Control
End-user experience when installing Endpoint Security for Mac on macOS High Sierra 10.13 and later
Kernel extensions are not loaded without user consent
Switch between modes of operation after installation
McAfee Endpoint Security 10.7.5 - Installation Guide - macOS

[rstasel]

@sdagley Perfect. So just ripping apart the mcafee installer, cool!

so drop the installers we want into /tmp, then postinstall. Seems logical.

The choices file is also appealing, but I can't say I've done it before. Anyone know if TalkingMoose's Choices Packager still works ?