Updated: June 2014
A common request we get from customers it how they can block many problematic or unauthorized (and uncontrolled) email clients connecting to their Exchange servers via Exchange Web Services.
Some background, first.
Originally all Microsoft "Corporate" email clients - Outlook primarily - used the MAPI protocol for all access to Exchange. This included access for all email, calender, free/busy (availability), address books, etc. Beginning with Exchange 2007, Microsoft slowly started segregating all of these components to a new more segmented and supportable architecture. In doing so, most of the new components were re-written to take advantage of standard web-based protocols which were much easier to support and get through firewalls and the like. With that - Exchange Web Services (EWS) was born.
Unfortunately, when they created the magical black box that is EWS, they also didn't give much in the way of Administrator documentation or good ways to control this within Exchange itself. At the same time, at Microsoft's recommendation, third parties were encouraged to perform all of their Exchange activities using these web services.
Some of the most common examples are Microsoft's horrendous Entourage client for the Mac, which was followed by Apple's conversion to use EWS in the Apple Mail client baked into OSX 10.6+ (Mountain Lion), and also by Blackberry OS via the "Outlook Web Access" option. At least the later versions of Blackberry used EWS, instead of their older versions which actually performed a type of screen-scraping of the OWA GUI.
With that in mind, it quickly became obvious that this access was hard to control and manage, as most of the endpoints received no policy whatsoever from the Enterprise AD or Exchange server. Your solution with Exchange 2007 - not much, other than block it completely at the firewall with TMG or ASA or something that could look for the path in the URL.
Exchange 2010 SP1 - Rejoice!
Thankfully Microsoft heard the feedback loud and clear, and beginning with Exchange 2010 SP1, this is highly manageable via new block and allow settings and lists that can be applied at an organizational or mailbox level!
The two commands used:
Note: Settings enabled/configured at the organization level are overridden by those at the mailbox level. This means you are able to enforce a secure policy by default, then just make a few exceptions for users.
Wildcard Note: It is very poorly documented that wildcards are only allowed when specifying an EWSBlockList. Wildcards are NOT allowed in any of the EWSAllowList parameters, and specifying them will break this functionality.
i.e. You can specify -EWSBlockList:"*Mozilla*" but not -EWSAllowList:"*Mozilla"
The most common configuration we setup for client is as follows: Outlook for Windows will be able to connect via any method for email, calendar, availability and BES and ActiveSync will continue to work normally.
Mac Outlook, Entourage, Blackberry BIS/scraping/OWA, certain Linux and non-Activesync Android clients will be blocked from connecting at all.
In the Exchange Command Shell, run the following commands:
Set-OrganizationConfig –EWSEnabled:$True –EWSAllowOutlook:$True –EWSAllowEntourage:$False –EWSAllowMacOutlook:$False -EWSApplicationAccessPolicy:EnforceAllowList To allow a BES Server to perform calendar lookups: Set-CASMailbox -Identity besdamin –EWSApplicationAccessPolicy:EnforceBlockList For any users who we want to approve for Mac: Set-CASMailbox -Identity <alias> -EWSAllowEntourage:$True –EWSAllowMacOutlook:$true ––EWSApplicationAccessPolicy:EnforceBlockList (note - we recommend the above method, because the Mac OS Mail client changes the string often based on version, and as a result if using and Allow List, the strings would have to be constantly updated as EWSAllowList does NOT allow wildcards) For any users who we want to approve for Blackberry Web Access: Set-CASMailbox -Identity <alias> –EWSAllowList:"Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0)"
Now your EWS is safe and secure!