Some mobile device management solutions for Apple iOS require the use of an agent application, and some don’t. Why is that, and what does an agent app add to MDM? This article will answer those questions.
Core MDM functionality
First, a little background: All of the MDM APIs in iOS (which were first introduced with iOS 4 in 2010) are controlled by an XML file the comprises the MDM configuration profile. The profile contains settings for various aspects of the device, and credentials that allow a server to query the device for those settings and perform other management tasks, such as changing the password and wiping the device.
Because the settings and capabilities provided by iOS configuration profiles are set and well-defined, the capabilities provided by an MDM solution will also be exactly the same, at least when it comes to available queries and actions on the device. The capabilities are the same for you, too, if you use the iPhone configuration utility. It’s is a great way to mess around and find out what a profile can actually do. (For Windows | Mac) (Android, on the other hand, is a completely different case. All Android MDM solutions consist of an app that takes lots of permissions including special device administrator permissions; capabilities vary widely based on the MDM vendor, Android version, and device manufacturer.)
What will vary is how exactly an MDM solution will allow you to use the available queries and actions to create policies. Some solutions can be used to create any sort of policy imaginable by linking together any of the available device queries with any of the available device management actions, while other solutions will have pre-made policies.
Using policy, it’s possible to go beyond the limited management actions that are available in iOS MDM. For example, there’s no setting in a configuration profile for blacklisting select Public app store apps (unless you turn off the App Store all together), but it is possible to get the same effect through policy. Using the MDM APIs, you can query a device for all installed apps. If one that you want to blacklist shows up, you can threaten to wipe the device, or something a little less drastic like remove email access or simply notify IT that the device is out of compliance.
Adding an agent app
Now that we know how MDM policy works, where does an an agent application come in? An app can ask for permission to access APIs that are not exposed to configuration profiles. Quite simply, these extra queries and actions give MDM servers more variables to use when creating policies. To see all the examples of what’s possible, you can register at developer.apple.com and look at the full lists of all the APIs available in iOS. (And that’s a lot of them!) (Also, don’t forget that any other random bit of information or action, external to the device, could be used to create policy, as well.)
What do MDM solutions do with all these extra APIs? Location-based policy is one logical example that comes up, and using extra-device input, Active Directory or other identity systems can be linked to the administrative end of some MDM solutions.
The reality for most MDM solutions, though, is that agent applications don’t really get used for policy—instead they’re used for other tasks. Tracking the location of lost devices (or just any devices if you’re in a big brother mood), testing for jailbroken devices, and installing MDM profiles themselves are the most common uses. Agent apps can serve a wide variety of other functions, including acting as an enterprise app store, a document management or file syncing app, an email client, or as a browser.
And there you have it: the possibilities are theoretically endless, but the practical implementations of agent apps that we see today are less about being able to build deeper policy and more for other tasks.