Deploying LucidLink with Jamf Pro MDM

  • Updated

Introduction

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.

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 Policy containing only a Restart Options payload with the "MDM Restart with Kernel Cache Rebuild" option selected. As per the Policy Setup step, below.

Workflow Overview

  1. The Mac is added to the ABM instance by Apple, an Apple Authorised Reseller or manually via Apple Configurator for iOS.
  2. 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.
  3. 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.
  4. The Mac reaches the Desktop.
  5. 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.
  6. 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.

Screenshot_2023-03-13_at_14.24.20.png

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.

  1. In Jamf Pro navigate to Configuration Profiles
  2. Click New
  3. Use the following settings:
    1. General > Name = lucidfs
    2. General > Level = Computer Level
    3. Approved Kernel Extensions > Allow users to approve kernel extensions = YES
    4. OPTIONAL: Approved Kernel Extensions > Allow standard users to approve legacy kernel extensions (macOS 11 or later) = YES
    5. Approved Kernel Extensions > Approved Team ID > Display Name = LucidFS
    6. Approved Kernel Extensions > Approved Team ID > Team ID = 3T5GSNBU6WScreenshot_2023-03-13_at_14.26.44.png

 

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.

Policy Setup

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.

  1. In Jamf Pro navigate to Settings > Computer Management > Packages
  2. Click New 
    1. Display Name = LucidLink + Version Number (e.g. LucidLink-2.1.4286)
    2. Choose File > Upload the desired LucidLink .pkg
      Screenshot_2023-03-13_at_14.34.32.png
  3. Navigate to Policies
  4. Click New
  5. Use the following settings:
    1. General > Display Name = LucidLink
    2. General > Enabled = YES
    3. General > Trigger = This is up to you, but the first attempt has to happen after initial PreStage Enrollment and Apple Setup.
      Screenshot_2023-03-13_at_14.37.57.png
    4. Packages > Find your Package and click Add
      Screenshot_2023-03-13_at_14.39.18.png
    5. Restart Options > MDM Restart with Kernel Cache Rebuild = YES
    6. Restart Options > KEXT Path = /Library/Filesystems/lucidfs/lucidfs.fs/Contents/Extensions/14/lucidfs.kext

      The KEXT path is OS version specific, please refer to the table at the bottom for the necessary paths. You may consider Smart Group based Policies if deploying to multi-version estates.
    7. Restart Options > No User Logged In Action = Restart immediately
    8. Restart Options > No User Logged In Action = Restart
    9. Restart Options > No User Logged In Action > Delay = 5
    10. Restart Options > No User Logged In Action > Start the restart timer immediately = YES
      Screenshot_2023-03-13_at_14.42.09.png

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.

 

macOS KEXT Path
Sequoia (15)
/Library/Filesystems/lucidfs/lucidfs.fs/Contents/Extensions/15/lucidfs.kext
Sonoma (14)
/Library/Filesystems/lucidfs/lucidfs.fs/Contents/Extensions/14/lucidfs.kext
Ventura (13)
/Library/Filesystems/lucidfs/lucidfs.fs/Contents/Extensions/13/lucidfs.kext
Monterey (12)
/Library/Filesystems/lucidfs/lucidfs.fs/Contents/Extensions/12/lucidfs.kext
Big Sur (11)
/Library/Filesystems/lucidfs/lucidfs.fs/Contents/Extensions/11/lucidfs.kext
Catalina (10.15)
/Library/Filesystems/lucidfs/lucidfs.fs/Contents/Extensions/10.15/lucidfs.kext
Mojave (10.14)
/Library/Filesystems/lucidfs/lucidfs.fs/Contents/Extensions/10.14/lucidfs.kext

 

FAQs

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.

Script Ideas

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.

References

You can read more about macOS Secure Token and Bootstrap Tokens here: https://support.apple.com/en-gb/guide/deployment/dep24dbdcf9e/web

https://learn.jamf.com/en-US/bundle/technical-articles/page/Manually_Leveraging_Apples_Bootstrap_Token_Functionality.html

Here is more information on deploying KEXTs with Jamf Pro:

https://learn.jamf.com/en-US/bundle/technical-articles/page/Managing_Legacy_Kernel_Extensions_in_macOS_Using_Jamf_Pro.html

Was this article helpful?

0 out of 0 found this helpful