Why MDM is fundamental to support Apple at SAP

Rich Trouton of SAP talks at JNUC 2019 about how MDM is no longer a 'nice-to-have.' It's a necessity.

November 13 2019 by

Haddayr Copley-Woods

Rich Trouton of SAP discusses MDM at a JNUC 2019 podium.

When it comes to supporting Mac systems, it's safe to say that Rich Trouton of SAP knows what he's talking about: his 20 years of Mac system support experience runs the gamut from educational and research institutions to advertising and enterprise software development.

And he's come to believe one thing for sure: MDM is no longer a "nice to have." It's a necessity.

First, he defined what MDM is: Mobile Device Management is a delivery mechanism for distributing data and settings to Apple devices. This includes Macs, iPhones, iPads and Apple TVs.

More specifically, MDM is an API for sending device management commands. Not all of these commands are backwards-compatible, so MDM commands for a specific OS version and later won’t necessarily work on earlier OS versions.

Apple admins can use MDM to push email, security settings, applications, app settings, certificates and even media content to Apple devices. MDM also allows them to apply certain management workflows and settings which are impossible using other means.

There are two major components to MDM: Apple’s Push Notification Service and the MDM server used to manage those devices.

A look at APNS:

When you take a device out of the box, it knows the address of the initialization server it’s supposed to talk to, and that it’s supposed to download a bag file. (See http://init-p01st.push.apple.com/bag for more information.) The bag file is a plist which contains the necessary data for the Apple device to start talking to APNS.

  1. Now that the Apple device knows how and where to start talking to APNS, it opens a connection and says hello.
  2. APNS says hello back and provides a certificate.
  3. The device checks the certificate and verifies that it’s valid, telling the device that APNS can be trusted to communicate with.
  4. The device has an Apple-issued device certificate, so once the device has verified that the certificate provided by APNS is valid, it sends that device certificate up to APNS.
  5. APNS checks the certificate it’s been sent by the device and verifies that it’s valid, telling APNS that the device can be trusted to communicate with.

Once both sides know that the opposite end can be trusted to communicate with, they exchange cryptographic ciphers and begin a secure conversation.

APNS will be used by Apple devices regardless of whether they’re enrolled in a mobile device management service or not. For the various apps on your Apple device that use push notifications, APNS is how those notifications get sent to your device.

APNS also requires having certain ports opened outbound.

The APNs servers use load balancing, so your devices don’t always connect to the same public IP address for notifications. It’s best to let your device access these ports on the entire 17.0.0/8 address block, which is assigned to Apple.

This is the part, says Trouton, "where your Infosec and firewall folks may start shaking their heads and saying things like 'No, no,' and 'Can’t do it.'"

For those having that argument with their security or network folks, says Trouton, here are some important facts to know:

  • APNS never needs an inbound network connection on your network.
  • Only outbound connections from your network to Apple’s network ( / 8) are needed for APNS.
  • APNS never makes unsolicited connections.
  • APNS uses TLS 1.2
  • APNS authenticates all transactions with device tokens and payload tokens, as well as validating all SSL certificates.

"Once the argument is over and they’ve agreed to open up the needed ports," says Trouton, "you may find that they didn’t actually open up all the necessary ports. To check this, Two Canoes makes a great diagnostic tool." (https://twocanoes.com/products/mac/push-diagnostics/)

For more information about APNS and how it works, Tourton suggests that admins check out Brad Chapman’s talk on the subject given at the Jamf Nation User Conference in 2017.

In essence, an MDM service is an HTTP server that responds to communication with either a plist containing a command, or an OK response. Most traffic between a device and the MDM server it’s enrolled with are going to be plists being sent back and forth.

An MDM server also needs certificates. There are two types of certificates specifically used by MDM servers, the APNS Vendor certificate and the APNS Push certificate:

  • The first is the APNS vendor certificate. This is a special certificate which is used to generate the certificate signing request for an APNS push certificate, prior to uploading the request to Apple for an APNS certificate.
  • That brings us to the APNS push certificate. This is a special certificate used by MDM servers to communicate with APNS.

Where possible, you should try to have one Apple ID per APNS certificate and make sure you have them documented. If you use a personal Apple ID or one tied to your specific work email address, you may accidentally create two active APNS certificates, which can wreak havoc.

How an MDM server talks to APNS:

  1. Like an Apple device, it opens a connection and says hello.
  2. APNS says hello back and responds with a certificate.
  3. The MDM server checks the certificate and verifies that it’s valid, telling the server that APNS can be trusted to communicate with.
  4. The MDM server now sends the APNS push certificate that it was issued by the Apple push certificate portal.
  5. APNS checks the push notification certificate it’s been sent and verifies that it’s valid, telling APNS that the MDM can be trusted to communicate with.

Once both sides know that the opposite end can be trusted, they exchange cryptographic ciphers and begin a secure conversation.

However, the push certificate and the topic are not the end of the chain of certificates. The last link for devices is what’s known as the device token. This token is generated by APNS and is unique to the device. These tokens are the same kind of tokens that APNS assigns to applications which use push notifications.

The device gets the token from APNS and knows to forward it to the MDM server during MDM enrollment:

  1. The device connects to the MDM server and sends in an enrollment request.
  2. The MDM configuration downloads to the device.
  3. The device is now managed by the MDM server and is able to communicate securely.
  4. Now that the MDM profile is in place on the device, the device registers itself with APNS using the topic
  5. APNS then generates a token, based on the combination of the device ID and the MDM topic.
  6. Once APNS has generated the token, it’s sent down to the device.
  7. Once the token is sent to the device by APNS, the device then forwards it to the MDM server. Once the MDM server has it, the token is associated with the MDM’s record for that device.

The device token may change occasionally. When a change is detected, the device automatically checks in with the MDM server to report the new token.

So now everything involved has the right cryptographic trust relationships in place to communicate securely with each other.

One thing that’s important to understand is that no management data goes over APNS. APNS is only used as a trigger mechanism to make the device ask its MDM for commands to run. This genericism is what allows APNS to be used by everybody who needs to send push notifications, because APNS is only ever telling the device to check in with whatever originally generated the notification.

APNS is also pretty secure because of its verification scheme. By the time an APNS notification reaches its target device, it relies on the push notification certificate being valid, the topic being valid, the token being valid and the push magic string being valid. If any of those are not valid, the notification is automatically discarded by the system.

So now we know how MDM works, but why do we need it?

In OS X El Capitan, kernel extensions must be digitally signed using an Apple Developer ID for Signing Kexts certificate and installed into /Library/Extensions. System Integrity Protection, introduced as part of OS X El Capitan, now enforces code signing and explicitly disables the kernel extension developer mode previously available in OS X Yosemite.

In macOS Sierra, kernel extensions must be digitally signed using an Apple Developer ID for Signing Kexts certificate and installed into /Library/Extensions. System Integrity Protection remains the enforcement mechanism.

So: you can use MDM to push email, security settings, applications, app settings, certificates and even media content to Apple devices. But can’t you do this in other ways?

Up until macOS Sierra, maybe you could. With the introduction of macOS High Sierra, things changed.

You could modify the list of kernel extensions using the spctl command, but only while booted from the recovery environment for the specific Mac you want to manage.

This is easy for an individual to do, but how do you manage this for more than a handful of machines?

Through MDM enrollment. For High Sierra 10.13.0 through 10.13.3, if a particular Mac was enrolled into an MDM solution, kernel extensions management went back to the macOS Sierra model. In this enforcement model, user approval was no longer needed for third party kernel extensions.

This marked the first time that some large enterprise environments really needed an MDM solution for Mac management. Why? Many security tools use kernel extensions and those kernel extensions need to load in order for the security tool to run correctly. Starting with 10.13.4, Apple began enforcing what is known as user-approved MDM.

Having an automated enrollment into MDM did not grant all MDM management rights. Instead, a human being now needed to go and click a button in the profiles preference pane.

Apple also went to some trouble to make sure that this button could not be clicked using automated means. Among other items, they disabled the ability to click the approval buttons via remote screen sharing. Once approved, all MDM management rights are now available. This is important because Apple began requiring UAMDM be enabled before certain management rights were available. The first was management of third-party kernel extensions in 10.13.4. A new kernel extension whitelist profile became available, but it only worked on Macs where UAMDM was enabled.

This new profile allowed Apple admins to whitelist kernel extensions by vendor or by individual kext. Without this whitelisting, the logged-in user will be asked to approve the loading of third-party kernel extensions even if the Mac is enrolled into MDM. Meanwhile, starting on macOS Mojave, Apple introduced new privacy protections for data stored in the user’s home folder and elsewhere. When an outside tool or process tries to access protected data, users receive error messages.

Alongside these new protections, Apple introduced another management right which is only available to Macs with UAMDM enabled. This was the ability to whitelist the ability of specified tools and processes to access areas otherwise put off limits by Mojave’s new user protections. Without this whitelisting, the logged-in user will be asked to approve or deny actions by those tools or processes.

It seems likely that Apple will be putting more and more management behind UAMDM, which makes it all the more important that managed Macs be enrolled with an MDM and stay that way.

Another Apple program which leverages MDM is the volume purchase program for distributing software from the App Store. VPP’s latest way of assigning App Store licenses to devices relies on an MDM server to both manage the device and also assign the license. Assigning licenses directly to devices means avoiding the need to have an Apple ID involved in the license assignment. Instead, the MDM server can assign a license to the computer record it has and the app can install silently on the Mac in question.

Bringing up the tail of MDM’s capabilities is one that MDM has had since its introduction: the ability to lock and wipe devices. These are likely MDM’s least thought-of functions, until a VIP leaves their Mac or iOS device in the back of a taxi somewhere. However, they can be a lifesaver in such situations as they allow a device to be either remotely locked or completely wiped to prevent access to the data stored on it.

What can't MDM do?

MDM can't do absolutely everything you need to manage your devices. Profiles have limitations. Apple Admins fill the gap with scripts. Generally, scripting can do everything with management that profiles cannot.

So how do you choose when to use a profile or when to use a script?

Trouton's advice, which is based on Apple's signaling that profiles are the way forward, is to see if you can use a profile first. Check to see if a profile exists for what you want to do, yes. You also need to ensure that the tool Apple uses can work with the profile. If not, use a script. Do you always want to manage it? Use a profile. Do you want to manage it only once? Script it. But don't just assume that a profile will never work for your purposes; recheck every so often to see if the situation has changed.


An attendee asked for more information on the permissions app SAP has created, and Trouton provided the link: github.com/sap/macOS-enterprise-privileges

One fan thanked him for his "ridiculously fabulous website" and how useful it is. The entire audience burst into applause.

A final questioner asked about good sources for finding payloads for building out config profiles. Trouton recommended ProfileCreator on GitHub for templates to pull from that will help in building config profiles, as well as Apple's profile-specific payload key templates. And, of course, Trouton has offered his own genericized open-source profile templates on GitHub.

A .pdf of the deck for this entire, more detailed and granula presentation can be found here: https://tinyurl.com/JNUC2019PDF

They keynote is here: https://tinyurl.com/JNUC2019Keynote

Trouton also has a book coming out on January 6, 2020, cowritten with Jamf's own Charles Edge: Apple Device Management: A Unified Theory of Managing Macs, iPads, iPhones, and AppleTVs

Useful links

Apple Mobile Device Management: https://developer.apple.com/documentation/devicemanagement

A Push Odyssey - Journey to the Center of APNS: https://www.youtube.com/watch?v=Z-Lg9uBbmfk

Getting MicroMDM working and working with MicroMDM: https://youtube.com/watch?v=WGKT-PyHz6I

Demystifying MDM: open source endeavours to manage Macs: https://youtube.com/watch?v=6DBGIDcBKFw

Subscribe to the Jamf Blog

Have market trends, Apple updates and Jamf news delivered directly to your inbox.

To learn more about how we collect, use, disclose, transfer, and store your information, please visit our Privacy Policy.