I have many iOS devices in my company and I have to manage them centrally, so we tried to use third party MDM applications for eg: airwatch but it is very costly.
We decided not to use it and are thinking of creating a MDM from scratch. We tried all solutions available online but I didn't get any solution. Can anyone please help me with this.
iOS MDM is clientless protocol. So, you develop a server, but you don't develop a client application for it. Actually, there is a client app, but it's developed by Apple and built into operation system.
So, your server will send a command, built-in MDM client will receive and execute it.
Generally speaking, if you want to develop MDM server, you need to register into Enterprise Developer Program and get MDM documentation.
A documentation here it'll help you create your own mdm solution from scratch I believe
Some other helpful links on developing mdm server Ref 1, Ref 2
Here is the link to MDM tag in stack overflow browsing this will help you get answer for most of the FAQ
If you want any clarification in getting this done comment below here. I'm ready to help you
Overview
In order to manage device we can configure it manually using iOS Settings app
But it has scalability problem and its a lot of work configuring every device manually and it requires physical access
so apple introduced iPCU(iPhone Configuration Utility) tool using which we can create configuration profiles(.moibleconfig) and we can install it Over USB or OTA(Over the Air)
But it requires User interaction
so apple introduced MDM services for iOS it does not require user interaction we can do so many things very easily without user consent such as remote lock, unlock,wipe,configuring mail etc...
MDM is basically a protocol using which you can manage devices remotely.
Overview
Changes we make in iOS settings app are stored in /var/mobile/Library/ConfigurationProfiles as .plist files along with the profiles(.plist) installed by iPCU and MDM
Lets say we are turning off the App Store app installation in the device so to do that we'll go Settings->Restrictions and turn off the App Store installation so allowAppInstallation would be turned to false in its configuration(.plist) lets say we are configuring the app installation using iPCU as well as MDM then iOS we'll take most restrictive one when conflict comes between the configuration profiles of iOS settings app profile,iPCU profile and MDM profile.
iOS creates a profile called ProfileTruth.plist by merging all this profiles and iOS works with respect to this plist
MDM basically consists of these things
iOS Device
It can be any device that runs using iOS.All iOS device has a inbuilt MDM client.It will act upon the instruction fed by MDM server
MDM Server
Its basically a application that is hosted on application or web server and it feeds the command to MDM client that is hosted on iOS Device
Signalling
This a mechanism that invokes the mdm client from Server in our case it is APNS
Herewith I have attached MDM workflow
MDM Enrolment
It starts with MDM enrolment profile
In iPCU you can create a new profile choosing MDM payload
Check In URL
The is the URL where enrolment of the device happens.
i.e upon installation of profile on the device MDM client sends necessary information to the MDM server which MDM server will use to authenticate and connect with the device
Server URL
Once the MDM server got the enrolment information.It can use the information to connect the device using APNS and when MDM client wakes up it connects with the URL mentioned in Server URL and Server can send back the queued commands to MDM client
Topic
Enter the subject of APNS certificate that's going to be used for MDM.
Identity
It can be any certificate generated by Certificate Assistant but important thing is it has to be signed by globally trusted CA or in the case of self signed CA the CA has be installed in the device.
Install the MDM Enrolment Profile
You can install this profile using Over the Air or Over the USB
As soon as it installs, iOS Built-in client will connect to MDM server(Check In URL) with Authenticate request
PUT: /checkin
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>MessageType</key>
<string>Authenticate</string>
<key>Topic</key>
<string>com.example.mdm.pushcert</string>
<key>UDID</key>
<string> [ redacted ] </string>
</dict>
</plist>
Now server can either accept or reject the Authenticate request.In order to accept the server has to respond with blank plist
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
</dict>
</plist>
Upon receiving the response MDM client will send TokenUpdate request
PUT: /checkin
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>MessageType</key>
<string>TokenUpdate</string>
<key>PushMagic</key>
<string> [ redacted uuid string ] </string>
<key>Token</key>
<data> [ 32 byte string, base64 encoded, redacted ] </data>
</data>
<key>Topic</key>
<string>com.example.mdm.pushcert</string>
<key>UDID</key>
<string> [ redacted ] </string>
<key>UnlockToken</key>
<data>
[ long binary string encoded in base64, redacted ]
</data>
</dict>
</plist>
Again server needs to send a plain plist to complete the enrolment process
MDM server has to store the following keys in server
PushMagic
Server has to attach this to all the Push notification it sends to connect MDM client
Token
A unique id that identifies the device to APNS
UnlockToken
A key used to clear the passcode of the device.
Managing the Device
Now the server has to send push notification by passing above Token to Token for Push notification library and Payload of Pushmagic as value for the key MDM
{"mdm":"996ac527-9993-4a0a-8528-60b2b3c2f52b"}
See aps is not present in this payload
Once the device receives the push notification the MDM client contacts the Server URL instead of Check In URL with status idle
PUT: /server
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Status</key>
<string>Idle</string>
<key>UDID</key>
<string> [ redacted ] </string>
</dict>
</plist>
The server then responds with whatever command it has queued for the device.
Lets see a example for Device Lock
The server has to respond with command like this to the client request
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Command</key>
<dict>
<key>RequestType</key>
<string>DeviceLock</string>
</dict>
<key>CommandUUID</key>
<string></string>
</dict>
</plist>
When the MDM client receives this for its status idle request that was sent earlier.It'll immediately lock the device and respond the server with following standard acknowledgement
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CommandUUID</key>
<string></string>
<key>Status</key>
<string>Acknowledged</string>
<key>UDID</key>
<string> [ redacted ] </string>
</dict>
</plist>
You can find some list of Commands here
That's all.This approach would do a simple demo thing.
Note:
I will try to fine tune or add more content here for easier understanding
Please go through this link and content
About Mobile Device Management
The Mobile Device Management (MDM) protocol provides a way for system administrators to send device management commands to managed iOS devices running iOS 4 and later, OS X devices running OS X v10.7 and later, and Apple TV devices running iOS 7 (Apple TV software 6.0) and later. Through the MDM service, an IT administrator can inspect, install, or remove profiles; remove passcodes; and begin secure erase on a managed device.
The MDM protocol is built on top of HTTP, transport layer security (TLS), and push notifications. The related MDM check-in protocol provides a way to delegate the initial registration process to a separate server.
MDM uses the Apple Push Notification Service (APNS) to deliver a “wake up” message to a managed device. The device then connects to a predetermined web service to retrieve commands and return results.
To provide MDM service, your IT department needs to deploy an HTTPS server to act as an MDM server, then distribute profiles containing the MDM payload to your managed devices.
A managed device uses an identity to authenticate itself to the MDM server over TLS (SSL). This identity can be included in the profile as a Certificate payload or it can be generated by enrolling the device with SCEP.
Note: For information about about SCEP, see the draft SCEP specification located at datatracker.ietf.org/doc/draft-nourse-scep/. The MDM payload can be placed within a configuration profile (.mobileconfig) file distributed using email or a webpage, as part of the final configuration profile delivered by an over-the-air enrollment service, or automatically using the Device Enrollment Program. Only one MDM payload can be installed on a device at any given time.
Configuration profiles and provisioning profiles installed through the MDM service are called managed profiles. These profiles are automatically removed when the MDM payload is removed. Although an MDM service may have the rights to inspect the device for the complete list of configuration profiles or provisioning profiles, it may only remove apps, configuration profiles, and provisioning profiles that it originally installed. Accounts installed using managed profiles are called managed accounts.
In addition to managed profiles, you can also use MDM to install apps. Apps installed through the MDM service are called managed apps. The MDM service has additional control over how managed apps and their data are used on the device.
Devices running iOS 5 and later can be designated as supervised when they are being prepared for deployment with Apple Configurator 2. Additionally, devices running iOS 7 and later can be supervised using the Device Enrollment Program. A supervised device provides an organization with additional control over its configuration and restrictions. In this document, if any configuration option is limited to supervised devices, its description notes that limitation.
Unless the profile is installed using the Device Enrollment Program, a user may remove the profile containing the MDM payload at any time. The MDM server can always remove its own profile, regardless of its access rights. In OS X v10.8 and later and iOS 5, the MDM client makes a single attempt to contact the server with the CheckOut command when the profile is removed. In earlier OS versions, the device does not contact the MDM server when the user removes the payload. See MDM Best Practices for recommendations on how to detect devices that are no longer managed.
A profile containing an MDM payload cannot be locked unless it is installed using the Device Enrollment Program. However, managed profiles installed through MDM may be locked. All managed profiles installed through MDM are removed when the main MDM profile is removed, even if they are locked.
At a Glance
This document was written for system administrators and system integrators who design software for managing devices in enterprise environments.
The MDM Check-in Protocol Lets a Device Contact Your Server The MDM check-in protocol is used during initialization to validate a device’s eligibility for MDM enrollment and to inform the server that a device’s device token has been updated.
Related Chapter: MDM Check-in Protocol The MDM Protocol Sends Management Commands to the Device The (main) MDM protocol uses push notifications to tell the managed device to perform specific functions, such as deleting an app or performing a remote wipe.
Related Chapter: Mobile Device Management (MDM) Protocol The Way You Design Your Payload Matters For maximum effectiveness and security, install a base profile that contains little more than the most basic MDM management information, then install other profiles to the device after it is managed.
Related Chapter: MDM Best Practices The Device Enrollment Program Lets You Configure Devices with the Setup Assistant The HTTP-based Device Enrollment Program addresses the mass configuration needs of organizations purchasing and deploying devices in large quantities, without the need for factory customization or pre-configuration of devices prior to deployment.
The cloud service API provides profile management and mapping. With this API, you can create profiles, update profiles, delete profiles, obtain a list of devices, and associate those profiles with specific devices.
Related Chapter: Device Enrollment Program The Volume Purchase Program Lets You Assign App Licenses to Users and Devices The Volume Purchase Program provides a number of web services that MDM servers can call to associate volume purchases with a particular user or device.
Related Chapter: VPP App Assignment Apple Push Notification Certificates Can Be Generated Through the Apple Push Certificates Portal Before you receive a CSR from your customer, you must download an “MDM Signing Certificate” and the associated trust certificates via the iOS Provisioning Portal. Then, you must use that certificate to sign your customers’ certificates.
© 2022 - 2024 — McMap. All rights reserved.