It is possible to deploy and manage LucidLink installation and KEXT approval on macOS via an MDM solution such as Jamf Pro. In this guide we will look at the steps necessary to achieve this in Jamf Pro.
For an end-to-end zero-touch user workflow the following requirements must be met:
- The Mac is in ABM (Apple Business Manager)
- ADM (Automated Device Enrollment) is configured between ABM and Jamf Pro
- A PreStage Enrollment has been configured and the Mac is in this scope
- The Mac has undergone the PreStage Enrollment from a fresh install or out-of-the-box
It is possible to deploy LucidLink and approve the lucidfs KEXT with a Mac in Jamf via User-Initiated enrollment although physical interaction with the Mac is required. Since you cannot escrow a BootStrap Token if the Mac has not gone through a PreStage Enrollment.
- 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 Jamf Pro instance.
- During the Apple Setup screen the Mac will undergo a Jamf Pro PreStage Enrollment which will allow a Bootstrap token to be escrowed in Jamf once the user logs into macOS. This is important to facilitate the deployment of an “Approved Kernel Extension” payload without the need to manually enter macOS Recovery Mode and the Startup Security Utility on Apple SIlicon Macs.
- The Mac reaches the Desktop.
- The Mac is added to the scope of a Configuration Profile in Jamf Pro that contains an “Approved Kernel Extension” payload, containing the TeamID for the lucidfs KEXT.
- The Mac is added to the scope of a Policy in Jamf Pro that installs the LucidLink .pkg and contains a “Restart Options” payload to rebuild the KEXT Cache.
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.
PreStage Enrollment Setup
There are no specific options or checkboxes in the PreStage Enrollment configuration that are required to allow Jamf to set “Reduced Security” mode. The act of enrolling the Mac this way is what generates the trust between ABM, Jamf Pro and macOS.
There are no specific setup requirements, only that the PreStage Enrollment is configured in Jamf Pro and the Mac is part of the 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 Jamf Pro.
Configuration Profile Setup
The Configuration Profile contains details of the Kernel Extension and should be deployed to the Mac prior to installation of the LucidLink application (see Policy Setup).
This should be deployed after PreStage Enrollment, deploying as part of PreStage Enrollment will fail.
- In Jamf Pro navigate to Configuration Profiles
- Click New
- Use the following settings:
- General > Name = lucidfs
- General > Level = Computer Level
- Approved Kernel Extensions > Allow users to approve kernel extensions = YES
- OPTIONAL: Approved Kernel Extensions > Allow standard users to approve legacy kernel extensions (macOS 11 or later) = YES
- Approved Kernel Extensions > Approved Team ID > Display Name = LucidFS
- Approved Kernel Extensions > Approved Team ID > Team ID = 3T5GSNBU6W
Once configured, this can be deployed to the Macs in question, the KEXT will not need user’s to click Allow. The payloads in the Policy Setup section will automate rebuild of the KEXT cache.
Important Note: The Lucid application has a different Team ID (Y4KMJPU2B4) to the Kernel Extension (3T5GSNBU6W). For the purposes of deployment and security around KEXTs, please use the Team ID (3T5GSNBU6W) for the KEXT approval.
This should be deployed after the Configuration Profile, to ensure that when we attempt to load the Kernel Extension, it is already in the list for Allowed KEXTs.
- In Jamf Pro navigate to Settings > Computer Management > Packages
- Click New
- Display Name = LucidLink + Version Number (e.g. LucidLink-2.1.4286)
- Choose File > Upload the desired LucidLink .pkg
- Navigate to Policies
- Click New
- Use the following settings:
- General > Display Name = LucidLink
- General > Enabled = YES
- General > Trigger = This is up to you, but the first attempt has to happen after initial PreStage Enrollment and Apple Setup.
- Packages > Find your Package and click Add
- Restart Options > MDM Restart with Kernel Cache Rebuild = YES
- Restart Options > KEXT Path = /Library/Filesystems/lucidfs/lucidfs.fs/Contents/Extensions/11/lucidfs.kext
- Restart Options > No User Logged In Action = Restart immediately
- Restart Options > No User Logged In Action = Restart
- Restart Options > No User Logged In Action > Delay = 5
- Restart Options > No User Logged In Action > Start the restart timer immediately = YES
Once this is deployed to the Mac via a trigger or Self Service, the LucidLink .pkg will install silently. It will pop up for the User to go to System Preferences to Allow the KEXT, the user should not do this.
A restart timer will begin, the user will be notified their Mac will restart in 5 minutes, so that they have time to close and save work. The Mac will then restart and rebuild the KEXT cache, this is what Allows the KEXT automatically.
Following this restart, the user will be able to login, run Lucid and link to their Filespace.
Q. Does FileVault being enabled affect deployment of the KEXT Payload?
A. No, FileVault has no bearing on MDM being able to set Reduced Security mode.
Q. What is the process for Intel Macs?
A. 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 PreStage Enrollment.
Q. Is the process the same for macOS Ventura?
A. Yes. The Secure Token and Boot Strap Token functionality as it is today started with macOS Big Sur.
Q. What about T2 Intel Macs?
A. The deployment method is the same as an Intel Mac, providing you do an "MDM Restart with Kernel Cache rebuild" post install Lucid the user doesn't have to click Allow manually.
Q. Will I need to allow the KEXT again when I update Lucid?
A. 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. As in the main workflow, we advise following Install (or Update) of Lucid with a Restart Options payload containing the "MDM Restart with Kernel Cache Rebuild" option checked.
Q. If a Mac did not go through PreStage Enrollment, can I retrospectively allow MDM control of the security mode?
A. 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 Jamf Pro to deploy a KEXT Payload without the user entering Recovery Mode > Startup Security Utility.
You may want to script a version validation and Lucid update procedure for your macOS clients so that you don't need to create a new policy with every release of LucidLink. The Bash script attached at the bottom of this article (lucidUpgradeCheck.sh) will check if Lucid is installed and if it is, return 2 variables internally ($installedVersion and $latestVersion). This does not rely on Lucid running and does not rely on Lucid being installed.
Using these variables and a comparison you could trigger updates of Lucid on a trigger such as a macOS logout or login. We provide this script as a barebones, base script from which you can build your own procedures.
You can read more about macOS Secure Token and Bootstrap Tokens here: https://support.apple.com/en-gb/guide/deployment/dep24dbdcf9e/web
Here is more information on deploying KEXTs with Jamf Pro: