Disclaimer: This blog is not intended to be advice on how to manage your environment. As the name suggests, these accounts are based on experiences I’ve had in my own lab. Always approach information you find outside (or inside for that matter) official documentation with skepticism and follow the golden rule: Never test in production.
For many Administrators, MDM for Windows has historically been a smattering of scripts, agents, group policy, and registry changes. No matter if you used ConfigMan, DesktopCentral, Smart Deploy, or even good ol’ fashioned MDT the underlying premise has always been the same: Distribute a payload and run it. With the advent of MDM in the cloud, very little has changed in this regard except the exposure we receive to the inner workings of the platform. With no on-prem infrastructure to build and maintain, we often learn just enough to make services like Intune do what we want and move on without a second thought to why or how. In my experience, this ‘keep it simple’ approach is fine for most small organizations, however sooner or later we are all faced with a need to push the limits of what turn-key offerings can provide and look closely at the gears under the hood in order to move forward.
If you have ever managed an Apple device, you know this story all too well. Despite their market dominance of the mobile world, Apple maintains a fractional foothold in the desktop OS space and thus are often neglected by organizations where the MacOS footprint is limited to a handful users. Platforms like JAMF or VMWare’s Workspace One are often considered too costly (whether that’s true or not) to implement for such a limited use case and Administrators are left to choose either leaving them un-managed or rejecting them in the environment entirely.
Enter the hero of our story: Microsoft Intune. The all inclusive, one stop shop for your device management needs. It’s ready to integrate with everything Microsoft and if you already pay for SCCM/MEMCM, EMS, or M365 E3 or E5 you already own it! Well… sort of. I’m not going to get into the licensing as (per usual) it’s complicated. But it is true that with Intune, we can manage Windows, iOS, Android, and MacOS albeit with diminishing turn-key options as we go down the list.
How it Works
While Microsoft has made fantastic strides in their cross platform capabilities all around, the fact of the matter is when it comes to MacOS it flatly does not compare to other MDM providers that have offered Mac management for far longer. There are a number of reasons, but to understand why we first have to understand how Apple MDM architecture works.
From a high level, Apple uses their Push Notification Service (APNS) to let the device know that it has new configurations to pull down. They do not, as commonly believed, PUSH configurations to the device. Once received, the device reaches out over HTTPS to exchange property lists (plists), executes new MDM commands within them, then report the results back to the MDM server. These MDM commands are baked into the OS by Apple and are therefor (usually) universally applicable regardless of the MDM provider (You can find a list of these commands and their supported devices HERE). However, generally speaking this is where the similarities end. In order to do more, each provider must implement it’s own methodology to execute and deploy configurations beyond Apple’s supported means.
A key difference that sets Intune apart from the likes of JAMF is the lack of a managed admin account. Whether the device is enrolled manually or through Automated Device Enrollment (ADE); the end users account is the first and only one created out of the box. For better or worse, Intune leverages the root account (unless otherwise designated) to elevate and run functions like scripts and packages via the Intune Management Extension (not to be confused with Kernel or System Extensions). Without either of these, the user would be perpetually bombarded by Gatekeeper to elevate and implement everything we throw at them.
The Problem and Why it Matters
Recently I had a customer looking to enable FileVault on a number of shared machines. While Intune can easily enable encryption on MacOS and escrow the recovery key for backup to Azure and rotation. The problem begins to surface when we attempt to implement shared Apple workstations with multiple accounts.
As you may already be aware, once FileVault is enabled, the login screen is replaced with its own authentication to unlock the disk. Only users who are FileVault enabled can accomplish this regardless of admin privileges. We can enable additional users via System Preferences, but how do we automate this? Well, the short answer is with Intune we can’t… At least using any means I’ve been able to identify. If you have a solution, please let me know in the comments below. In the mean time, let me explain why.
In order for a user to be enabled for FileVault, they first need to be enabled for SecureToken and Bootstrap. By default, the first (non-mobile) user to implement a password is enabled for SecureToken, then Bootstrap is enabled after the first time they log in with a SecureToken enabled account. During normal operation, this is the account the user created during Setup Assistant. No accounts after the first will receive the same treatment and as we discussed earlier, since Intune does not create a managed admin account, it simply does not have the local rights to manage FileVault further beyond the initial enablement and escrow.
Now, it is worth pointing out that while JAMF does offer the option to initiate encryption with either the managed admin account or the current/next user; the managed admin does not initially receive a SecureToken or Bootstrap. This is a step which is set in the configuration payload later on via delayed enablement. You can see a wonderful breakdown of the process (Pre Big Sur) by Frederick Abeloos HERE.
While being able to manage user enablement for FileVault in a way that allows multiple users to authenticate and unlock the disk sounds like a desirable feature and one that could be achieved programmatically with an enabled managed administrator account; it is worth considering the intended use Apple envisioned in FileVaults design, where it falls within the security model Microsoft has encouraged in the rest of their product suite, and what we would be sacrificing should we allow it.
- As is evident in Apples recent history, security of the local system and user privacy is paramount. For this reason, FileVault is intended for use with 1-1 device/user assignments. In their mind, no one else besides the end user should be able to access the physical system without the end user’s consent. While they have given us great capabilities to integrate their devices into the enterprise space, Apple devices are first and foremost user “owned” and core functionality services like FileVault reflect that mantra.
- Microsoft’s stance for privileged accounts has always been one of eliminating them outside of a central identity provider. Even Windows devices disable the local admin account and scramble the password by default and offer no readily available alternative with their cloud platforms. (See You can use Intune to create a local admin account, but that doesn’t mean its a good idea – Out of Office Hours for more info on that)
- Given point #2, if Intune offered a managed administrator similar to their competitors (even if we could rotate the password periodically like LAPS) we are still left with an account that could be compromised locally with the ability to unlock encryption which is never advisable. That said, you can certainly script the creation of a local admin account, but with the limited toolset Microsoft provides us within Intune, there’s very little we can do to leverage it today beyond physically elevating a process when the end user has ‘standard’ permissions.
Putting FIleVault itself aside: It’s clear Microsoft has chosen a different strategy to work within the bounds of Apple’s framework. Asking for more can be a difficult task given the frequency and limited disclosure Apple is willing to give in advance of new releases as well as a challenge to the bigger picture offered by their security model. Until then, we shall continue to search endlessly for solutions which to us feel like no brainers and curse at the long dead threads concluding with little more than “Just use JAMF”. It is my hope at least that you walk away from this post with a greater understanding of how Intune manages MacOS and what considerations are required to avoid using the other big players.