If you have to install version 6 and above of crowdstrike on bigsur, have to install their unsigned profile first. This profile only be uploaded and distributed with MDM solutions.
In order to upload to MDM, that profile needs to be signed first.
Original location of the profile --- > https://supportportal.crowdstrike.com/s/article/Tech-Alert-Preparing-for-macOS-Falcon-Sensor-6-11
1 - Follow Steps explained here,
If jamf freezes during generate of pem, ignore it & refresh the page
2- After it is generated under keychain, please locate the certificate and look for "Subject Key Identifier" Value. Copy it to clipboard and remove spaces.
3- Generate signed version of the mobile config profile following below command at terminal
sudo /usr/bin/security cms -S -Z SubjectKeyIdentifierValue -i ActualPathofUnSignedProfile -o OutPutWhereYouLiketoSaveSignedProfile
This covers everything required except the notifications. If you are still getting prompts for KEXT (Install CS, disable network, no prompt? Enable network, prompt comes up within 5 minutes?), disable "BIOS/Firmware Standard Visibility" on the CS console.
As recommended earlier, having one profile with all the settings may be a problem in the future with Big Sur/M1 and kernel extensions. The general recommendation is to separate them out as per the above link. Makes scoping and troubleshooting easier as well.
I came across this thread after having all the same issues posted here, did a lot of troubleshooting and think I have this working.
Manually recreating the settings doesn't seem to work; it messes up for some reason. I think it adds fields.
To fix this download the plist posted above at:
Posted: 1/27/2021 at 2:59 PM CST by ghart
Save that data as a .mobileconfig file
Take the time and follow the instructions OP posted on signing the file. THIS IS MANDATORY. I thought I'd be able to get around this; no dice.
Upload the newly signed file and distribute via configuration profiles.
Push the installation package via a package.
Push the script to connect with your customer ID via a package.
No pop ups.
I've tested this on a newly installed Big Sur. Next I am going to test this on Catalina (which is working without the signed file) and then upgrade the machine to Big Sur. This is important because even though it worked on Catalina without a signed file, when upgrading to Big Sur the machine gave pop ups.
-Edit. It installs fine on Catalina with the exact same process and configuration profile. Next I will upgrade the Catalina Machine to Big Sur to see if there are any pop ups.
-edit2: updating Catalina to big sur did not prompt any additional notifications. I consider my testing basically complete and ready for a small rollout followed by mass rollout.
@sumitjha Check to see if you have "Firmware analysis" or "BIOS/Firmware Standard Visibility" enabled on the CrowdStrike console for your clients (Not sure exactly what it's called as I don't have access. If yes, that's where the prompt is coming from and until CrowdStrike updates that component to use a System Extension instead of a KEXT there is nothing that you can do, other than to disable this feature.
I have only tested twice but this config is working for me ( I am not seeing the update approval pop up) I have not asked the security team if it's working as they need from console side ... and we tried disable "BIOS/Firmware Standard Visibility" on the CS console.. that did not fix the issue according to the security team..
I think key is the "Network Extension" check box...
Thanks for posting that link!!!
Looks like there are new directions on how to build the profile by hand...
Also it says download the CS made profile with Chrome ...so that could be causing an issue ...
I'm trying to push the new Crowdstrike built configuration profile from Jamf 10.28 to my computer, however Jamf gives the status code "<Exception> -[__NSCFConstantString objectForKeyedSubscript:]: unrecognized selector sent to instance" and it tells me the installation failed.
EDIT: This apparently is an issue with the profile not being signed. Is this a my machine problem?
Hey everyone, this has been a great resource for getting past some of the stuff I had going on with CS.
Did anyone find a way to bypass the "machine is already licensed" error? When I first did this, I was using a script I had from a POC we did about 8 months ago. It installed the program locally, but it did not show up in the portal. Basically almost all of my POC machines have this error, and since they are not in the CS portal I can't get a token to uninstall the program.
Would be very interested if anyone has a fix for this.
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.
@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.
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.
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'
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/.
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)