iPhones and iPads are flooding the workplace, threatening to dislodge IT-issued BlackBerries and netbooks. As a result, IT groups need fast-yet-effective ways to secure employee-liable devices. One solution: AirWatch Enterprise MDM for Apple iOS4, a Mobile Device Manager (MDM) that can be purchased as a cloud service.
Back in July, we tested AirWatch Enterprise v5.11, focusing on its ability to track, trouble-shoot, and provision Windows Mobile phones – see part one of this review. At the time, AirWatch could track iPhones, but more was expected in iOS4.
In part two, we review AirWatch Enterprise MDM using new iOS4 interfaces to manage iPads, iPhones, and iPod touches. Although these features took awhile to mature, they were well worth the wait. Using this Software-as-a-Service (SaaS), any IT group can deliver rich remote management for iOS4 devices – and the apps that run on them – with little effort. But there’s a caveat: this service is a continuing work-in-progress.
Managing iOS4
As described in part one, authorized admins can use the web-based AirWatch Console to manage a diverse array of smartphones, from Windows Mobile and Symbian to iOS and soon Android. However, the control that can be exerted over any device depends on vendor/model and OS version. Like other third-party MDMs, AirWatch Enterprise is ultimately constrained by each phone’s capabilities and SDK APIs.
For iPhones, iPads, and iPods, developers are further limited by Apple’s rules and procedures. Specifically, the AirWatch MDM Agent had to comply with SDK rules and pass Apple review to be published at the AppStore. But with iOS4, developers get to loosen these shackles a wee bit by using Apple’s shiny new MDM interfaces.
When the first iPhone was released, it had little security and no remote configuration. Over time, passcode and encryption features became configurable via XML profiles. Apple’s iPhone Configuration Utility could be used to generate profiles to be posted at websites for user installation. Eventually, ActiveSync support was extended so that Exchange servers could check passcode/encryption settings and remotely wipe lost iPhones.
MDMs like AirWatch began to use profiles and ActiveSync to manage iPhones, supplemented by data gathered by Agent apps. Although OS 3.x Agents could not run in the background, they could receive messages from the Apple Push Notification Service (APNS). These hooks were a starting point, but MDM was too user-dependent and employers still could not remotely install or control other iPhone apps.
Fortunately, Apple has now addressed this by adding native MDM to iOS4 (PDF). Employers are no longer limited to ActiveSync checks, desktop-generated profiles, or user-installed Agents. Instead, iOS4 devices and all of the apps that run on them can now be provisioned and tracked by enterprise MDM consoles, requiring near-zero user involvement.
In a nutshell, here’s how iOS4 MDM works. Each user browses to an employer-designated MDM provisioning portal to install Apple’s Global MDM Configuration Profile. During installation, the iPhone/iPad/iPod generates a device certificate and enrolls with the employer’s MDM. This process establishes an MDM relationship between the employer’s server and managed device.
Figure 1
Thereafter, commands sent by the employer’s MDM are relayed through APNS to managed devices. Devices respond directly the requesting MDM over HTTPS, creating a secure conduit over which to query settings, receive reports, install/remove profiles, and provision apps. Although Exchange can still apply ActiveSync checks to iOS4 devices, native MDM enables far greater control and visibility.
Vendors that have announced support for iOS4 MDM include AirWatch, BoxTone, MobileIron, Sybase, Tangoe, and Zenprise. However, starting with the same API does not result in identical functionality or usability. As we learned, an MDM’s power comes from how devices are presented and administered – and not for just one device, but for many.
Getting Started with iOS4
AirWatch Enterprise MDM for iOS4 can be deployed as an appliance ($5000/100 devices), licensed software on your own server ($30/device), or a subscription service ($2/month/device). For app management, add $10/device (software) or $1/month/device (service).
We reviewed the service, delivered by a multi-tenant Enterprise MDM 5.11 server, hosted by AirWatch. As such, there was no hardware to procure and no software to install. However, MDM for iOS4 requires a unique APNS certificate. This cert must be obtained from Apple by using an iOS Developer Enterpriseaccount ($299/year) to generate an X.509 request and download the Apple-issued response.
Anyone hoping for a free demo may be dismayed by this dependency. However, enterprises building their iOS apps may already have an Apple Developer account. We used an entry-level account ($99) to fulfill this prerequisite. No matter how you get your cert from Apple, the resulting .p12 file and App Bundle ID must be loaded into AirWatch before any iOS4 device can be enrolled. This cert will be used to authenticate MDM commands sent to enrolled devices.
Figure 1
To kick off enrollment, send your users an email or SMS containing a provisioning page URL, login, and activation code. If desired, AirWatch can even send an SMS to devices using a batch import file. As each user visits the URL, their device is placed into a default location group. (Recall from part one that every AirWatch subscriber is assigned a unique location to be carved into geographic or organizational subgroups.) AirWatch uses this location group to push the appropriate profiles to each newly-enrolled iOS4 device, completing over-the-air provisioning.
During our trial, we enrolled an iPhone4, a couple of iPods, and a few iPads. When all went well, our volunteers found enrollment quick and easy. But when problems surfaced – for example, a 3.x iPad that choked on an iOS4 profile – we had to contact AirWatch support. In general, the AirWatch Console could only tell us that MDM commands were sent to APNS; it often could not say whether commands were successful or why they had failed. This seems to be a limitation of Apple’s MDM architecture; we hope to see more error reporting in future iOS releases.
Something Old, Something New
Once enrolled, iOS4 devices join all other managed devices (e.g., Windows Mobiles, older Apples) on the AirWatch Console. On the Home page, they contribute to health stats charted for each location group. On the Location page, they are returned by filtered searches. On the Devices page, they appear in the Device Dashboard, accompanied by status and OS-specific actions.
Figure 1
For older (3.x) Apple devices, this Dashboard control panel can be used to view device details, request Agent check-in, view event or message logs, view current or historical GPS location, send an SMS message, or request a data wipe. But AirWatch must depend on a device-resident Agent to supply details and process APNS notifications. For example, if a 3.x iPad is sleeping, displayed details or GPS coordinates will not be current. To install a new profile on a 3.x device, AirWatch can only send an APNS notification, suggesting the user click a provisioning URL. Additionally, remote lock, passcode clear, and device query actions are not available for 3.x devices.
However, new iOS4 devices can use native MDM to overcome these limitations, with or without a device-resident AirWatch Agent. For iOS4 devices, this Dashboard control panel can:
- Display device queries:Send a notification to the device, requesting current data (e.g., details, certificates, installed apps, profiles, restrictions), all returned without user prompting.
- View device details, certificates, apps:Display most recently-reported values – for example, apps are shown with version, size, timestamp, and deployment method (iTunes or AirWatch).
- View config/app profiles, restrictions:Display all profiles or restrictions pushed to the device by AirWatch, including profile version, content, and creation time.
- Perform a security audit:Use recently-reported values to assess the device’s current security posture (below). (Note that audit requirements are not themselves configurable.)
- Send a message: Send the device’s user an email message or (for devices associated with a wireless carrier supported by CellTrustonly) an SMS text.
- View event or message logs:As for 3.x devices, returns a filtered but very basic list of AirWatch-device interactions (e.g., 4:05 am Server to Device Information Requested).
- Clear passcode or lock:Remotely lock or unlock a managed device. Note that if restrictions require a passcode, the user will be prompted to configure a new one within a grace period.
- Remote wipe:After receiving required admin confirmation, wipe all device settings and data, resetting it to factory default. (Users may restore personal data and apps from iTunes.)
- Remove MDM: Break the MDM relationship established during enrollment, removing all AirWatch-installed profiles, apps, shortcuts, and restrictions.
Figure 1
While some of these actions applied to older devices, many now go deeper or provide stronger control. For example, config profiles and restrictions may now be updated without user assistance – in fact, without the user noticing. Enterprise apps can now be deployed over-the-air, while enforcing compliance with IT-defined black lists.
From a security perspective, AirWatch for iOS4 offers major improvements. Help desks can use “clear passcode” to safely lock a lost phone while letting the user back in later. Restrictions like auto-lock duration can now be tightened on the fly, not just when the user checks mail. And black lists can be used to immediately “unmanage” or auto-wipe a device infected with malware.
But iOS4 MDM is still maturing, requiring sometimes awkward adjustments. For example, some details (e.g., IP address, GPS coordinates) are not surfaced by MDM APIs and are only available from devices with installed AirWatch Agents. AirWatch used Apple’s jailbreak API to check for hardware compromise – an API disabled in iOS 4.2. Dashboard controls for each device should match OS type, but sometimes did not. When using AirWatch to remotely remove MDM, we experienced APNS delays from six minutes to forever. The latter was a one-time anomaly that should never happen, but we still recommend testing features you expect to be fool-proof.
Configuration Profiles
In part one, we showed how AirWatch uses Odyssey to configure Windows Mobiles. However, iPhones, iPads, and iPods must be configured using XML profiles. Readers familiar with Apple’s iPhone Configuration Utility will recognize these profiles, because their attributes and encodingsare identical, no matter who generates them.
Here, AirWatch brings quite a bit to the table by wrapping profiles inside a centralized scalable GUI. AirWatch makes it easy to create, update, and deploy an extensive set of profiles to selected device models, versions, and locations.
To get started, use the Device Profile Management page (below) to load profiles that you created or have permission to edit. From here, you can search, filter, or publish profiles (i.e., push them to devices). For each profile, you can view a list of affected devices and deployment status (e.g., profile pending, installed, removed). By selecting devices from this list, you can also remove a previously-installed profile or install an optional profile.
Figure 1
Each profile is associated with an affected platform, model, OS, and location group. This lets you apply different policies to sets of devices – for example, location-specific Wi-Fi settings or prohibiting camera use on iPhones. If desired, profiles can be locked or assigned an “importance” or “sensitivity” level to be used for filtering.
After a platform has been selected, supported profile sections and attributes are displayed. To add to a profile, just select a section (passcode, restrictions, Wi-Fi, VPN, etc) and fill out a form. This part of the GUI is similar to Apple’s utility; you can even export AirWatch-generated XML. Although we were unable to generate correct Wi-Fi settings no matter what we tried, AirWatch produced valid XML for most other attributes.
AirWatch’s approach makes it easier to maintain complex profiles for a large diverse workforce. Because profiles are not deployed until published, XML can be exported for testing. Once published, profiles may be auto-deployed to every new device by setting Default Profiles for each model/version. Installed profiles can even be temporarily deactivated by checking a box or specifying effective dates (after which they expire).
We found this GUI promising and powerful, but a bit overwhelming. What’s the difference between a managed and unmanaged profile? (Managed profiles are installed transparently, while unmanaged profiles require user acceptance.) If a profile previously-removed from a device is updated, will the profile be re-installed? And so on.
AirWatch has done an admirable job here, but we still see room for improvement. First, we’d love a current admin guide (unavailable during our review). Secondly, we would like more visibility into profile-related device events, such as when installation fails. Finally, to avoid frustration and error, we would prefer to see fields like model that are not yet reliably implemented disabled.
Mastering Apps
Device attributes surfaced in iOS4 are more extensive than in OS 3.x, but the single-most important addition to iOS4 may be over-the-air application deployment. To this end, AppStore and enterprise apps can be managed by selecting the “Provisioning” tab on the AirWatch Device Profile Page (below).
Figure 1
iOS4 provisioning for third-party apps is indirect. AirWatch taps into this by letting you define “Recommended External Applications” for any location group. To add to this list, just supply an app name and iTunes URL. The URL is added to an App Catalog web page hosted by AirWatch for each managed device. However, recommended apps are still downloaded from the AppStore and installed in the usual fashion by iTunes.
iOS4 provisioning for enterprise apps is more direct and ultimately transparent. To install enterprise apps on devices in a given location, create App Profiles. Each profile must be associated with an App ID, version, description, icons, application (IPA) file, and provisioning profile. The IPA file may or may not include a provisioning profile, but only those with separate provisioning profiles can be disabled when MDM relationships are removed. If desired, EULA text, metadata, and screen shots can also be specified here. This info is added to App Catalog pages, but enterprise apps are stored on the AirWatch server and downloaded over-the-air, bypassing iTunes.
These provisioning interfaces let employers skip AppStore review and encourage users to install both third-party and enterprise apps. However, MDM does not currently let you force app install or update. Instead, use the AirWatch dashboard to query profiled and installed apps. You may also wish to direct users to their own App Catalog page by publishing web clip config profiles.
Finally, what about discouraging unwanted app installation? AirWatch supports this by enforcing Blacklist compliance. Blacklists can be defined for any location group, and may contain a list of forbidden device models, OS versions, and/or individual apps.
Figure 1
In theory, Blacklists might be used to prevent ActiveSync by iPhones older than the 3GS or iPads running anything other than iOS4. Blacklists might be used to send a warning SMS to any non-compliant device or even remote wipe that device. However, we had no luck sending an SMS and were told that ActiveSync disablement was still under development. Blacklists were added to AirWatch right before we completed our review, so we expect them to be fleshed out shortly.
Bottom Line
In addition to iOS4 MDM features covered here, AirWatch also provides alerting and reporting for Apple devices. For example, we spotted a few interesting reports, such as a passcode compliance report, an encryption compliance report, and a profile compliance report. These reports could be very useful to audit an individual device or entire location group’s security posture and identify those needing closer inspection or remediation.
In fact, AirWatch will no doubt add more alerts, reports, and other MDM features over time. Errors encountered early on had disappeared by the time we finished, while a few new errors had surfaced. Overall, AirWatch responded quickly to support requests. However, only major bugs were fixed promptly; minor bugs languished. AirWatch appeared to be focused on rapidly extending Enterprise MDM functionality – and not just for iOS4. While this approach offers clear benefits, it also caused some degree of instability for SaaS subscribers like us.
Ultimately, tolerating a bit of on-going change seems like a reasonable trade for turn-key full-featured scalable iOS4 MDM. For just a few dollars per month, AirWatch offers an easy way to secure those “look what I got for Christmas!” iPads returning to the office come January. It might take awhile to master all the details, but most IT admins will quickly grasp AirWatch’s use of iOS4 MDM to remotely manage just about any new iPhone, iPad, or iPod touch.
Lisa Phifer owns Core Competence, a consulting firm focused on business use of emerging network and security technologies. Since 1997, Lisa has been involved in mobile workforce policy development and best practices, ranging from wireless/VPN security to portable data defenses.
Follow eSecurityPlanet on Twitter: @eSecurityP.
