Apple MDM: traffic flow

When managing Apple iOS devices over the air, it’s important to remember two vital facts:

  • You can’t talk to the devices
  • The devices won’t (usually) proactively talk to you

This, naturally, leads to the question: how can you manage them? Enter Apple, the great intermediator.

Apple relies on its Apple Push Notification Services (APNS) to handle two distinct types of communications: “wake up” messages, and application notifications.

The latter is highly visible to users: app badge updates and other messages that are delivered via modal dialogs or the Notification Center. A third-party or enterprise in-house app must have one or more servers configured to talk to Apple to request that such notifications be delivered.

Wake up messages, however, are effectively invisible to end users, and are vital to MDM.

Even Apple can’t find a specific iOS device in the wild, so each device, MDM-managed or not, establishes a communications channel to Apple’s servers any time they’re on a network which allows it, via TCP port 5223[*]. Once that connection is established, Apple will use it to send APNS messages.

For MDM management, then, the traffic flow looks like this:

  1. iOS device establishes a TCP connection to Apple, awaiting further instructions
  2. Time passes
  3. A corporate MDM server which manages that device sends a request to Apple for the device to check in
  4. Apple queues the request
  5. Time passes (not, typically, very long)
  6. Apple sends the wake up message to the iOS device
  7. Assuming the iOS device still has its MDM payload, it issues an HTTP over TLS request to the corporate MDM server
  8. Once contacted, the MDM server may issue information requests (“what apps are installed?”), new configuration profiles (“here’s your email configuration”) or commands to perform certain operations, such as clearing a passcode if the user has forgotten how to unlock the device
  9. Once each request has been handed to the iOS device and responses provided, the connection terminates until the next time Apple wakes the device

In my short list of vital facts at the top of this document, I used the word “usually” as a caveat. As I mentioned in my last post, there is one case where an iOS device will proactively communicate with an MDM server: if the device is running iOS 5 (or, presumably, greater), and the MDM payload has a certain flag set, the deletion of the payload by the user will result in a single check in request.

This, combined with the fact that other MDM configuration profiles tied to the payload will also be deleted, helps compensate for the fact that an MDM payload cannot be locked when installed over the air.


* If an iOS device is on a wireless network that does not allow port 5223 access to Apple’s network, it cannot receive APNS messages even if it has cellular data services. In some corporate networks, then, the surest way to make sure a corporate device cannot be managed by the corporate servers is to place it on the same network as those servers.

Advertisements
Comments are closed.
%d bloggers like this: