Expert's Rating
Pros
Cons
Our Verdict
In the hands of an IT administrator, Apple’s iPhone Configuration Utility becomes an important security tool for iPhones on his network. The new 2.0 release sports some welcome improvements, though it could use better documentation and still falls flat in some areas.
I’ve spent quite a lot of time working with the ICU since version 2 was released, and it has mostly been a good experience. (Note: Since we don’t do any in-house applications, or preload applications, I’ve not used the Applications or Provisioning Profiles features of ICU 2.)
There’s no work to upgrade configurations from the first version of the ICU. They just worked, and required zero extra work to continue using unchanged, a big benefit to adminstrators transitioning to the new software.
Within the Configuration Profiles setup, the UI has gotten a tweak to make using the new features easier. Instead of a series of tabs across the top of a pane, the individual features are now set up vertically, with rather nice icons. While a minor change, I’ve found the new layout to be much nicer to work with.
The completely new features, such as LDAP, CalDAV, SCEP, and others are easy to use: to set up an LDAP account or accounts in a Configuration Profile, for example, you fill in the Account Description, (the “Name” the user will see), the account password and username if needed, the DNS name or IP address of the LDAP server, whether SSL is used or not and the search base information.
For CalDAV, you have the Account Description, Server DNS name or IP Address and port, optional username and password, and should the account use LDAP. From the IT POV, the setup is dead simple.
Existing options get some new tricks as well. For example, when I’m configuring company-issued iPhones, I can set the profile to be unremovable except by wiping the device. I can still enforce a passcode, but I can require a more complex passcode, with non-alphanumeric characters, I can set aging/autolock/passcode history, I can set a grace period, (how long the device can be locked without requiring a passcode to unlock), and one that could be of great advantage to iPhone users with sensitive data on the device, maximum number of failed attempts. This lets you set a maximum number of failures on the device, (between 4 and 16). If that number of failures is reached, the device automatically erases all the data on the device. This is handy when dealing with a thief smart enough to prevent a remote wipe by using Airplane Mode.
In the restrictions section, you can completely lock a user out of Explicit content, Safari, YouTube, the iTunes Music Store, the App Store, or installing their own apps on the device, as well as the camera.
Camera control is important for companies where security is an issue, and this may get the iPhone in the door in organizations that might otherwise consider a smartphone with a camera to be too high-risk for their employees to use.
Because ICU allows for multiple Configuration Profiles, I was able to create LDAP-only profiles for my existing users already on Exchange ActiveSync. If you have profiles that only differ by a single feature, (i.e. VPN users vs. Non-VPN users), then you just duplicate the profile, and make your modifications.
Oh SCEP Where Art Thou?
In ICU version 1, you could only hand out configuration profiles by directly connecting the iPhone to the workstation running the ICU, emailing the profile to the user, or having the user go to a Web site and downloading the file onto their iPhone. That left the process either in the hands of IT (direct connection to the iPhone), or required the user to install the profile.
In a true Over the Air (OTA) setup, the user goes to a secure URL in Safari, authenticates to that URL, and then the configuration proceeds from there. Usually the only other information anyone had to enter was their e-mail address and password. This was a feature that was not really well-implemented in the first version of the ICU, and something that a lot of companies wanted.
For example, one of the disadvantages to the e-mail profile was that the e-mail could ONLY be opened on the iPhone. Well, if you haven’t set up the iPhone for e-mail, you then had to send a company provisioning protocol to a device on an external e-mail account which meant the device had to have at least one e-mail account set up. For a personal phone, this may have happened, maybe not. For a company issued phone? You had to provision the device to provision the device. Not a great option.
The Web site option helped a little, but then making sure that the wrong people can’t get to the profile starts adding layers of complexity to the process, and the user still had to manually accept the profile, etc. It was slightly better in practice, but not by much.
With the ICU 2, Apple has provided a way for a company to deal with provisioning in a more automatic OTA manner, and it’s based around SCEP, or the Simple Certificate Enrollment Protocol. This allows a company to set up an SCEP server, and by using device specific items, such as the IMEI number, the device MAC address, and a challenge token, (read: Password/Passcode), a company can then pretty much automatically configure the device, and the only additional information the user has to enter are things that are specific to them, such as e-mail address and e-mail password.
It’s a great step forward for Apple, but there’s a problem. While the iPhone Enterprise Deployment guide does a great job of showing you how the process works, and giving examples of the XML responses, what it does not do is provide any useful information on setting up an SCEP server. Now, SCEP is an internet draft proposed by Cisco, and they (eventually) have documentation on it, if you don’t have Cisco gear, that’s kind of useless, and Apple provides no links to that info anyway.
Apple provides three links to “help you out” with SCEP:
That’s it. Now, if you have an SCEP expert in-house, that’s probably enough to get you going with it. If you don’t, then it’s kind of useless. SCEP is still kind of new even on the Cisco side, and if you’re trying to get it to run on Mac OS X Server, at the moment, there’s effectively nothing to help you get moving. So it’s a great idea, but at the moment, effectively useless until some implementation documentation gets created and propagated.
My final complaint with ICU 2 relates to its ineffective support of LDAP. For example, all my user records are in LDAP via Open Directory. When I do an install via direct connection, why can’t I point things like the Exchange Active Sync profile at someone’s username, and have it grab the e-mail address and password from my LDAP server? Why can’t it do the same for e-mail and or CalDAV, especially if you’re using Apple’s Mail and CalDAV servers, or your e-mail server ties into Open Directory?
It is perfectly possible to securely get this information, but you can’t, and so you have people having to type in user names, e-mail addresses, and passwords, and it’s unnecessarily tedious. (This may not be an issue in SCEP, since it does tie into LDAP, but based on the lack of good documentation on SCEP, especially as it applies to iPhone Provisioning…who knows. Well, I guess Apple, but they aren’t telling at the moment.)
The new feature set in ICU has been really handy for me, and I do appreciate it. Unfortunately, the utility makes you hit walls that shouldn’t be there, like good implementation docs for a feature that a lot of people want, it’s really frustrating, and that’s just not the Apple Way.
[John C. Welch is a senior systems administrator for The Zimmerman Agency, and a long-time Mac IT pundit.]