Posted on 02-03-2021 03:57 PM
We've started to deploy Crowdstrike on Apple Silicon machines and are running into issues with the kernel extensions due to the machine security policy being set to "Full Security" by default. Right now our end-users are seeing a "system extension blocked" pop-up every 30 minutes.
Apple's support page says if you have Automated Device Enrollment with an MDM then it can be automatically authorized upon contacting your MDM vendor. I can’t find any Jamf support articles that actually explain how to make this change.
How do we do this?
We're going to have a handful of existing machines where we'll need to force them into recoveryOS mode to change it manually and then I want ALL new machines going forward to have this handled automatically via the way Apple claims it can.
Posted on 02-03-2021 04:34 PM
You cannot completely pre-approve KEXTs in Big Sur.
KEXTs required the user to allow them to load and reboot, period. Pre-approving allows the user to do this, without having to reboot into recovery. This is not an MDM/Jamf Pro issue. This is by Apple design, please thank your Apple representative.
CrowdStrike only uses a KEXT if you have Firmware Analysis turned on, so that is what would generate a KEXT prompt -- for that reason, I have recommended that we do not have Firmware Analysis turned on -- I don't want users being prompted to approve required security software (because most will ignore it).
Posted on 02-03-2021 08:36 PM
Technically, Apple is telling you to stop using kexts altogether in Big Sur, and their guidance about automatic approvals through MDM is only true for Catalina and earlier. There is a macOS MDM command to reboot and rebuild the kext cache which supposedly can replace a user's manual approval, but Jamf does not support it yet. We're running into this with Carbon Black.
Posted on 02-04-2021 05:05 AM
You can't (MDM) approve the KEXT on Big Sur.
If you want to not have the popup then remove the Firmware Analysis setting from your prevention policy and you might as well strip out the KEXT of your profile
Posted on 02-04-2021 10:53 AM
The KEXT Config Profile does apply in Big Sur, it just doesn't function the exact same as it did in previous OS Versions.
Yes, Apple is telling customers, and vendors, to stop using KEXTs. However:
But, we all need to move to them. Yet another of Apple's gift to enterprise.
Posted on 02-12-2021 01:21 PM
@alexjdale - if it's just a scripted command then what is the issue with Jamf? I'm not going to ask anyone to do this manually because that's just asking for chaos.
Crowdstrike is going to need to overhaul their marketing schtick because they're a broken record when it comes to letting you you know that "we run at the kernel level."
The machines that I have been testing on don't receive a pop-up to Approve anything (making me think the approval config works), they just receive the notice that Crowdstrike's KEXT has been blocked - as shown in the original post.
Posted on 04-16-2021 04:25 AM
It's clearly stated on Apple's support page that the MDM vendor should support this functionality, for devices enrolled via Automated Device Enrollment.
Posted on 04-16-2021 06:13 AM
You will need to utilize the Jamf Pro API to load legacy KEXTS on BS with Apple Silicon
#!/bin/bash
### Restart computer via MDM command & rebuild kernel cache after installing legacy kext(s) in Big Sur
### You would think this would be easier... but it's not?! Must use Jamf API with a touch of 'the crafty'...
### 2021.04.05 - JW
### WARNING!!! Computer will reboot immediately with zero notification!
### Background: Despite Apple still allowing legacy KEXT installs on Big Sur (via Jamf/MDM), the process is not that smooth.
### The post-install user approval/restart process is still very UGLY.
### Simply pre-approving KEXT ID's via config profile is not enough.
### We need to either automate away the uglies, or leave it to the standard user to do so (blech!)
### Pulling info from here (though needed some significant tweaking):
### https://www.jamf.com/jamf-nation/articles/793/manage-legacy-kernel-extensions-in-macos-11-using-jamf-pro
### And some mechs & ideas from here for api/json formatting etc:
### https://gist.github.com/talkingmoose/327427d23b422000f9d17183f8ef1d22
### This all very rudimentary- take with a grain of salt & LOT'S OF CAUTION!
### -JW
###----------------------------------------------------------------------------------------###
### Custom Variables
###----------------------------------------------------------------------------------------###
jamfProURL="https://ORG.jamfcloud.com"
### API username/pass
### For now, let's use Jamf policy script parameters we can switch to encrypted script creds later.
username="$4"
password="$5"
### Note: the Jamf API user level permissions required are:
### Jamf Pro Server Objects: Computers (Read)
### Jamf Pro Server Actions: Send Mobile Device Restart Device Command
### Jamf Pro Server Actions: View MDM command information in Jamf Pro API
###----------------------------------------------------------------------------------------###
### Get an api authorization token (auth lasts 30 minutes, but we'll expire at end of script)
###----------------------------------------------------------------------------------------###
# create base64-encoded credentials
encodedCredentials=$( printf "$username:$password" | /usr/bin/iconv -t ISO-8859-1 | /usr/bin/base64 -i - )
# generate an authorization bearer token
authToken=$( /usr/bin/curl "$jamfProURL/uapi/auth/tokens" --silent --request POST --header "Authorization: Basic $encodedCredentials" )
# Clean up token to omit expiration details
token=$( /usr/bin/awk -F " '{ print $4 }' <<< "$authToken" | /usr/bin/xargs )
###----------------------------------------------------------------------------------------###
### Do the things...
###----------------------------------------------------------------------------------------###
### 1) Obtain the computer's mdm managementID.
### Why this is such a chore to obtain is beyond me... if anyone ever finds an easier way PLEASE TELL ME!
### https://www.jamf.com/jamf-nation/articles/793/manage-legacy-kernel-extensions-in-macos-11-using-jamf-pro
### Based on details of link above, and a bit of tweaking, this API call will return details of ALL computers!
### (number of devices to return info on is set by size parameter in curl line)
### HOWEVER, we only need our current workstations's managementID from this mass of data!
### Lets grab our computer's serial number and parse/filter the API data found between it (our desired serial) and the key 'isManaged' to obtain our 'managementID'.
serialNumber=$( system_profiler SPHardwareDataType | awk '/Serial/ {print $4}' )
managementID=$( curl -X GET "$jamfProURL/uapi/preview/computers?size=2000" -H "accept: application/json" --header "Authorization: Bearer $token" | awk '/'$serialNumber'/ {p=1; next} /isManaged/ {p=0} {if (p==1) print $0}' | grep 'managementId' | awk '{ print $3}' | sed 's/[,"]//g' )
### testing reference to make sure our values are correct:
echo $serialNumber
echo $managementID
### 2) Restart device via MDM command & rebuild kext cache in the process
### WARNING!!! notifyUser flag does not seem to be working as intended?!? Will reboot immediately!
### As we'll be running this immediately after installing a legacy KEXT, let's give installer 15 sec to finish up... just in case.
sleep 15
### Initiate the restart
curl "$jamfProURL/api/preview/mdm/commands"
--request POST
--header "Authorization: Bearer $token"
--header "Accept: application/json"
--header "Content-Type: application/json"
--data-raw '{
"clientData": [
{
"managementId": "'$managementID'",
"clientType": "COMPUTER"
}
],
"commandData": {
"commandType": "RESTART_DEVICE",
"rebuildKernelCache": "true",
"notifyUser": "true"
}
}'
###----------------------------------------------------------------------------------------###
### Expire our authorization token
###----------------------------------------------------------------------------------------###
curl "$jamfProURL/uapi/auth/invalidateToken"
--silent
--request POST
--header "Authorization: Bearer $token"