Daniel Eran Dilger
Random header image... Refresh for more!

Exchange enhancements in iPhone 3.1 cause some users grief

EAS policy settings

Prince McLean, AppleInsider

Improved support for Microsoft’s Exchange Server’s security policy features, delivered in the iPhone 3.1 firmware update, has left some users angry after discovering that their mobile device is no longer compatible with the policy defined by their company.

Exchange enhancements in iPhone 3.1 cause some users grief
.
At issue is Apple’s iPhone client implementation of Exchange ActiveSync, the Microsoft specification Apple licensed last year in order to provide official support for Exchange Server sync to the iPhone and iPod touch.

EASy to wipe

EAS defines not only how Exchange server syncs data to mobile clients, but also involves remote management features like remote wipe and security policy such as mandating that all devices be set to use a PIN to lock the screen when not in use.

Microsoft has evolved EAS over time, adding new options that allow Exchange admins additional control over the devices they choose to support. For example, in Exchange 2007 Service Pack 1, Microsoft added a new security policy option to require device encryption on mobile devices in order to support a new feature of Windows Mobile 6.0.

With file level device encryption, administrators can rapidly remote wipe a lost or stolen device, minimizing the risk of its data falling in the wrong hands. Without device encryption, a remote wipe takes longer because the remote device must zero all of its files. This makes it more likely that a thief could interrupt the wipe process, although once a phone is stolen, a savvy thief can disable its network connection and attempt to prevent any remote wipe from ever occurring.

Client-side EAS

Client manufacturers who license EAS from Microsoft, including Apple, Palm and Sony Ericsson, can implement the EAS specification on their client devices however they like. For example, the Palm Pre’s Exchange support currently doesn’t support security policy involving PIN use or remote wipe at all. Even Microsoft’s own Windows Mobile 5.x implemented support for EAS differently than the current WiMo 6.x.

For example, under WiMo 5, EAS remote wipe couldn’t also clear any data stored on an installed SD Flash card. Since most WiMo phones shipped with very little included storage, any important data was most likely kept on this impossible to wipe Flash memory.

This effectively meant that Exchange admins simply could not really wipe a WiMo 5.0 phone, even though the devices were described as supporting a form of remote wipe. That detail didn’t stop pundits from favorably comparing WiMo 5.x’s ineffectual wipe with the lack of any remote wipe feature on the original iPhone up until the release of the 2.0 firmware.

Policy respect

An Exchange server has no way to demand that clients obey all of its security policies; it has to trust that client devices respect them. When administrators specify a given policy on the server, mobile devices that fully support those feature options will stop working if the server-side policy settings raise the bar beyond the devices’ capabilities.

That’s what happened to many iPhone users who upgraded to iPhone 3.1 only to discover that their device stopped syncing with any Exchange Servers using the default “RequireDeviceEncryption” policy set to “True.” Only the iPhone 3GS and the newly released 32 and 64GB iPod touch models support this hardware encryption feature; earlier models of the iPhone and iPod touch do not, and subsequently, their expanded support for Exchange policy settings forced them to no longer work.

IIn order for affected iPhone 3.1 users to reestablish a connection with Exchange, server-side administrators need to create a policy exception (for either that user or the entire server) which will allow connections to mobile devices that do not support device encryption. This was the status quo prior to Exchange 2007 SP1, which introduced the policy option, so it really isn’t a drastic reduction in security as some have suggested. It involves unchecking a box and clicking OK (below).

The only other alternative is for those users to either upgrade to phone hardware that meets the minimum requirements configured on their company’s Exchange Server, or downgrade back to iPhone 3.0 and simply ignore the security policy set by their company.

EAS policy settings

Oh the humanity

This change in the iPhone 3.1 update was poorly communicated to users by Apple, which should have at least alerted users of the potential impact of the upgrade during the installation process. The same update also quietly disabled tethering support on AT&T for certain users who had enabled the software feature against the terms of their AT&T contract.

The result was confusion and frustration by users, many of whom lack any capacity to motivate their company’s Exchange admins to help them understand what had happened, let alone accommodate them with security policy changes from the default settings many Exchange Server shops never bother to change.

Similar security policy problems have resulted in problems for Mac users. Windows Server introduced changes that broke compatibility with existing clients while trying to enhance the network’s security profile in tandem with the launch of Vista, for example. Support for alternative platforms like the iPhone and the Mac is not Microsoft’s top priority, of course. However, Apple’s increasing popularity among consumers, particularly among executives and mobile road warriors, has helped to promote improved support for Apple clients in many Windows-oriented companies.

Still, when unexpected things happen, many pundits are ready revile Apple’s security credentials and denounce the company in scathing terms. Writing for InfoWorld, Galen Gruman stated Apple had “betrayed the iPhone’s business hopes” and accused the company of misrepresenting the security profile of its iPhone devices, based on the speculation that iPhone 3.0 software must have “lied” by reporting that it was performing encryption prior to the update.

The problem with proprietary standards

In reality, iPhone 3.1 simply improved its support for EAS’s defined security policy options, with unfortunate results for anyone who wanted to sync with an Exchange Server set to the default policy settings that happened to exclude their model of iPhone.

The proprietary nature of EAS, along with its constantly changing specifications tied to Microsoft’s business decisions rather than industry consensus, creates a problem for consumers who want competition and choice along with the assurance that the phone they buy will work with their company’s servers.

Right now however, the enterprise messaging industry’s leading vendors have no desire to craft an open standard for mobile sync. Instead, RIM is promoting its own BlackBerry Enterprise Server product, which rakes in profits, while Microsoft is working to establish EAS as a way to anchor its dominance in corporate email with Exchange Server.

