Hostile takeover :-) Possible to purge Non removable MDM profile ?

[michaelhusar]

We got a couple of OS X 10.11 machines, that where enrolled in a different MDM (we cannot access anymore)
Since there is a lot of data on the drives we do not want to wipe the machines
Is there a trick to get rid of the old MDM profile ?

"Normal" profile removal via bash fails with error "Profile is not removable"

bash-3.2# profiles -R -p com.uni.mdm
profiles uninstall for identifier:'com.uni.mdm' and user:'root' returned 101 (Profile is not removable.)

[jjones]

If you have root access to the machines, sudo jamf removeMDMProfile will remove the Jamf MDM Profile in turn remove all other profiles associated with that MDM.

[michaelhusar]

I tried that, but the "other" MDM is not a Jamf MDM :-( so this command does not work

[RobertHammen · Accepted solution]

Profiles live in a database in /var/db/ConfigurationProfiles... wonder what would happen if you nuked that directory, then rebooted the Mac. May also need to remove /Library/Managed Preferences, too... Try this on a VM or expendable Mac before you do on a "real" system.

[frozzierox]

I came across a similar problem with centrify, where some profile were actually not installed properly so it made removing them pretty difficult. I ended up using a simple command line to remove the individual profiles, after finding that "/usr/bin/profiles -D -f" was not removing all of them.

I located their individual names, called the command to remove them and then purge everything else:

/usr/bin/profiles -R -p com.centrify.osx.MDM
/usr/bin/profiles -R -p com.centrify.centrifydc.ssl
/usr/bin/profiles -D -f

[kilodelta]

If the profile was installed using DEP, and marked as non-removable, then no. Much like a supervised iOS device, the only "official" way to remove it is to wipe the OS or for the old MDM system to send an unmanage command.

Your best bet is to backup the data using Target Disk Mode, rsync, or some other method.

You might be able to yank out the DEP status by re-running the Setup Assistant (delete /var/db/.AppleSetupDone and reboot), but since the profile is already installed...probably not.

[blackholemac]

You could do a full drive clone of the Mac to a different machine...doing that should in theory break the certs used by the other MDM.

May introduce some weirdness so testing is always in order. May not work too...you could try calling support for the old MDM provider, give proof of the "hostile" takeover and ask how to remove their product.

[michaelhusar]

Thanks a lot everyone for your great help!
@RobertHammen Nuking /var/db/ConfigurationProfiles did the trick; I went for also deleting /Library/Managed Preferences too.
After restart - the "Sharing"-Preferences said "There is an error" - but a second restart healed that.
Now I am testing for "other" side-effects. But so far everything good - machine is successfully in JSS after a QuickAdd.pkg.
Only thing that I see: Under Management: There is no button for "Download Updates" and no "Download and Install Updates" - but this has maybe other reasons.

@frozzierox I tried that, but was stuck with the error complaining about "not removable"

@kilodelta I changed the Enrollmentprofile settings to "User can remove MDM profile" and did a re-selfenrollment and did a second attempt starting over and trigger a re-DEP of the machine. But the MDM profile could not be exchanged or replaced - so the status "not removable" stuck.

@blackholemac I opened a ticket with the "other" provider and tried to call. All in vain - phone response was, that their tool is not able to revoke their MDM profile.

Again, a big thank you to everyone!

[esummers]

You can nuke /var/db/ConfigurationProfiles. You probably also need to delete /Library/Keychains/apsd.keychain. Reboot. A notification to re-enroll using DEP should appear in notification center shortly after the user logs in. You could also remove /var/db/.AppleSetupDone if you want to do re-enrollment in setup assistant instead.

[chlaird]

I'm fairly sure this has been "fixed" by Apple in 10.13.4. Nuking /var/db/ConfigurationProfiles used to be my go-to and now on 10.13.4 it just kicks back "Operation not permitted" no matter what I do.

[blairb]

Yeah, this is kind of unbelievable. Now every time something gets screwed up I have to wipe and re-image the computer?

[stevewood]

@blairb You shouldn't need to wipe and re-image a machine. SIP is what is blocking the deletion of that folder. Booting to the Recovery partition, opening Terminal in Recovery, and navigating to that folder structure (make sure you're going to /Volumes/Macintosh HD/var/db) should allow you to remove the ConfigurationProfiles folder structure.

[blairb]

I can definitely do that... but some of my techs having to do that is worrisome to me. Infinitely easier when that directory wasn't SIP protected.

[talkingmoose]

When your MDM profile doesn't allow removal, you can go into your Jamf Pro server, locate the computer record, click the Management tab and click the Remove MDM Profile button there.

