How to Achieve Your Desired End-State Through Auto-Remediation

How do you want the devices you manage to be configured? What settings do you want to be enforced, which apps do you want to be installed, how often should the OS be updated—in other words, what is the end-state that you want to achieve? And how are you going to achieve it? 

Those were the questions that Arek Dreyer and Matt Wilson—senior product engineers at Kandji—discussed at our recent live event, “A Deep Dive into Auto-Remediation.” They’re questions that every Mac admin asks—and is asked—on a regular basis. Arek and Matt looked at the ways Kandji can help you achieve the end-state you want for the Apple devices you manage. 

End-States, MDM, and Agents

Arek: First of all, what do we mean when we talk about the desired end-state?

Matt: You can think of it as, how do you want your devices to be configured? What should they look like once they're configured? That can include the settings you want and the applications that should be installed. You also want to think about, Are there any settings that you want to leave up to the user—maybe allowing them to set their desktop backgrounds, to customize their dock, to choose dark mode or light mode?

Arek: Mobile device management is one of tools admins have to achieve that desired end-state. Just so we’re all on the same page, how would you define MDM?

Matt: It’s a framework Apple has provided that allows admins to configure and manage settings, via the Apple Push Notification service (APNs). Because we're leveraging APNs, those settings are delivered almost immediately when they are assigned to a device.

Arek: And that's for all Apple platforms, right? 

Matt: Yep: macOS, iPad, iOS, and even tvOS. 

Arek: MDM is super powerful and built right in to the operating systems. But what about settings we can't set over MDM? Apple doesn't give us the hooks to do everything we need to do to achieve that desired end-state. What are our other options? 

Matt: On the mobile side of things—iOS and iPad—there’s managed app configuration, an additional set of keys that developers can make available. For example, in Zoom you can preconfigure things like room IDs or authentication protocols, so when the app is delivered to the device, they’re already set up. The user doesn't have to do anything, they can just launch the app and go. 

Outside of that, outside of the MDM framework itself, we are a bit limited on the mobile side of things. But on the macOS side, there are a number of additional tools that we can use to manage the device. One way is with an agent on the device.

Arek: On iOS, iPadOS, tvOS you can't open Terminal and run a script or a command line tool—but we can with macOS. That's where the Kandji Agent comes in.

Managing Apps

Arek: How can you use Kandji to achieve and maintain that desired end-state? 

Matt: One example is our Auto Apps: We test and pre-configure apps and make them available to admins, who can then deliver them to the Mac. You can choose to continuously enforce them, to make sure that an app remains on the device. So if a user accidentally or intentionally removes, say, Python 3 from their system, the Kandji Agent would detect that and reinstall it. 

Arek: How long would we have to wait before the agent reinstalled Python 3? 

Matt: You’d just need to wait for the device’s next check-in, which happens every 15 minutes. Whenever that check-in happens, Kandji will check the Blueprint, see what the end-state should be, and then make sure the device looks like that. 

If an application isn't in our Auto Apps catalog, you can upload a custom app—CrowdStrike, for example. Something I really like to use in those cases is an audit-and-enforce script, which lets you define what the end-state of that device should look like before you install the application. It could be as simple as checking to see if the application is already in the Applications folder. If it's not there, we could have the script exit and kick off the installation process automatically. 

In the case of our CrowdStrike example, we can check for its settings profile, which we've delivered over APNs, to make sure that those settings are in place before the app is installed. We've gone so far as to make sure that the CrowdStrike agent is running properly, and if we don't see that, we can try to restart it. And if that fails, we can trigger a reinstallation to make sure that the security tool remains on the system.

Arek: So the desired end-state is: CrowdStrike is installed, with a particular set of characteristics that are defined in that audit-and-enforce script. And if, for whatever reason, the conditions of that script aren’t met, then the Kandji Agent will re-download the installation assets and perform a completely new installation. 

Matt: Right. And again, this would run every 15 minutes, at every recurring check-in. The audit script would run, determine the device’s current state, and then either reinstall the app if necessary or not because it's there and working properly.