Imagine if Palm had paid Apple for the rights to sync the Pre with iTunes, but that part of the deal required Palm to only support features Apple allowed. This wouldn’t be ideal or open. On the other hand, it’s challenging for community consensus to build open standards that don’t hamper the potential for innovation. Emerging web standards are a great example of finding a common ground in between, where vendors can innovate with different engines and browsers that also implement common, compatible features.

Whether something similar will ever happen in the mobile world remains to be seen. Apple is rapidly becoming a significant player in the smartphone industry, having passed Microsoft’s combined Windows Mobile market share. With so many iPhone users, Exchange administrators have more reason than ever to accommodate them.

Apple is also taking its first real opportunity to enter the enterprise market seriously, and iPhone 3.1 is evidence of that, even if it results in short-term pain for some users right now. To help, Apple has revised its iPhone 3.0 Enterprise Deployment Guide (PDF) to include the new changes in iPhone 3.1.

Without much life left in its own mobile platform, Microsoft is likely to become increasingly supportive of third party mobile platforms on Exchange, and could someday even release EAS as an open specification to prevent a rival, alternative open specification from being launched.

Microsoft is actually making some use of the Open Mobile Alliance Device Management (OMA DM) protocol, which is also used by Symbian and in mobile device management tools sold by IBM. OMA DM is an offshoot to the SyncML consortium. Apple hasn’t attempted to support SyncML since the original version of iSync, and neither the iPhone nor Android seem to be paying any attention to OMA DM.

  • http://www.giveyourbrainachance.com jeromec

    I have a hard time understanding this article. The sentence “mobile devices that fully support those feature options will stop working if the server-side policy settings raise the bar beyond the devices’ capabilities” in particular, keeps puzzling me:
    What is a mobile device that fully supports feature options which are beyond the device’s capabilities???

  • kris

    @jeromec

    My understanding is that the iPhone 3.1. supports the encryption option(feature), but this setting(when set to TRUE) is above the capabilities of all iPhones and iPod touches released before 2009

    I hope I’m makings sense to you.

  • Hypothesard

    @jeromec
    A device (iPhone) that would recognize (support) all the rules to apply (enforce) when connecting to a Server-side appliance (Exchange server) even those rules forbiding a device lacking capabilities (iPhone EDGE and 3G) like Hardware encryption (which is present in iPhone 3GS)
    Even if It means that the Device (iPhone EDGE or 3G) is now excluded from accessing the Server-side Appliance.

    In natural language :
    The iPhone (all of them) with iPhone OS 3.0 didn’t have a full implentation of the latest “Rules to respect” when connecting themselves to an Exchange Server (2007 sp1) which sets to refuse connection with a device not having Hardware encryption.

    the iPhone OS 3.1 now fully support those setting on the server side and diplay the refusal and effectivelly forbid the connection to the Exchange server when the iPhone doesn’t have Hardware encryption (iPhone 3G and iPhone EDGE).

    Only the iPhone 3GS do have hardware encryption (Software encryption is not efficient in the real world : lack of speed when asked to “remote wipe”, which mean motivated party could crack open the device, then later on, decrypt the storage part, where Hardware encryption provides instantaneous “Remote Wipe out”)

  • MarkyMark

    This whole interwebz “episode” is turning into kind of an amusing impromptu IQ test – which readers immediately grasp the situation and its consequences, and which are left baffled? Lots, I suspect…

  • http://www.adviespraktijk.info Berend Schotanus

    This actually might be good news for Apple.

    The best way for companies to keep their employees satisfied and to prevent them for using workarounds that allow the use of private iPhones but threaten company security is to provide them with company owned iPhone 3GS’s.

  • Dorotea

    So lets see if I have this right.

    iPhone 3g/2g don’t have hardware encryption.

    iPhone 3G/2g running OS 3.1 is able to connect to Exchange Server when the security policy doesn’t require hardware encryption of the data on the iPhone. If Exchange server security policy does require hardware encryption, then an iPhone 3g/2g running OS 3.1 cannot connect.

    iPhone 3gs has the ability to do hardware encryption, so it can connect to Exchange server using OS 3.0 and OS3.1

    OS 3.0 did not fully implement client security policies for Exchange server. OS 3.1 does. It is left up to the client (iPhone OS) to fully disclose security to Exchange Server .

  • duckie

    @Dorotea
    It’s not that it’s up to the client to fully disclose security exactly. If a client doesn’t know about a given policy rule (such as encryption) when Exchange asks about it, then Exchange simply allows it to connect anyway. It’s a bit like someone asking you for ID at a nightclub door, and if you say nothing and produce no ID then they let you in anyway.

  • pa

    @duckie,

    Good analogy. Just to get a better feel for how Microsoft implements mobile device security on Exchange, you could have used airport security check in your example.

    – can you please remove your laptop, put your bags and jacket and shoes in a tray and place them on the conveyer to be checked by our x-ray technician?
    – *no response*
    – please go right ahead sir!

  • duckie

    Now that I’ve looked into this issue in a bit more depth, I should add that the policy setting that is likely to be making the real difference on Exchange is “allow non provisionable devices”. When set to true, this allows legacy devices that don’t support the “require encryption” rule (such as Windows Mobile 5 and 6.0, and iPhone OS 3.0 and earlier) to sync with Exchange. Exchange sites that previously allowed iPhones to sync would presumably have had this setting on and still do (and I’d hazard a guess that their old WinMo devices are still happily syncing). There is therefore no reason for admins in such places not to make a policy exception for iPhone OS 3.1 users since this will effectively be preserving the status quo.

    The hot air being blown around the web about “security holes”, “bug fixes” and Apple “breaking things” is quite frankly arrant toss and apparently written by people who have never been anywhere near an Exchange admin interface in their life.