This only removes the MDM profile. It doesn't remove Jamf Pro management.

You can restore the MDM profile by running sudo jamf mdm in Terminal on the Mac, but on updated High Sierra Macs, you or the user will need to Approve the MDM profile. This also means any admin user on the Mac can remove it now. Standard users can't remove the MDM profile whether installed via DEP or this method.

[carrie]

with Mojave it is no longer /Volumes/Macintosh HD/var/db -- it is /Volumes/OS X Base System/var/db ... and it still doesn't have ConfigurationProfiles - that folder is totally wiped from all posted locations I have found with google searching so far

[tcam]

@carrie /Volumes/OS X Base System/var/db is the recovery partition your booted off of

You may want to open disk utility, make sure the built-in storage is mounted AND see what the built-in storage is named.
If it's protected by filevault 2, when you try to mount the built-in storage, you will be prompted for the filevault 2 password or recovery key.

For instance if the built-in storage was named mapple
cd /Volumes
ls -al

returns:
OS X Base System
mapple

cd mapple/var/db

Which means the whole path would be /Volumes/mapple/var/db/

[bradtchapman]

Adding to that... if you only see “OS X Base System” in Terminal, the internal disk is not mounted. The most common reason for this is FileVault. You’ll need to quit Terminal, open Disk Utility, and mount the volume with a known local password.

[BYRTO]

hi, i bought a second hand mbp2017, i recently updated to catilina and suddenly every now and then i get a notification in the top right screen which says " the systemadmin can help to setup my system " . . . when i check under profiles there is non . . . i can skip this and nothing happens . . . when i choose details the profile options show up but with no further infos . . .

the guy i was buying this from is now not answering any questions...what should i do now ?

[sdagley]

@BYRTO If you install the profile it will enroll your Mac with the MDM for the company that originally purchased that Mac from Apple. If it's a Jamf Pro system that would install the Self Service app which would hopefully have some mechanism to contact that org's IT department, and you could contact them to see if you bought a stolen machine.

[networkadmin]

We were in a similar predicament, of our own doing -- we'd enrolled a lab of Mojave Macs using non-removable profiles, then wanted to change MDMs without erasing all the Macs. With some trial and error, and a little help from this: http://rachelviniar.com/non-removable-mdm/ and from the MacEnterprise list, we were able to use recovery mode to bypass SIP and nuke the old profiles surgically. Details here: http://whoopis.com/core/mac-related/removing-a-non-removable.html In case it helps anyone else.

[Brochardt]

@talkingmoose : Please tell me how to go to "your Jamf Pro Server
"...you are killing me,,,

[ifbell]

I had to deal with this issue in the past couple of days do to our conversion from one MDM to Jamf. I found this URL which is mentioned above a good starting point. The process worked without issue for our Catalina machines. A couple of notes from my process I wrote out for my clients so we could walk through this together via a video call.
1: After the Command-R they had to Authenticate 2: They needed to go to the Disk Utility and mount the main drive
3: Once in the terminal they needed to do a cd / first then they could do the cd /Volumes command and get the correct path.
4: After this cd var/db/ConfigurationProfiles and the pwd I have them do an ls to double check they are where they think they are.
5: I have the user do a cd /Settings and an ls to confirm that everything is as it is supposed to be after the touch command.
6: then a reboot command

After all of the above I found that the profiles were gone and I could enroll the machines into Jamf without issue.

Hope this helps someone.

[bradtchapman]

@ifbell , I think you forgot a step. #5 only indicates that you've listed the contents of the Settings folder. Did you also instruct them to rm the files in that folder?

[maser]

Has anybody figured out the exact set of steps to do the same thing on a Big Sur system? We have 2 systems (out of about 2000+ Big Sur upgrades) where the MDM Profile got messed up some how and were looking into ways to see if it could be resolved without a full wipe-and-reload.

[NightFlight]

Has anybody figured out the exact set of steps to do the same thing on a Big Sur system? We have 2 systems (out of about 2000+ Big Sur upgrades) where the MDM Profile got messed up some how and were looking into ways to see if it could be resolved without a full wipe-and-reload.

+me too -- but add a zero to the fleet count. Honestly an erase and install might be easier as DEP will just kick in for the majority and point to the new instance. Calling up users and walking them through a disk mount and terminal will kill our helpdesk.

[NightFlight]

Boot to recovery

Disable SIP

/bin/rm -rf /var/db/ConfigurationProfiles/Store/*

/usr/bin/csrutil clear

reboot

[NightFlight]

This may work on the latest Big Sur >= 11.4   

profiles renew -type enrollment 

... what a BS name. 🙂

[bmcfarlane]

This worked for me on 11.4! Thanks!