DEP Macs - Prevent MDM Profile removal?

We have it on. It's...really kind of awful, to the point where I'm almost finished a whole blog post about how badly it needs fixing. In fact, it's the core reason why I still haven't had my users upgrade to High Sierra - because there's no way to remove, update, re-install, or re-enroll a machine short of wiping the entire device in High Sierra with non-removable MDM on, even if you disable SIP to get to /var/db/ConfigurationProfiles , removing that folder just totally breaks all kinds of SIP-locked and MDM-related functions in HS, so it's not the solution it is in 10.12. There's no way to fix MDM with it set as non-removable in 10.13. No commands (neither profiles nor jamf ones) work because the non-removable MDM blocks any changes. You can't change the MDM enabled user or fix it after using Migration Assistant. You basically can't do anything, and I've done a ton of experimentation with no results for any way to migrate a user or properly re-enroll the existing and already active MDM enabled user.

If you're thinking about turning it on, my advice from struggling with this pretty much since HS came out is to not, and leave it off!

The biggest pro is that you can't remove the MDM profile.
The biggest con is that if you need to troubleshoot MDM problems then you can't remove and re-enroll into MDM easily. Even if you disable SIP, delete /var/db/ConfiguratIionProfiles and re-enable SIP and re-enroll. At least that's what others have reported on Slack. And trust me, you will run into MDM issues that require you to troubleshoot.

The other problem of course is that an unremovable MDM profile does not necessarily mean that the user cannot remove the jamf agent on the computer. You could indeed have an MDM profile and no jamf agent.

You might also run into a situation where a computer enrolls into MDM but never gets the jamf agent. If you MDM profile is unremovable, well good luck troubleshooting that.

If you need to troubleshoot MDM capable users, the unremovable MDM profile might also bite you as well.

Great feedback!

It seems that so long as the Mac is able to receive the "Remove MDM Profile" remote command then you can properly uninstall and reinstall Jamf. Digging deeper, I have discovered a potential fix that seems to work when the Jamf agent is removed. This should also work if the Mac is somehow unable to receive the "Remove MDM Profile" command.

In this scenario the jamf agent is removed but the MDM Profile and all other config profiles remain installed and unremovable. In that state, if the Mac then goes through a user initiated enrollment on Jamf Pro 10.2 or greater then the downloaded MDM Profile successfully replaces the locked profile and completes enrollment. This new MDM Profile is removable, so it's up to you whether you want to keep the Mac in this state OR opt to remove the Jamf framework and re-enroll via DEP (sudo profiles -N)

Has anyone tried this fix in production?

The problem is that usually when you're having to re-enroll a machine, it's because it's having difficulties with MDM in the first place. I've never had a case where I've needed to fix the MDM enabled user or re-enroll a device where it was actually capable of receiving the 'Remove MDM Profile' command, even after a reboot, even after a recon. Maybe that's just the particular set of issues I've had related to MDM, but none of my tests with that command have ever yielded results, just infinitely pending MDM commands.

@rviniar please share your blog post when it's ready :)

I should have clarified, in the scenario I described when the Jamf agent framework is removed from the Mac, the 'Remove MDM Profile' and other remote commands no longer work. This is expected behavior.

However, performing a user initiated enrollment on top of the original broken & locked MDM Profile does successfully remove and replace it with a functional profile. Seems like a decent fix to me, given we then have the ability to remove the Jamf framework + MDM Profile and start DEP enrollment again. Curious if anyone's tried this specifically.