Remove MDM profile from iOS device – without App, iOS/iPadOS 18+

I bought a used iPad at ebay – a device in good condition for little money, delivered super fast, condition as described. Unfortunately, I was confronted with a previously unknown message when setting it up: The device is “remotely managed”, apparently by the previous owner’s school. I wrote to him directly and he promised to contact the school admin.
As of “now”, nothing has happened in this regard and instead of waiting, I was curious whether the problem could be solved myself…

TL;DR

I managed to remove the profile, but the iPad is still not 100% “free”. After a reset, the profile is there again. At least you can get rid of the restrictions of the MDM profile for the time being.
And yes – there is software on the net that promises exactly that – but it costs money and doesn’t seem particularly trustworthy – who knows what else it might do to the device. My solution requires a little patience and IT know-how (Linux!) but no third-party software. You may also need a cloud server – but only for a short time, the costs are in the cent range.

Research

First of all, I had to get an overview of what remote management actually is and how it works. Roughly summarized, remote management is often used by schools and companies to be able to control the devices centrally. Management is then combined with a so-called “Mobile Device Management” (MDM) profile. This profile is installed on the device after the initial setup and ensures that the administrator is granted certain rights to the device remotely.

The registration of the device as a “supervised” or “remotely managed” device is part of Apple’s responsibility (Apple School Manager) and the MDM profile can be delivered by a third-party provider (in this case jamfcloud.com was used).

Since the MDM stuff can be provided by third parties, there is also a documentation of the protocol from Apple; here I found an interesting piece of information: “If the server no longer manages a device, it should simply respond to all requests with your 401 HTTP code. In this case, the MDM profile would be automatically removed”. I thought to myself, I could start here 🙂

Tools

Configurable DNS server

We need to intercept the HTTP request from the MDM “check-in” and redirect it to our own server. This is done via DNS – the iPad requests the known check-in URL and ends up – without realizing it – on our server. I use nextdns.io for this – I have also stored this as the central DNS on the FritzBox so that all traffic from the house network runs through it. It’s very easy to set up and the service is free up to a certain number of requests.

Server

We need a web server that accepts the check-in request and responds with a 401 HTTP code. Depending on the network configuration, this could also be a Linux server running in the local network (it only needs to be accessible from the iPad). I quickly clicked together a cloud server with Ubuntu from my trusted cloud provider and started it. The server only needs to run for a few hours at most and can then be deleted again.

Work steps

