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.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.
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.