Deploying Jamf from another service

[pbenware1]

Here's one out of left field, from my security group...

We have a number of computers (Macs, windows, etc) reporting in CrowdStrike, Axonius, and other services.  Not all of the Macs are enrolled in Jamf, for reasons good and bad, and we need to get them enrolled.

The security team is looking for ways to deploy Jamf without needing to visit the computer (identifying user and location can be a challenge).  I know nothing about whatever process CrowdStrike might use for this.  I do know that installing MDM software on Windows computers can be done via Active Directory, and apparently CrowdStrike uses a some kind of method for deploying MSI or exe installers to Windows computers.

I also know at one time Jamf had a quick add package that could, maybe, have been deployed from CrowdStrike or other tool that can support macOS pkg files, but today Jamf deployment depends on having the user, at the computer, download and install, with authentication, the Cert and MDM files.

As best I know, enrolling a Mac into Jamf really can't be automated.  Am I wrong about that?

[AJPinto · Accepted solution]

Your options are not good. Keep in mind they are comparing joining AD, a 20+ year old workflow with modern MDM enrollment workflows. To say that the security surrounding enrolling devices has improved just a wee bit in the past two decades is an understatement. Microsoft also has AD viewed as a point of authority that can register a device with Intune, Apple does not have this same concept. 

If your devices are all in Apple Business Manager, assigning them to Jamf may cause the enrollment process to automatically trigger with DDM. However, you would be accepting whatever situation those devices are in as "trusted" when enrolling which exposes your environment to risk. I have never needed to test this kind of post activation DDM based enrollment, so I can't say for sure how well it works. 

Apple retired the ability to enroll into MDM from CLI back with macOS 10.15, which in turn ended the ability to use a quick-add package to enroll into MDM. This closed off any options to use something like CloudStrike or Axonius to deploy a package to attempt to force an enrollment. 

The two main ways to enroll a device.

1. Device Enrollment, where a user manually enrolls the device into MDM. This does not give supervision over the device but does give management. If the device is in ABM, you can use the profiles binary to change the enrollment type and supervise the device. This is an incredibly hands on enrollment method.
2. Automated Device Enrollment, this requires the device to be in ABM, and have macOS reinstalled. On macOS activation the device is forced into management. 

https://it-training.apple.com/tutorials/apt-deployment/#understanding-device-and-user-enrollment

---

As best I know, enrolling a Mac into Jamf really can't be automated.  Am I wrong about that?

---

Technically no, device enrollment can be fully automated. Fully automated how apple wants it done, which is during device activation. Any enrollment of a fully activated macOS will require interaction, which is by direct design by Apple. 

One thing I learned with managing Apple products. You do it Apples way or not at all, you cannot manage a Mac like a PC.

TL;DR: Apple has deliberately designed macOS device enrollment to require user interaction unless using Automated Device Enrollment (ADE) via Apple Business Manager (ABM) during activation. While technically possible to automate ADE post-activation, this introduces security risks. Fully activated macOS devices will always require some user interaction for enrollment, as per Apple's strict design.

[pbenware1]

Thanks @AJPinto that's about what I thought.

We do use Apple School Manager; it's required now for all new Mac purchases that are done through our procurement platform.

The majority of devices in question either weren't purchased through the procurement platform, making getting them into ASM a challenge, or they are in ASM, but were not assigned to an MDM server before they were setup.  ASM is a relatively new requirement, and we have more than 50 MDM servers in our ASM instance, so the auto-assignment is not enabled.  We've addressed the second problem by proactively assigning all Macs to the correct MDM in ASM, but the first problem remains an ongoing concern.

At the end of the day, it's a few hundred Macs, so we will likely have to have field support suss out where they are, or just handle it through attrition.  Which is what I've been telling the security spooks for the last 5 months.

[AJPinto]

Devices can be retroactively added to ASM. If they were purchased from an authorized reseller in the past, they can still go back and add the device now that you have ASM. The other option is hands on with Apple Configurator.

50 MDM servers would drive me nuts lol. I'm figuring a unique server for each campus or something to that effect. It may be a good idea to consolidate to one server and use Jamf sites, but you know your needs better than I (assuming you are not with an MSP). However, it may be a good idea to have a default MDM server that everything goes to, and have it configured to where you can't enroll devices. This would effectively box in devices at MDM enrollment that you have not processed yet rather than letting them activate as a "personal device".

This unfortunately seems like it would be a boots on the ground situation. Dealing with security can be a challenge if they don't understand how Apple works.  We got a new exec in security recently, and I had some very remedial conversations with him on blocking OS updates last month. He was fully under the impression that apple would allow forever deferrals on major OS updates because Microsoft does and it's just good for business. His eyes were opened lol.