The recent revelation that Apple's iPhone OS had been falsely reporting to Exchange servers that iPhones and iPod Touches provided on-device encryption when in fact they did not has raised several questions regarding mobile device support for EAS (Exchange ActiveSync) policies -- vital safeguards many businesses employ to secure access to corporate information, whether to meet specific regulations or as a matter of general security prudence.
As it turns out, information on EAS policy support among mobile devices is not easy to come by. Also not easy is ascertaining what exactly will happen when an Exchange server is configured to use a policy that any given mobile device may or may not support.
[ The InfoWorld Test Center evaluates just what Apple's iPhone Configuration Tool can manage. | Read the "7 myths about iPhone Exchange policies" that users often believe. ]
Here's what IT can do to ensure the EAS policy compliance of users' mobile devices.
What EAS policies the devices really do support
Exchange ActiveSync 2007 supports 29 access and security policies that IT can enable. (To get the details on the policies and their values, check out Microsoft's documentation for Exchange Server 2007 policies.)
Just a handful of mobile devices support at least some EAS policies: Apple's iPhone; smartphones using Microsoft's Windows Mobile OS; Nokia's E and N series, as well as the S60 through a download; and Palm's WebOS, along with its defunct Palm OS.
Windows Mobile 6.1 supports all 29 policies, though an Exchange enterprise license is needed for 14 of them. Apple and Nokia did not respond to InfoWorld's request to list specifically what EAS policies their devices support; a Palm spokeswoman was unable to find the information even after several days. (Update: I finally got an answer from Palm eight weeks later, confirming the information below.) All three companies have published limited information on their Web sites:
- Nokia's site says that it supports "all security policies," without indentifying which ones those are.
- Apple's site says the iPhone supports Allow Camera, Password Enabled, Allow Simple Password, Alphanumeric Password, Password Expiration, Password History, Maximum Failed Password Attempts, Minimum Password Length, Maximum Inactivity Time Lock, Policy Refresh Interval, Minimum Device Complex Characters, Require Manual Synchronization While Roaming, and -- in iPhone OS 3.1 only -- Require Device Encryption.
- Palm's Web site says its WebOS 1.1 and later supports Password Enabled, Alphanumeric Password, Password History, Maximum Failed Password Attempts, Maximum Password Length, Maximum Inactivity Lock, Minimum Device Complex Characters, and Password Recovery.
Google's Android OS does not support EAS at all, and Research in Motion's BlackBerry does not support EAS directly. Instead, you use RIM's BlackBerry Enterprise Server, which has its own set of policies, all of which, of course, the BlackBerry OS supports.
Many devices allow users to connect to Exchange via IMAP, if Exchange is configured to accept such connections. No EAS policies are enforceable via IMAP.
How to make sure EAS isn't fooled
Apple's false reporting of on-device encryption for iPhones ended with its iPhone OS 3.1 OS update released on Sept. 8. By not telling users or IT admins of this fix to previously misreporting devices, Apple caused many users to unexpectedly lose access to Exchange once they upgraded to iPhone OS 3.1. (The iPhone 3G S and the late-2009-model iPhone Touch have on-device encryption, so they can accurately report support for this policy.)
The reason that the iPhone OS got away with connecting to Exchange servers that required on-device encryption is because Exchange has to trust that the devices are accurately reporting what they support, as well as the device's actual status for each supported policy.
When a device tries to connect to Exchange, EAS asks the device which policies it supports and whether they are in force. This occurs before the user is allowed to log in. In essence, the device says "yes" to the policies it has implemented, and Exchange assumes the answer is "no" to the rest. The Exchange server then grants access, or not, based on the policies that IT has configured it to require.
Thus, if EAS requires a policy that the device does not explicitly says it supports, "the device is blocked from accessing the Exchange server," a Microsoft spokesman confirms.
For example, if EAS is set to require a password that contains at least one nonalphanumeric character, and the device doesn't support that policy, it won't get access to Exchange. Even if the user's password happens to match that requirement, Exchange won't let the device connect, because the device has told EAS it can't verify the passwords, and EAS won't take the risk that the password might be OK.
However, there is a way around these requirements. EAS has an option called Allow Non-Provisionable Devices. If that option is enabled, EAS will let a device connect even if it does not support the policies IT has asked EAS to follow. In other words, if a device does not explicitly say it doesn't support a policy, EAS assumes it does support that policy. (The device must still follow the requirements of the policies it does support.) Presumably, if you've enabled Allow Non-Provisionable Devices, you've decided that the devices meet your access and security requirements and EAS should not block them due to lack of policy support.
Consider this example: EAS is set to require both a minimum length password and on-device encryption. But the device only supports the minimum password length policy. If the Allow Non-Provisionable Devices option is enabled, EAS will let the device connect to Exchange (assuming the user's password meets the minimum length). It essentially ignores the fact that the device doesn't support the on-device encryption policy. But if the Allow Non-Provisionable Devices option is disabled, the device won't be allowed to connect in this case, since it is known to support only one of the two required policies.
What to do about noncompliant devices
If a device's EAS policy support matches the ones you require, and they don't miss any policies you do require, then there's no security reason not to allow users of these devices access to Exchange. (You may have other reasons to disallow their access, such as their limited configuration management tools.)
At a minimum, you should make sure that the Allow Non-Provisionable Devices option in EAS is disabled. This treats a non-answer as a no when it comes to policy support, and will block devices that support only a subset of Microsoft's 29 EAS policies -- meaning the Apple iPhone, Palm Pre, and Nokia E series, N series, and S60 smartphones -- when your EAS policies on Exchange aren't supported by the device.
But if you're not sure the devices are telling the truth about the policies they support -- for example, if you have iPhone users that run iPhone OS 3.0 or earlier -- you need to do more. After all, even with the Allow Non-Provisionable Devices option disabled, EAS can't tell when the device is lying. Here are your options to block untrusted devices:
Ban them all. The safest low-cost choice for devices you don't trust to be accurate is to ban them altogether, such as by requiring the use of certificates for access that you haven't distributed to their users. Because these devices have no certificates installed, they can't connect. But this technique means you need to distribute certificates to the mobile devices you do support, which essentially limits you to BlackBerry (which requires the separate BlackBerry Enterprise Server) and Windows Mobile devices in an enterprise setting. (Apple's iPhone configuration tool does allow the distribution of certificates, but without the control you'd need to restrict usage to specific users and without the automation possible for BlackBerry and Windows Mobile.)
Create separate policies for different devices. A more nuanced choice is to create separate policies for users of these devices that don't support all 29 EAS policies; the goal of these separate policies is to raise the security requirements in the areas such devices do support to compensate for their lack of support in other areas. For example, if you have a corporate security standard that requires on-device encryption but you want to let iPhone users connect to Exchange, you could set up a policy requiring that a password be set that meets specific complexity thresholds, that passwords be changed every so often, and that remote wipe be enabled (through the Maximum Failed Password Attempts policy). For devices that support on-device encryption, such as Windows Mobile handhelds, you would have a simpler policy that, say, require just a complex password and on-device encryption. Of course, you cannot use this "alternative policy" option if you have a regulatory or other reason that forces you to use a policy on all devices. For example, if you're subject to HIPAA or privacy breach notification laws, you don't have the option of disabling the on-device encryption policy -- you risk audits, fines, and contract cancellations if you do.
Use a mobile management server. The third option costs money, but gives you the most control and confidence that you're not being fooled: Use a mobile management server such as Good Technology's or MobileIron's along with a mobile client that works with that server. For example, Good has a mobile client for the iPhone, Palm WebOS, and Android OSes that add on-device encryption using the Defense Department-grade FIPS standards. It also adds encryption to Windows Mobile 6.0 and earlier (later Windows Mobile versions come with on-device encryption). And MobileIron's product knows what EAS policies that, say, an iPhone supports and thus will block devices that lie about them.
Note that not all mobile management platforms can help enforce EAS policies or add missing policy support to mobile devices. For example, the Zenprise server does not provide these capabilities, though the company says a future version of the server and companion mobile client software will.
Related articles
7 myths about iPhone Exchange policies
Misinformation about connecting iPhones to corporate networks could get your business into serious trouble
The other iPhone lie: VPN policy support
The iPhone OS 3.1 fixed false reporting about Exchange policy adherence. It turns out that a similar flaw existed for VPN policies, too
Apple betrays the iPhone's business hopes
Apple's fix of a security hole reveals a long-simmering flaw and makes many iPhones suddenly incompatible with Exchange
Mac (in)security: How to secure Macs in business
As Macs make their way into the enterprise, IT needs to address these six security flaws before disaster strikes
21 apps Apple doesn't want on your iPhone
Worthwhile productivity apps you won't find at the App Store
The no-junk business iPhone apps finder
InfoWorld's interactive catalog of iPhone apps designed for businesses, professionals, and IT staff