Just went through all of this with a customer. We can't upload their provided mobileconfig because it is not signed. We can't copy the plist data because it has all of the extra config profile formatting (plus there may be acceptance issues with Jamf on extensions). Very simple process is to sign the profile and upload to Jamf. Use this process to get a signing cert from Jamf Pro: https://www.jamf.com/jamf-nation/articles/649/creating-a-signing-certificate-using-jamf-pro-s-built-in-ca-to-use-for-signing-configuration-profiles-and-packages After that, use the /usr/bin/security command method sign the profile. Test the profile by manually installing it on your Mac. The formatting should look pretty. Then you can upload to Jamf Pro and it will look pretty there too. The nice thing about this method is that if CS provides a new group of setting for macOS 12 we don't need to reinvent the wheel on setting and can get it uploaded in 5 minutes. In addition to this you may want to whitelist the notifiation settings. There's a plist floating around for com.crowdstrike.falcon.UserAgent that we can use and upload as custom Jamf payload and push.
Anyone able to get this working on M1 macs?
@ubcoitThank you. I went the multiple profile route with scoping to the specific macOS on your post. Working great for new machines and allowing upgrades from the CS console with no interaction needed from the user. The one glitch that I have encountered was some of the macs wouldn't upgrade - showing Changes Pending in the CS console, but never move forward to complete the install. The Falcon client would then go into limbo, showing that it was still installed, but not respond to terminal queries. This mostly happened to Big Sur systems. I opened a ticket with Crowdstrike and they sent over a command for v6 clients already installed : sudo /Applications/Falcon.app/Contents/Resources/falconctl load --force. When this was run, it forced the CS client to check back into the console and perform the upgrade. I made a policy to go hunting once a day for systems that were below the current build, and force their checkin. Sometimes this also triggered the "Falcon" would like to Filter Network Content, and once a user clicked Allow, it would continue. I'm not sure why that was occasionally popping up, but I think it's a hold over from previous Config Profiles prior to upgrade to Big Sur.
We were able to get Crowdstrike to install and bypass the system extension prompt by adjusting the profile to specifically target the System Extension (com.crowdstrike.falcon.Agent) as opposed to just allowing all system extensions from their team identifier.
We were able to get Crowdstrike to install and bypass the system extension prompt by adjusting the profile to specifically target the System Extension (com.crowdstrike.falcon.Agent) as opposed to just allowing all system extensions from their team identifier.
which is great. -- this SHOULD be the case now...
For the sake of clarity, the issue for which this thread was opened, mostly applied to CS client versions below 6.2. -- the later 5.x and early 6.x clients still included a 'Kernel Extension' -- prior to the wide-adoption of the newer 'System Extension' framework.
The solve ( in our case ) was to have the 'BIOS Inspection' feature disabled in the Falcon Web Console / Policy.
Working with Cybereason for our endpoints now and all seems a lot smoother. Will update all of things come up. Keep up the good work for all security strengthening deployments. Go Jamf!!!
This discussion was very helpful for my rollout from Sophos to CrowdStrike. Does anyone know how PPPC configuration profile payloads get applied when you have multiple profiles setup and scoped to the same computer? My testing indicates that it all gets combined and applied correctly, but I ended up creating a single PPPC configuration profile with all the payloads I needed (Zoom, Sophos, CrowdStike) to make auditing easier. It looks like the PPPC is an exception here, since I ran into serious issues trying to apply multiple KEXT/SystemExtension profiles to the same computer.
This discussion was very helpful for my rollout from Sophos to CrowdStrike. Does anyone know how PPPC configuration profile payloads get applied when you have multiple profiles setup and scoped to the same computer? My testing indicates that it all gets combined and applied correctly, but I ended up creating a single PPPC configuration profile with all the payloads I needed (Zoom, Sophos, CrowdStike) to make auditing easier. It looks like the PPPC is an exception here, since I ran into serious issues trying to apply multiple KEXT/SystemExtension profiles to the same computer.
Profile Payloads generally combine, as you describe, as long as affected preference domains don't contain any overlap. -- in the case of PPPC, you can certainly combine / make a single PPPC profile that is 37 miles long... but it is generally better to separate them a little... --- if you have to make a minor adjustment, you don't necessarily want to roll the entire profile. ( not to mention that a single syntax error can cost you HOURS of trying to find the typo one application at a time.... )
Also, if a machine "already has" a config profile, sometimes a simple change is less effective than a 'just create a new profile so it gets a new uuid'
Profile Payloads generally combine, as you describe, as long as affected preference domains don't contain any overlap. -- in the case of PPPC, you can certainly combine / make a single PPPC profile that is 37 miles long... but it is generally better to separate them a little... --- if you have to make a minor adjustment, you don't necessarily want to roll the entire profile. ( not to mention that a single syntax error can cost you HOURS of trying to find the typo one application at a time.... )
Also, if a machine "already has" a config profile, sometimes a simple change is less effective than a 'just create a new profile so it gets a new uuid'
Thanks for the info! I may go back to the separate PPPC profiles then for maintainability. It confused me that there is a built-in one for Jamf called "Privacy Preferences Policy Control" that is assigned no matter what and is for the Jamf Agent/Framework. Another issue I ran into was that /Library/Managed Preferences/com.apple.TCC.configuration-profile-policy.plist didn't seem to make sense until I combined everything into one configuration profile object on Jamf. I was using that file to audit, but maybe there is a better way that I don't know of. The thing that really started this off was trying to have multiple KEXT profiles scoped. That did clobber some previously approved KEXTS, hence the increased caution and auditing of /Library/Managed Preferences/.
Thanks for the info! I may go back to the separate PPPC profiles then for maintainability. It confused me that there is a built-in one for Jamf called "Privacy Preferences Policy Control" that is assigned no matter what and is for the Jamf Agent/Framework. Another issue I ran into was that /Library/Managed Preferences/com.apple.TCC.configuration-profile-policy.plist didn't seem to make sense until I combined everything into one configuration profile object on Jamf. I was using that file to audit, but maybe there is a better way that I don't know of. The thing that really started this off was trying to have multiple KEXT profiles scoped. That did clobber some previously approved KEXTS, hence the increased caution and auditing of /Library/Managed Preferences/.
when it comes to KEXT vs. SYSEX..... 100% make sure you put them in separate profiles. 😉
( as in, keep your kext exceptions and sysex exceptions in separate profiles.)
M1 machines HATE having any sort of KEXT exception in profiles.
when it comes to KEXT vs. SYSEX..... 100% make sure you put them in separate profiles. 😉
( as in, keep your kext exceptions and sysex exceptions in separate profiles.)
M1 machines HATE having any sort of KEXT exception in profiles.
I'll definitely keep them separated, so thanks for the confirmation there. We have had a single KEXT profile for a long time that covers things like Google Drive and Sophos, but where I went wrong was building a second profile that only had the new IDs for CrowdStrike. It tested great for just putting CrowdStrike on a mac, so I went ahead and scoped it to the machines in addition to our original KEXT profile thinking it was okay. What seemed to happen instead was that the CrowdStrike-only KEXT profile was overwriting the previous one despite both being scoped. Things didn't get back to normal until I took what was in the CrowdStrike profile and appended it to the original approved KEXTs profile. Then I very carefully pushed and used plutil in a script policy to double check all the the expected team IDs were there. This seemed opposite to the PPPC setttings. I wonder if System Extensions requires you to have only a single policy per computer? I ended up setting it up that way since we have Sophos and CrowdStrike for now and scoped it to Big Sur only after getting burned on the KEXT issue. The other strange thing is that I created two content filter profiles, one for Sophos and one for Crowdstrike, then scoped both of them to the same machine. It seems to work and no one reported the Filter Prompt during the rollout, but still seems like another thing that shouldn't work. Both Kernel Extensions and PPPC payloads are described as "Exclusive" by Apple, while System Extensions and Web Content filter are "Combined". Has anyone had success combining KEXT profiles with Jamf, or does everyone do what I am doing and make sure there is only one scoped KEXT profile per computer that has all the info needed?
I'll definitely keep them separated, so thanks for the confirmation there. We have had a single KEXT profile for a long time that covers things like Google Drive and Sophos, but where I went wrong was building a second profile that only had the new IDs for CrowdStrike. It tested great for just putting CrowdStrike on a mac, so I went ahead and scoped it to the machines in addition to our original KEXT profile thinking it was okay. What seemed to happen instead was that the CrowdStrike-only KEXT profile was overwriting the previous one despite both being scoped. Things didn't get back to normal until I took what was in the CrowdStrike profile and appended it to the original approved KEXTs profile. Then I very carefully pushed and used plutil in a script policy to double check all the the expected team IDs were there. This seemed opposite to the PPPC setttings. I wonder if System Extensions requires you to have only a single policy per computer? I ended up setting it up that way since we have Sophos and CrowdStrike for now and scoped it to Big Sur only after getting burned on the KEXT issue. The other strange thing is that I created two content filter profiles, one for Sophos and one for Crowdstrike, then scoped both of them to the same machine. It seems to work and no one reported the Filter Prompt during the rollout, but still seems like another thing that shouldn't work. Both Kernel Extensions and PPPC payloads are described as "Exclusive" by Apple, while System Extensions and Web Content filter are "Combined". Has anyone had success combining KEXT profiles with Jamf, or does everyone do what I am doing and make sure there is only one scoped KEXT profile per computer that has all the info needed?
Here is the simplest answer I think I can give...
Suggest breaking your exceptions / PPPC profiles into two groups....
10.15.x and below... and 11.x and above...
10.15.7 and below:
Put ALL of your KEXT / SYSEX / PPPC / Traffic or Content Filters -> 1 profile -> fine. no issue.
'allow user to approve' options in PPPC (e.g. screen-recording for teams) -> no workie.
scope to all machines that are NOT 11.x or above (via smart group)
11.x machines ( including M1 😞
SYSEX ( system extensions ) ONLY !!!!
ABANDON any/all use of KEXT, and any exceptions in your profiles.
Put ALL of your SYSEX / PPPC / Traffic or Content Filters -> 1 profile -> fine. no issue.
'allow user to approve' options in PPPC -> work like a charm.
scope to machines that are 11.x or above (via smart group)