First of all, the iPad must be set up so that we have the home screen in front of us. The device must therefore first be registered with the remote administration and the MDM profile installed.
There should also be a way to send files to the iPad (e.g. Airdrop, or a service such as https://www.swisstransfer.com).

Create your own CA and SSL certificate

Of course, the original check-in server responds via HTTPS, so we also need an SSL certificate. It must be a self-signed one, because real certification authorities such as Let’s Encrypt naturally do not issue one for a domain that does not belong to us.
However, a self-signed certificate has the disadvantage that the iPad will not trust it. So we also need our own “Certificate Authority” (CA) which we install on the iPad so that it trusts our certificate after all.

I got the individual commands from arminreiter.com and www.brainbytez.nl here is the quick sequence:

Create CA:
In the first block, the CA is created which is subsequently installed on the iPad and with which the certificate is signed. It is important to enter a password of your choice when creating the private key.

# define a name for the CA
CANAME=MyOrg-RootCA

# optional
mkdir $CANAME
cd $CANAME
# generate aes encrypted private key
openssl genrsa -aes256 -out $CANAME.key 4096

# create certificate, 1826 days = 5 years
openssl req -x509 -new -nodes -key $CANAME.key -sha256 -days 1826 -out $CANAME.crt -subj '/CN=MyOrg Root CA/C=US/ST=Denver/O=MyOrg'

Create server certificate:
We create a “wildcard” certificate so that it is valid for all subdomains of the MDM administrator’s domain. The only important thing here is that you enter the correct domain for you in MYDOMAIN. You can find this in the MDM profile on the iPad under “Settings -> General -> VPN and device management -> (name of the profile) -> Enrollment”. The URL is under there – we only need the domain name.

# define variables
MYCERT=webserver
MYDOMAIN=*.jamfcloud.com
# create the certificate signing request
openssl req -new -nodes -out $MYCERT.csr -newkey rsa:4096 -keyout $MYCERT.key -subj "/CN=$MYDOMAIN/C=US/ST=Denver/O=MyOrg"
# create a v3 ext file for SAN properties
cat > $MYCERT.v3.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage=serverAuth
subjectAltName = DNS:$MYDOMAIN
EOF
# sign the certificate with the CA
openssl x509 -req -in $MYCERT.csr -CA $CANAME.crt -CAkey $CANAME.key -CAcreateserial -out $MYCERT.crt -days 730 -sha256 -extfile $MYCERT.v3.ext
# concatenate certificate and ca
cat $MYCERT.crt $CANAME.crt > $MYCERT.pem

You should now have various files in the folder. Among others a file “MyOrg-RootCA.crt” and a file “webserver.pem”

Install CA on the iPad

In order for the iPad to trust our self-signed certificate, we need to install our own CA on the iPad. To do this, the CA file (“MyOrg-RootCA.crt”) from the previous step must now be transferred to the iPad. The most convenient way to do this in a Mac world is via AirDrop.
After transferring the file, the profile is usually installed directly (or you have to open the file again via the “Files” app).
You then go to the settings, where you will now see something about a profile that has just been installed prominently on the left-hand side. Tap on it and always tap on“Install“, which is written in trustworthy red.
Now you have to trust the certificate as SSL Root CA. To do this, go to “Settings -> General -> Info -> (scroll all the way down) -> Certificate trust settings” and activate your root CA there.

Install server

First, we install an Nginx web server (or any other) on our server. On Debian/Ubuntu this can be done with apt-get update && apt install nginx

We can now simply edit the Nginx standard installation under /etc/nginx/sites-enabled/default. In my case it looks like this:

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        listen 443 ssl default_server;
        listen [::]:443 ssl default_server;

        include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                # just always return a 401
                return 401;
        }
}

As you can see, I have also activated SSL on port 443. In addition, the server simply responds to everything with a 401 HTTP code.

Now you have to copy the SSL certificate created in the previous step to the server. Namely the files “webserver.pem” and “webserver.key”.

We now need to edit the file /etc/nginx/snippets/snakeoil.conf and add our SSL certificate and key there. This could look like this, for example, if the files were copied to /root/cert/:

ssl_certificate /root/cert/webserver.pem;
ssl_certificate_key /root/cert/webserver.key;

With the command nginx -t we now test whether everything is correct, if everything is OK there we load the new web server configuration with systemctl reload nginx

Redirect DNS

Now we redirect all requests to the check-in domain (e.g. jamfcloud.com) to the public IP of our server. With NextDNS this can be done via “Settings -> Rewrites”

Test

If you now call up the (https!!!) check-in URL with the web browser on the iPad, an NginX standard error page should appear there and no certificate errors – but a trustworthy closed padlock next to the URL.

Observe

You can now watch the NginX access log live to see when your iPad calls the check-in URL tail -f /var/log/nginx/access.log
In my case, the URL (which can only be reached from my network via the IP) was called surprisingly often by various bots that check for open security holes. But the MDM request can be easily recognized by the “MDM” string.

Waiting

In my case, I waited a few hours – at some point, the long-awaited check-in request arrived. After taking a look at the iPad under “Settings -> General -> VPN and device management”, the profile was gone 🙂
However, there also seems to be a quicker way to provoke the MDM check-in request by briefly switching to flight mode and back again.

Conclusion

A rather complicated method, but at least you don’t have to install any strange software. You couldn’t sell the iPad this way either, and the steps have to be repeated after every factory reset.
So the solution is more of a stopgap. In my case, I hope that the school admin will soon release the iPad properly. Otherwise, the iPad is still “remotely managed” but the administrator no longer has any authorizations.