I've followed the following guide to update our client to Cortex XDR from Traps 6.1.
I'm still getting the following message on some machines though. Has anybody seen this, and to why it's not accepting the Kernel extension Team ID provided by Palo Alto.
I'm thinking of reaching out to them to see if Cortex uses a different Team ID?
Hi @dresslah , I also followed that Cortex manual and got it working without any additional authorization prompt for my prestage enrollment devices. As I understood the system extension (which you configured in step3) is only supported from macOS 10.15 and above. Could it be that this prompt only appears on lower versions? Another thing to consider is that the configuration profile should be deployed before the Cortex agent installation.
I've ran into similar problems. Of our entire fleet, we have about 80 devices. We've crafted a Configuration Profile from their Administrator's Page -- even with an Engineer on the line due to our problems, and we're still seeing approximately 20% of the deployments not applying User Approved Kernel Extensions being applied, despite the configuration in the profile.
Have an open case with PAN, and they're saying it's a Jamf issue.
Existing Configuration Profiles applied at 10.15.3 (and prior) apply the settings as enforced. Updates to 10.15.4 (and higher) start to exhibit these problems.
@milver - the few reports I've had, all users were on 10.15+. Also, I tried to have the config profile distributed before the Cortex push, but there may have been a timing issue where Cortex got there first.
@Licon - This would make perfect sense as my main problem user was on 10.15.4 at the time of incident. Although, when I tested on my corporate machine (I'm on 10.15.5), everything worked as it should. Nevertheless, good to know it may only be limited to 10.15.4+ In the mean time, I've just had the user accept everything manually.
I'm working on deploying Cortex XDR across our Mac fleet now. On macOS 10.14 and below, it installs a KEXT. On 10.15, it installs a system extension instead. You'll need to whitelist it separately from the KEXT.
EDIT: Just found Palo Alto's documentation specifically for deploying Cortex using Jamf: https://docs.paloaltonetworks.com/cortex/cortex-xdr/7-1/cortex-xdr-agent-admin/cortex-xdr-agent-for-mac/install-the-cortex-xdr-agent-for-mac-using-jamf.html
Hi all! Just deploying Cortex XDR 7.2 in our envirnoment and having no issues or prompts at all.
My recommendation would be to make sure that all the configuration profiles are present before installing Cortex. You can do that with a Smart Group that checks if your System extension and PPPC’s are present on the device, and use that to scope the install.
Let me know if I can help in any way folks 🙂
Adding to this, you will now also need to deploy a network extension config profile before upgrading/deploying Cortex 7.2.1, for macOS 10.15.4+
And in a very surprising move, because Jamf don't yet support network extensions in the GUI, Palo Alto are providing a signed config profile for you to use to achieve this.
I have only just started getting the problems with macOS 10.15.7. I have Cortex XDR set to install on any Catalina devices, however all device are scoped to the Cortex configration profile ready. Two Macs that were upgraded from 10.13.6, using self service to 10.15.7 have both required extention approval. I had 10.15.4 available as the catalina upgrade prior to this and didnt get any calls.
For the benefit of anyone else having issues, I have now worked out the correct workflow. While many people point out that you must have the profile on the device before you install the software, this should come with a very important warning.
Do not install a profile to manage this System Extension to pre-Catalina device, as I did. As some System Extensions are only supported fom Catalina onwards, the configuration payload did not work. Once you upgrade to Catalina or Big Sur the payload will not work as it was installed on an OS that did not understand it.
The soultion is to only install the Configuration profile post upgrade. Then the System Extensions payload should work when you install Cortex XDR.
I have also made sure that my Cortex install policy only installs once the Cortex profile is installed. I did this using an EA that looked for the profile, then I have a smart group that looks at the EA value, if it is true is will appear in the smart group. The policy then only installs on devices in that smart group.
What I have not tested yet is if I have Cortex Installed pre-Catalina (which only needs the kernel extension approved by profile), what will happen after the upgrade.
Hi All, I'm deploying Cortex XDR to my fleet, noticed the PA directions say "you must create a new agent installation package in the Cortex XDR management console, upload the ZIP package you downloaded from Cortex XDR to your MDM (do not extract it), and then add it to a distribution point." (https://docs.paloaltonetworks.com/cortex/cortex-xdr/7-4/cortex-xdr-agent-admin/cortex-xdr-agent-for-...)
What's this all about, saying upload the ZIP and do not extract?? Does it need to be unzipped and the installer run manually on each endpoint?
Has anyone here tried packaging CortexXDR as a usual PKG and deploying that?
inside the zip is an installer package with no information about your organisation. the config file contains your organisation config. if both files are kept together the installer will look for the config and use it to configure the client.
jamf accepts zips files and simply unzips them upon install, so just leave it as is and choose it as the installer 'package'. otherwise you'll have to make your own custom installer/package/script