Apple’s initial stab at the iPhone last year was a resounding success with consumers, but the business audience remained wary of the device due to its lack of security and management features. With this month’s release of the iPhone 2.0, Apple has taken aim at the corporate audience, providing a suite of new on-device features and centralized management tools intended to make the device compelling for business customers.
Based on eWEEK Labs’ tests, however, results are mixed. While the on-device improvements are most welcome, and hint at a much more secure future for the iPhone’s network connections and configurations, Apple’s first-generation configuration tools for back-end management and policy controls are woefully under-featured when compared to modern mobile device management platforms.
With its new iPhone Configuration Utility applications, Apple has taken a somewhat unsatisfying stab at providing mobile device management services for iPhones. Apple might have achieved its stated goal of providing a configuration tool for iPhones, but it does so in a fashion that leaves security, application delivery and device visibility by the wayside.
These shortcomings bear all the hallmarks of Apple’s long-standing lack of understanding for the needs of enterprise customers, and call into question the company’s ability to create an effective solution in-house that can serve the needs of its largest customers. Unfortunately, as the iPhone enters the infancy of its enterprise relevancy, there is nowhere else to turn for more robust enterprise management capabilities.
That said, the various iterations of the iPhone Configuration Utility could be successfully used in smaller, depot-style support environments, but the tools as currently structured lack the security and remote reach for large deployments to use effectively.
In a remote environment, the Configuration Utility requires a significant amount of user interaction to install policies–policies that are, by default, delivered in an insecure and compromisable manner. To cap it off, the users remain the arbiter of what is installed on the devices, as they have the power to simply remove any policies they don’t agree with.
Apple has introduced three versions of the iPhone Configuration Utility: an application that can be used only on Macs running OS X 10.5 (Leopard), as well as a pair of Web-based applications (one for Mac and one for Windows XP or Vista).
The versions are pretty much identical in terms of their ability to define and export policies for iPhone configuration, but the Mac-only application has a few additional capabilities missing from the Web-based iterations that deliver applications and track policies.
With all versions of the utilities, administrators can create profiles that deliver VPN settings (including the new Cisco IPSEC VPN capabilities); Wi-Fi settings (including certificates for enterprise-grade security); e-mail accounts for POP, IMAP or Microsoft Exchange servers; device-lock requirements; and even wireless WAN radio behavior. Administrators can also sign the policies with a certificate or a key so that users will see a little emblem on the profile before they install it that tells them the file is trustable.
That’s right–users will have to install profiles themselves. Apple does not include an agent on the device that can listen for and receive policies over the air.
Instead, administrators can export profiles from the Configuration Utility app for delivery via e-mail or a Web page. The user downloads the file, clicks on it to install (at which time the user can see exactly what the policy will do), and then answers a series of questions on the device to configure personalized settings such as a device pass code, Wi-Fi pre-shared keys, and user name/password combinations for e-mail and VPN configuration.
The policies themselves come in the form of an unencrypted X M L file. Certain fields-such as a VPN group password–are masked in some manner, but Apple makes it clear in the Configuration Utility EULA and in documentation that any sensitive data will be not be encrypted and that files should only be seen by authorized users.
Oddly, none of the Configuration Utility apps offer any mechanism for validating a policy before sending it out. The only way to make sure a policy is good is to install it on an iPhone.
This is unfortunate. Indeed, during tests I found it pretty easy to create an invalid policy: Simply clicking Configure on a profile to see what settings are available added the profile to the policy, even if I did not actually enter any data.
The Web-based iterations of the iPhone Configuration Utility also are pretty poor at policy version control–in fact, there is no version control at all. Each time I accessed the Web utility, it would show only the last policy I created. When I needed to edit a different policy, I had to import it back into the tool.
With the Mac OS X-based version, administrators can deliver applications to iPhones, but only to iPhones directly connected to the Mac running the Configuration Utility app–not to devices out in the field.
Administrators using this version also have the option of locking users from App Store access by setting a restriction on the iPhone. However, at this time, restrictions cannot be created via policy (even though Apple’s documentation offers hints that this feature is in the works). In addition, this version shows a rudimentary device inventory-for devices that have been connected to the Mac running the Configuration Utility at some point in the past. But there is no data collection for remote devices, so administrators cannot tell whether policies are up to date or installed at all.
Apple’s iPhone Configuration Utility Disappoints
=Configuration Web Utility for Windows to the Test}
Using the Windows iteration of the Web utility, I created a policy that would set Wi-Fi, VPN and Exchange configurations, and would require the user to create a pass code. Although I tested Wi-Fi using only pre-shared key-based encryption, the tool would also allow me to include a certificate with the profile to set up the new enterprise-grade security using 802.1x.
Within the Utility, the naming of policies is critical. There are actually two names: a common name that becomes the file name the user will see when he or she receives the attachment, and an identifier field that the iPhone leverages for policy precedence. Once you deploy a policy, the only way to modify settings is to send out another policy with the same identifier.
For example, I set up a weak pass-code policy (requiring four digits and no complexity) in a profile that included VPN and Wi-Fi settings (profile identifier1). Later, I tried to modify the pass-code policy (requiring six characters with one special character) with a second profile (profile identifier2). While an end user could install both profiles without a problem, the settings in identifier2 could not be activated until identifier1 was uninstalled. Alternatively, I would have needed to send out a modified version of identier1 to make the change.
I could set multiple profiles for both VPN and Wi-Fi configuration within a single policy. However, I could not include the Wi-Fi pre-shared key within the profile. This is a mixed blessing–it meant I either had to give the pre-shared key to the user who would install the policy (not acceptable) or be on hand to input the key myself (a significant burden when dealing with many devices). All that is moot, though, since the X M L-based file is not encrypted and I would not feel comfortable including that data in policy form.
As indicated earlier, administrators can require the user to set a device pass-code profile that matches certain length and complexity requirements. The administrator can also control the rotation period for the code, the number of illegal attempts accepted before device lock, and the number of minutes of inactivity before the code will be needed to unlock the device.
When the set number of incorrect login attempts is exceeded, the iPhone will lock until the device is synchronized with a known instance of iTunes. When locked, the iPhone is supposed to permit only emergency calls. However, I found that I could dial out to numbers other than 911 while my test device was in this locked-down state–a bug that could let thieves run up the cell phone bill.
Unfortunately, the use of a master administrator pass code is inconsistent on the iPhone. I found that administrators can set a secret pass code that protects the Restrictions page, thereby denying users access to certain features of the iPhone. Unfortunately, administrators cannot set this code via policy–they must configure it manually on a per device basis.
Also, installed policies are not protected by this administrator code. Users can enter the device lock pass code–which they set up–to remove a policy. This means that a user can remove a policy from the device, while the administrator cannot.
