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