Introduction
It is possible to deploy and manage LucidLink installation and KEXT approval on macOS via an MDM solution such as Kandji. In this guide, we will look at the steps necessary to achieve this in Kandji.
For an end-to-end zero-touch user workflow the following requirements must be met:
- The Mac is in ABM (Apple Business Manager).
- ADE (Automated Device Enrollment) is configured between ABM and Kandji.
- An Automated Device Enrollment Profile has been configured, the Mac is in this scope and it has undergone the ADE from a fresh install or out-of-the-box.
It is possible to deploy LucidLink and approve the lucidfs KEXT with a Mac in Kandji via Manual enrollment although physical interaction with the Mac is required. Since you cannot escrow a BootStrap Token if the Mac has not gone through an Automated Device Enrollment.
Important Note: When Lucid or macOS are updated, sometimes macOS requires the KEXT be "Allowed" again. In these instances you may have to create and deploy a Custom Scripts Library Item containing only a script with the "MDM Restart with Kernel Cache Rebuild" procedure. As per the Custom Apps PostInstall script step, below.
Workflow Overview
- The Mac is added to the ABM instance by Apple, an Apple Authorised Reseller, or manually via Apple Configurator for iOS.
- The Mac is powered on, out of the box, or freshly reinstalled, and checks in with ABM which then forwards the Enrollment to the instance.
- During the Apple Setup screen, the Mac will undergo an Automated Device Enrollment which will allow a Bootstrap token to be escrowed once the user logs into macOS. This is important to facilitate the deployment of a “Kernel Extension Profile” without the need to manually enter macOS Recovery Mode and the Startup Security Utility on Apple SIlicon Macs.
- The Mac reaches the Desktop and deployment of the Blueprint components will begin, once Lucid is successfully installed an automatic Restart will be initiated.
If the above steps are followed, Lucid will be installed and the KEXT automatically Allowed with no user intervention. This is applicable to both Apple Silicon Macs and Intel-based Macs.
When the Custom App installation completes, providing NotifyUser is set to True (it is by Default in the script attached here) in the Restart Command, the user will be be notified that the system will restart automatically. At this point the user should not manually restart the Mac. They should ignore any pop-ups to Allow the Kernel Extension and simply wait for the restart to happen automatically.
Automated Device Enrollment Setup
There are no specific options or checkboxes in the Automated Device Enrollment configuration that are required to allow Kandji to set “Reduced Security” mode. The act of enrolling the Mac this way is what generates the trust between ABM, Kandji and macOS.
There are no specific setup requirements, only that the Automated Device Enrollment is configured in Kandji and the Mac is part of the Blueprint scope. You need to ensure that the Mac does have internet connectivity at login time, it is at this stage that macOS will escrow the bootstrap token with Kandji.
Kandji API Token Settings
- Navigate to Settings > Access > Add API Token > Name = LucidLink Restart
- Copy the Token and keep it safe and secure in a password vault!
- Manage API Permissions > Configure
- Check the following Device Permissions
- Device List
-
Restart Device
- Save
Kernel Extension Profile Setup
- Navigate to Library > Add New > Profiles > Kernel Extension > Add & Configure
- Name: LucidLink Kernel Extension
- Settings:
- Allow users to approve kernel extensions = Yes
- Allow standard users to complete KEXT install = Yes
- Name = LucidFS
- Team ID = 3T5GSNBU6W
- Save
Custom App Setup
- Navigate to Library > Add New > Custom App > Add & Configure
- Name: LucidLink
- Settings:
- Installation = Audit and enforce
- Self-Service = Your Choice
- Install Details
- Installer Package
- Click to upload > Select the latest LucidLink installer .pkg
- Restart after successful install = No
- Save
- Navigate to Library > LucidLink > Edit
- Settings:
- Audit Script = Use the sample audit script attached to this KB (Ref 1)
- Preinstall Script = Use the sample preinstall script attached to this KB (Ref 2)
- Postinstall Script = Use a modified version of the Postinstall script attached to this KB (Ref 3)
- Save
Audit, Preinstall and Postinstall Scripts
Audit Script (Recommended) - The sample script provided here will check for the existence of the Kernel Extension Profile before installing Lucid, to avoid problems. If the app is not installed but the Kernel Extension Profile is, only then does the installation proceed.
Preinstall Script (Recommended) - This script checks for the existence of Rosetta2 installed on the local machine (if necessary, for Apple Silicon Macs) and installs if not present. This is required for the Lucid installer and app to run.
Postinstall Script (Required) - This script is what works the magic and allows the Kernel Extension automatically. Kandji has now made the "RebuildKernelCache" option available through the Device Restart API call.
For this to work, you must first generate an API token in your Kandji instance, and assign the necessary permissions to it as described in the above section "Kandji API Token Settings". You must copy this saved token and replace the template token variable in the "lucidlink_postinstall.sh" script on Line 63.
You must also replace the template api_url variable on Line 59 of the script, with your instance Kandji API URL.
FAQ
Does FileVault being enabled affect the deployment of the KEXT Payload?
No, FileVault has no bearing on MDM being able to set Reduced Security mode.
What is the process for Intel Macs?
The process is essentially the same except there is no concept of "Reduced Security" mode on Intel Macs, therefore the KEXT Payload can be deployed without the need for Automated Device Enrollment.
Is the process the same for macOS Ventura?
Yes. The Secure Token and BootStrap Token functionality as it is today started with macOS Big Sur.
What about T2 Intel Macs?
The deployment method is the same as an Intel Mac, providing you use the Postinstall Script provided to install the Lucid Custom App, the user doesn't have to click Allow manually.
Will I need to allow the KEXT again when I update Lucid?
It is possible that macOS marks the KEXT as "Updated" or "Modified" when you update Lucid since we will overwrite the lucidfs KEXT. In these cases, you may be asked to Allow the KEXT again. We advise including the Postinstall script (attached) in any future Lucid Custom Apps, to ensure the Kernel Cache is rebuilt successfully.
If a Mac did not go through Automated Device Enrollment, can I retrospectively allow MDM control of the security mode?
Currently, no. Escrowing the Bootstrap Token and having a user with a Secure Token is not enough to allow MDM to set the Security Mode. You can escrow a Bootstrap Token manually after User-Initiated Enrollment but it will not allow Kandji to deploy a KEXT Payload without the user entering Recovery Mode > Startup Security Utility.
References
- Audit Script - lucidlink_audit.sh (attached at the bottom)
- Preinstall Script - lucidlink_preinstall.sh (attached at the bottom)
Ref: https://github.com/kandji-inc/support/blob/main/Scripts/InstallRosetta2.sh - Postinstall Script - lucidlink_postinstall.sh (attached at the bottom)
You can read more about macOS Secure Token and Bootstrap Tokens here: https://support.apple.com/en-gb/guide/deployment/dep24dbdcf9e/web
Kandji Knowledge Base
https://support.kandji.io/support/solutions
Special thanks to Ryan Slater of Kandji for collaboration and testing.