Many organizations are moving to Mobile Device Management or MDM solutions to manage and control their mobile devices. The proliferation of Android and Apple devices has almost made this a necessity.
One of the primary controls with an MDM solution is to prevent mobile devices from connecting to company email unless the device is both managed and compliant with company policy. Almost every MDM vendor accomplishes this by using a gateway. In order for mobile devices to get email, they must first pass through an MDM gateway that checks to see if (1) the device is managed by the MDM solution and (2) if he device is compliant with company policy. If it fails either of those tests, it is prevented from retrieving email.
However, there is an issue. All of the gateways used by MDM vendors only monitor and control the Active Sync protocol. They do not monitor or control the Outlook Anywhere (RPC over HTTPS) or Outlook Web Access (OWA) protocols. Modern mobile devices are smart enough to try multiple protocols to connect to email if one of them fails. So, in certain email domain configurations, a device would still be able to retrieve email even though MDM was preventing an Active Sync connection.
The Backdoor
For example, a company has an email domain set up at mail.example.com. On this domain, Active Sync, OWA and Outlook Anywhere are active. If Active Sync is blocked, most smartphones and tablets will attempt to use Outlook Anywhere to connect. So, even if you have properly configured the MDM solution and properly configured the MDM gateway, non-managed devices can still get email.
Specifically, the mobile device is using the Exchange Web Services (or EWS) part of Outlook Anywhere to retrieve email. There are a lot of native and third party apps that will allow users to get email through EWS. Emoze for Android and Mail+ for Apple devices are just two examples. The native email app on Windows 8 phones goes right to EWS if Active Sync is unavailable. So bypassing Active Sync controls and using EWS is not difficult or complicated.
How do you know if mobile devices are connecting to EWS? Query the IIS logs on a CAS server for the cs-uri-stem value “/EWS/Exchange.asmx”. This will produce a list of connections to EWS. By looking at where the devices are connecting from along with researching the user agent strings, it can be determined if mobile devices are using EWS to get email rather than Active Sync.
Closing the Backdoor
There are a few different ways to close this backdoor, each of which will be discussed in turn.
Turn off OWA and Outlook Anywhere
This was actually one of the recommendations given to me when I discussed this issue with an MDM vendor. Their argument was that there is no point in restricting access to Active Sync while you allow anyone to connect to OA or OWA. I can see their point, but I don’t think this is a realistic option for most businesses.
Only Enable Exchange Web Services for Specific Users
EWS is used for a lot of things within an Exchange environment. Just a few of the things EWS is used for is Out Of Office functions, free/busy information, BES, and more. Turn off EWS and these services stop working. So this is probably not an option either.
Block External Access to Exchange Web Services
There are a variety of ways to accomplish this. If a TMG or UAG server is in front of the CAS servers, access to “/EWS/*” can be blocked. Another option is to restrict what IPs can connect to the EWS folder. This can be done by configuring IP Address and Domain Restrictions on the EWS folder from within IIS. Allow your private IP ranges and deny everything else.
The negative to this option is that external Outlook Anywhere users will loose functionality (out of office, free/busy, etc.).
Filtering Exchange Web Services
The better option is to filter what devices can connect to EWS. Starting with Exchange 2010 SP1, you can filter what user agents are allowed to connect to EWS. By enforcing a user agent white list, only approved applications (like Outlook or Outlook for Mac) will be able to connect to EWS. All other applications will be blocked.
This is accomplished through the use of the set-CASMailbox Exchange cmdlet. The command below will enforce a white list on EWS for the user “jdoe”. The white list will only allow connections from Outlook user agents.
set-CASMailbox -Identity jdoe -EWSEnabled $True -EWSAllowOutlook $True -EwsApplicationAccessPolicy: EnforceAllowList
There are also options for allowing Entourage for Mac, Outlook for Mac, and custom user agents. The two blogs below explain in more detail how to use the EWS white list feature in Exchange 2010 SP1.
http://thoughtsofanidlemind.wordpress.com/2010/08/12/controlling-ews-access-in-exchange-2010-sp1/
Unfortunately, there are fewer options for filtering EWS for plain Exchange 2010 and Exchange 2007. One solution is to use Request Filtering rules on the EWS folder within the IIS service on the CAS servers to block specific user agents. But that would require a lot of digging through the IIS logs on the Exchange CAS servers and regular review of the logs and the rules to ensure they are still effective.