Managing OS Updates

Matt: Managed OS is another good example of achieving a desired end-state with the Kandji Agent. An admin can control when OS updates or upgrades should be installed, while also giving the user some control.

Arek: It's really powerful to let the user install app updates and macOS updates or upgrades when it’s convenient for them. If you’re using an Apple device to get work done, any time you have to stop for an update is inconvenient. With the Kandji Agent, we can give the user a bit more control and pick exactly when to do those updates.  

At the same time, the admin can say, "You've got this window of time. At the end of this window, even if it's inconvenient, we're going to interrupt you to do this update." You can use the Agent to let the user know, "This update's coming. You’ve got five days."

Matt: Our managed OS library item lets you control major upgrades (Big Sur to Monterey, for example) or minor updates (like going from macOS 12.1 to 12.2). You can enforce those settings continuously, so they take effect as soon as an update becomes available. Or you can enforce a specific version, the latest version, or a minimum version, if you want your fleet to be on a certain floor of macOS; the user can manage upgrades beyond that.

Arek: So if you want to be sure that everyone is at least to macOS 12.0.1, you would pick that version. And if the Mac is not at least there, then the managed OS library item will automatically update it.

Matt: Right. We've even gone so far as to store the latest major release of the OS, so you don't have to worry about packaging that and uploading it into Kandji.

Arek: So your desired end-state might be defined as, "We want all Mac computers in our organization to be at least at this version of the operating system." That gives you time to test and make sure that your apps and the other things you use on that device work with the latest version of the OS, before making sure that everyone updates to that one.

Managing Mac Settings

Arek: What about computer settings? What are some of the settings that Kandji customers use to achieve their desired end-states? 

Matt: Let’s take FileVault for example. We've moved all of the relevant settings about FileVault—such as escrowing keys, rotating keys, and requiring a restart to configure FileVault initially—to a single pane of glass, making it easy for the admin to configure. You might need to set up an escrow profile to escrow the key, then a separate profile to rotate of the key, and then a profile that sets up FileVault itself. We've put all of those settings in the same area.

Our agent and auto-remediation come into play if you’re migrating to Kandji or if for some reason the FileVault key is not usable in Kandji's tenant. The agent on the device will detect that, see that the Mac is encrypted, then, if it needs to, it'll prompt the user to enter their credentials to escrow a new key into Kandji; otherwise, you might need to create a special script to do that.  

Arek: What other kinds of settings can be managed that way? 

Matt: One that's really popular is the computer-naming setting. We have a syntax of variables that you can use to define the names of devices, just by dragging and dropping. So if Alice decides she wants to change the name of her Mac to Alice's Cool MacBook Pro, the agent will see that and set it back to the name you want at the next check-in. 

Another one that I actually ran into myself when I first started at Kandji is the sudo timeout period. Sudo essentially lets you run commands in Terminal as the root user. If we have this particular parameter set, you must enter your password each and every time you run the sudo command. When I first got to Kandji, I was like, "Wait a minute, that seems weird." Usually there's a buffer period where you don't have to enter your password again. So I set it back to the default, and then 15 minutes later, it reverted back. So, based on my experience, this parameter definitely works. 

Arek: So again, bringing it back to the desired end-state, the desired end-state in this case might be that every time someone uses the sudo command, you want them to enter their admin password. And this parameter will help make sure that that desired end-state is in place, at least every 15 minutes. 

What if the Mac is offline? What if someone's like, "Hey, I'm going to disable this. I'm going to turn off my Wi-Fi, and just go wild with sudo for 24 hours before I get back on the network."

Matt: Because these settings are downloaded locally to the Mac, in a secure location, they actually run every 15 minutes even when the device is offline. So you get a remediated return to the defined end-state, even if a device doesn't have access to a network.

Arek: So, to recap, when your organization defines the desired end-state for devices, you can use a device management solution like Kandji to help get all your devices to that state. The specific mechanics include using Apple's MDM framework, and that's across all platforms. And then for macOS, we add that extra little bit of help with the Kandji Agent.

Matt: That’s it.