In this excerpt from Office 365 for IT Pros we look at the controls that are available to you for managing Exchange Web Services.
Exchange Web Services (EWS) is an API that enables client applications to communicate with Exchange Online. Applications can use EWS to retrieve information from Exchange Online services, or to interact with data in Exchange Online mailboxes. For example, an EWS application can retrieve information about calendar items for room mailboxes to determine which items might have an organizer who no longer works for the company.
EWS is also used by Microsoft Outlook for calendar free/busy information, Out of Office settings, calendar sharing, and other features such as MailTips. In general it is a useful protocol, but as with any protocol used to access Exchange Online there are controls available for administrators to use for a variety of scenarios. EWS controls can be managed at the mailbox level or the organization level.
PS C:> Get-CASMailbox Alan.Reid | fl ews* EwsEnabled : True EwsAllowOutlook : EwsAllowMacOutlook : EwsAllowEntourage : EwsApplicationAccessPolicy : EwsAllowList : EwsBlockList : PS C:> Get-OrganizationConfig | fl ews* EwsAllowEntourage : EwsAllowList : EwsAllowMacOutlook : EwsAllowOutlook : EwsApplicationAccessPolicy : EwsBlockList : EwsEnabled :
Using the EWS allow or block list
In June of 2013 LinkedIn was found to have implemented a feature that invited users to enter their corporate email credentials on the LinkedIn website. LinkedIn would then connect to the person’s corporate email account and scrape it for email addresses to suggest them as potential contacts that should be invited to connect on LinkedIn. The connection from LinkedIn made use of Exchange Web Services and highlighted the need to monitor and control EWS access to Exchange on-premises and Exchange Online.
Disabling the entire EWS protocol because of one unapproved example of application access would deny your organization the many good things that EWS allows. Fortunately, we can be selective in what we block or allow for EWS by configuring an EWS application access policy. The EWS application access policy can be configured on a per-mailbox basis, or configured for the entire organization.
Continuing with the example of LinkedIn, to block EWS access by the LinkedIn user agent for the entire organization there are two steps required that use the Set-OrganizationConfig cmdlet. First, set the EWSApplicationAccessPolicy to enforce the block list.
PS C:> Set-OrganizationConfig -EwsApplicationAccessPolicy EnforceBlockList
Next, add the LinkedIn user agent to the EWS block list.
PS C:> Set-OrganizationConfig -EwsBlockList @{add='LinkedInEWS'}
The EWS block list is a multi-value attribute so it should be managed using add/remove methods to avoid overwriting existing values when you are making modifications. For example, to also add the OWA for Devices user agent to the block list you would run this command.
PS C:> Set-OrganizationConfig -EwsBlockList @{add='MOWAHost*'}
PS C:> Get-OrganizationConfig | fl ewsblocklist
EwsBlockList : {MOWAHost*, LinkedInEWS}
Similarly, to remove an entry you would run this command.
PS C:> Set-OrganizationConfig -EwsBlockList @{remove='MOWAHost*'}
PS C:> Get-OrganizationConfig | fl ewsblocklist
EwsBlockList : {LinkedInEWS}
Unlike ActiveSync device access rules the strings used for EWS block and allow lists can use wildcards for partial matches. However there is no quarantine action available, only allow or block.
The example above blocks LinkedIn EWS access for the entire organization. If you only wanted to block it for a single mailbox user the same process would be used, but the Set-CASMailbox cmdlet would be used instead of Set-OrganizationConfig. Enforcing a block list will permit any EWS application that is not in the block list to connect. A more restrictive approach is to enforce an allow list instead, which requires that any EWS applications be listed in the allow list before they can connect.
PS C:> Set-OrganizationConfig -EwsApplicationAccessPolicy EnforceAllowList
Enforcing a block or allow list for EWS has no impact on the Entourage, Outlook for Mac, or Microsoft Outlook applications. These applications are controlled with different EWS settings which are discussed next.
Blocking/allowing Mac clients
There are two separate Mac clients that use Exchange Web Services for connecting to Exchange Online; Entourage and Mac Outlook. Entourage is the oldest of these, with the Web Services Edition released in 2008 to allow connectivity to Exchange Server 2007 using EWS. Prior to that Entourage used WebDAV, which was deprecated in Exchange Server 2007 and removed entirely starting with Exchange Server 2010. Mac Outlook is the version of Outlook that ships with Office for Mac 2011, but also refers to the newer version of Mac Outlook that is currently in Public Preview and due for release with Office 2016 for Mac.
The use of Apple Mac computers is common in many corporate and education sectors, however some organizations will have reasons to block the use of Mac email clients. For example, an enterprise that permits BYOD may choose to block Entourage and Mac Outlook and require those users to instead make use of Outlook Web App or Outlook delivered using an application virtualization infrastructure.
The Mac clients are allowed by default and can be blocked using Set-CASMailbox or Set-OrganizationConfig. For example, to block both Mac clients for a mailbox user you would run the following command.
PS C:> Set-CASMailbox Alan.Reid -EwsAllowEntourage $false -EwsAllowMacOutlook $false
Other uses for EWS
Exchange Web Services is used by many organizations for custom application development, such as creating integrations between Exchange Online and their in-house line of business applications. It is also the API used for integration between Exchange Online and other Microsoft services such as Skype for Business and SharePoint Online. EWS applications can send and receive email messages, manage calendar items, and a whole lot more.
EWS is also used by many third party migration tools as the protocol for accessing Exchange Online mailboxes. In addition, an ecosystem of “cloud backup” products is starting to grow, using EWS as the access protocol for backing up mailbox items from Exchange Online to cloud storage, meeting the needs of many organizations who would like to make use of Office 365 but are concerned about backup and recovery.
Learn more about managing client access to Exchange Online in Office 365 for IT Pros.
Emails are not blocking on Android outlook app using this
Set-CASMailbox “mailbox” -EwsBlockList @{Add=”Outlook-iOS/*”,”Outlook-Android/*”}
Please help me on it thanks
Hi Paul,
Thanks for such a good article.
Just had query on situaltion i am facing right now where i want use EWS for an Outlook365 email account , but came to know the Microsoft will be ending EWS from office365 starting Oct’20.
So what are the alternatives i can think of using EWS from an outlook email account?
is there a way i can create a separate outlook account (with company controlled and domain name) which have access to EWS ??
Hi .. not EWS will be ending, but just Basic Authentication. So you will have to use Modern Authentication to access data like OAuth2 for Microsoft Graph.
Hi Paul,
Based on your diagram, Outlook for Android and iOS will connect to API, then reach on-prem exchange server.
So, would like to ask,
for Exchange 2010 on-prem servers, Outlook for Android and iOS will connect to API, then reach on-prem Exchange server. Am I right?
Also, the API that we been talking about, is it the EWS?
Please correct me if I am wrong.
Hope to get reply from you soon.
Regards,
Zabek
Paul, How can we get a list of apps that we know about that are using EWS with O365?
We deal with a third-party web application that syncs email using EWS. They have been experiencing some sync failures i.e. 400 – Bad Request. They have requested that we check the logs on the Office 365 end for more info.
If I understand correctly, Exchange Online EWS logs are not available to Office 365 customers, even through support tickets?
The only way to know for sure is to ask them.
User & organizational expectations:
1. Microsoft claims support for third party identity providers. The Organizational expectation is that third party identity providers are supported fully.
2. The organizational expectation when an organization turns on MFA for hosted email is that all avenues of access to that hosted email will be controlled by MFA or else require an explicit opt-out.
3. Assuming you are using the most up-to-date software provided by Microsoft, the expectation is that thick clients such as Outlook and Skype should continue to work when using MFA.
The reality:
1. Microsoft claims EWS is legacy and should be disabled for security reasons.
2. Microsoft also claims EWS is required for thick clients such as Outlook and Skype to fully function.
3. EWS does not support MFA from third party identity providers. This seems to be a Microsoft support failure, not a third party identity provider support failure.
4. Organizations who wish to fully enforce MFA either have to disable EWS or leave EWS available as a backdoor.
5. Hence, organizations who wish to fully enforce MFA have to choose between supporting Outlook and Skype thick clients OR supporting MFA.
Does any of this seem inaccurate to you?
I can’t speak to organization’s expectations (which I’m sure vary wildly). Or the extent of Microsoft’s support statements for third party auth providers, since I haven’t read those. I would not assume that support for a third party auth provider guarantees full support for every feature they offer. The concept of “support” or “supported” doesn’t always mean what customers think it means.
If you could point me to where Microsoft says EWS is legacy and should be disabled for security reasons, that would be helpful. I’ve not seen that anywhere, nor have I looked very hard for it just now.
I don’t agree with your conclusion in point #5. Customers are not limited to those choices. Microsoft’s MFA offerings support those clients.
Basically you haven’t convinced me that your assertion that you posted on December 23rd is accurate, so I don’t see any value in spending my time continuing this debate. Maybe if you’ve got something more conclusive to write about it that you think the community at large should know about, then you can do so on your own blog and people can debate you there.
I’m not trying to debate you, I’m trying to make my questions clear since we seem not to be able to communicate.
Obviously your strength lies in the Microsoft ecosystem. For companies that prefer *not* to require multiple different types of 2fa solutions (a third party SSO/MFA provider such as Ping, Duo, or Okta – all leading vendors in their own right with far more user friendly and flexible MFA solutions as far as my last tests go when compared to Microsoft) this is a huge deal.
This does pit security against usability in a fundamentally flawed way. Either you lose functionality or you are required to teach your user population how and when to choose between 2 different MFA solutions. Or you switch all of your users over to Microsoft’s proprietary solution and accept the fact that Microsoft will never play nicely with third parties.
@Mike, not sure why you’re making such a fuss about this in January 2018. Microsoft announced back in September 2017 that you can now use Duo, RSA, or Trusona for native MFA through Azure AD, however it requires an Azure AD P2 license.
This was Duo’s announcement at the time:
https://duo.com/blog/announcing-duos-native-mfa-for-microsofts-azure-active-directory
Hi Paul,
I have one question i would be thankful if you could please answer .Could we create a group and apply that EWS restriction on that group and then whenever we want to block someone from using EWS we simply add that email id to that group. Is this possible.?
Thank you!
Not exactly. You’d need to write a script that checks the members of that group and disables the EWS protocol for them, and have that script run regularly.
Create a text file with the useragent strings and process each string e.g. through a loop to add or remove items in an allow or block list.
Hi Paul, Great article. Is it still true that if you have F1 or Kiosk licenses in your tenant the org-level setting can’t be used?
Yes, I believe that is still true.
Wouldn’t it be relatively trivial to spoof a commonly allowed user agent, such as Mac for Outlook or Skype and completely invalidate the thin veneer of protection Microsoft offers for EWS and effectively bypass any and all 2FA or MDM controls for an organization that has requirements for use of Mac or Skype?
How does spoofing a user agent bypass 2FA?
Microsoft claims that the EWS allow or block list relies on a user agent string. If you spoof the EWS allow or block list entry to an application that is essentially universally accepted, you defeat the allow or block list control.
Sources: https://msdn.microsoft.com/en-us/library/office/dn467892(v=exchg.150).aspx, https://blogs.technet.microsoft.com/canitpro/2016/04/06/step-by-step-blocking-outside-apps-from-accessing-exchange-web-services/
Still not seeing a connection between that and your assertion that it will “bypass any and all 2FA or MDM controls”.
For those using supported third party solutions for 2FA instead of Microsoft’s own ADFS + MFA solution and are using a cloud deployment of Exchange / O365, the EWS protocol does not support Modern Auth and therefore does not support 2FA unless you are using Microsoft’s own platform. Given that EWS can’t be disabled for core functionality to continue to function, there seems to be an open back-door that bypasses 2FA requirements unless you are willing to ban or hamstring the Outlook thick client (and possibly Skype).
So EWS does not support Modern Auth. Modern Auth is required for non-Microsoft 2FA support. EWS is required and can’t reasonably be disabled. The controls Microsoft does support for EWS (user agent based filters) are easily subverted using open source toolkits.
I *think* this also affects MDM solutions by allowing a user to not opt-in to an MDM program in order to obtain their email as long as they use EWS.
If you have a workload that isn’t MFA protected, it’s not exactly a “bypass” at that point is it? You’re already exposed to non-MFA connectivity to that workload. User agent restrictions are never going to be bullet-proof security measures. It’s a layer of control to prevent unwanted use of apps and services (e.g. blocking LinkedIn, blocking random third party mail apps).
If it isn’t a bypass, would it essentially be disingenuous to say that Microsoft supports MFA on cloud hosted Exchange if you use a third party SSO provider? It seems that 3 of the big ones I’ve indirectly polled confirm this (Duo, Okta, Ping Identity).
I haven’t had my morning coffee yet so I don’t know what you’re actually asking me.
Paul,
Can you please let us know how to block 3rd party email accessing emails through EWS?
Like AquaMail and BlueMail? I’m not able to get user agent string name
Use the allow list instead of the block list. That will block everything except the user agents that you add to the allow list. Obviously that is risky if you have a lot of EWS applications running.
Thanks…. it worked but Skype has issues. May i know the name of the string that i need to add skype for business online?
I don’t know what it is. Perhaps you can find it by asking in the Skype for Business forums on the Microsoft Tech Community, or by contacting their support.
We are in Offce 365. We enabled Enforce Allowed list. We have exceptions for outlook on IOS and Android, but My Outlook 2016 client can send and receive email but not Mailtips or freebusy information. Anyway to allow this specifically for Outlook?
I suspect you’ll need to add the Outlook user agent to the allow list. I don’t know what the user agent string will be though. You might need to ask Microsoft via a support ticket.
Hi I am just wondering can I use ews to retrieve the gal info? I.e. the organization info. Somehow I am only able to get the contact information. Any suggestions?
Hi Paul, I enabled the EWS Allow List and now I have to find and add the programs to the allow list (for example Skype4B or any custom programs our developers wrote) but I could not find what to add, where to find the string I have to add? Are there any log files which I can find the Allow list parameter? Thanks…
IIS logs on your Exchange servers should show you the user agents hitting the /ews/ virtual directory.
what user agent string have you guys confirmed working with EWS allowlist enforcement. I am struggling in getting enforce allowlist to allow my SFB Mobile client that has string like this – RTCC/6.0.0.0 UCWA/6.0.0.0 AndroidLync/6.11.0.0 (VS985 4G Android 6.0). Whenever i applied the enforce Allowlist with the SFB agent, i still get cannot connect to exchange server error in SFB mobile and i cannot retrieve SFB Meetings. Your direction is appreciated.
I’m working with a client that uses EMM for conditional EAS approval, however TypeApp over EWS has been utilized by some users and we want to block it.
For the same reasons mentioned above, we don’t want to disable EWS entirely because it is useful, but we’d like to add TypeApp to the EWS block list.
I’m struggling to identify the EWS user agent string. I reached out to their support but no response yet. Anyone point me in the right direction?
Paul,
Great article, as there is not a lot written about this subject. One quick question, once EWS is enabled and functional, what is the expected response upon login? A quick web browser test of our O365 EWS address returns a: “You have created a service. To test this service, you will need to create a client and use it to call the service. You can do this using the svcutil.exe tool” instead of an actual XML response like our on premises EWS. I inquire because so far none of our (packaged, supposedly O365 supporting) third party apps can read from O365 EWS and I’m wondering if we’re missing something in our O365 config.
Application access to EWS is not something I deal with a lot. There’s an Exchange dev forum on TechNet or you could post to the new Microsoft Tech Community forums to see if anyone can point you in the right direction.
Hi Paul, Lovely Article.
But when I try to do it on my entire Organisation I am stuck with the following error!
===========================
License validation error: the action ‘Set-OrganizationConfig’,
‘EwsAllowEntourage,EwsAllowList,EwsAllowMacOutlook,EwsAllowOutlook,EwsApplicationAccessPolicy,EwsEnabled’, can’t be performed on the user ‘Configuration’ with license
‘BPOS_S_Deskless’.
+ CategoryInfo : NotSpecified: (:) [Set-OrganizationConfig], RuleValidationException
+ FullyQualifiedErrorId : [Server=HKXPR03MB0535,RequestId=657b9bdd-3929-4265-a4af-9f5d1fb911e2,TimeStamp=07-08-2016 04:00:59] [FailureCategory=Cmdlet-RuleValidati
onException] C7DE35AE,Microsoft.Exchange.Management.SystemConfigurationTasks.SetOrganizationConfi
=====================================
How do I skip the “Desk-less” users and apply only for other licenses
If you have Kiosk licenses in your tenant the org-level setting can’t be used, and you’ll need to apply the EWS restrictions at the mailbox level.
I believe even If you use “Set-CASmailbox” for a user who hold the Kiosk License it will not work as it will give you the same error given above.
Could you please help me resolving the same query as how to block the outlook for android and Outlook for iOS to place in EWSblocklist if the User holds the Kiosk License?
Hi Paul,
We were trying to use the block option in order to block some mobileapps to work with our EWS in 365.
The problem is that we managed to block Cloud Magic, while other applications such as AquaMail or Typeapp that were added to the block policy- Keep working.
I suspect that we in the EWS logs, these apps are recognized in different name then we added into the policy.
Is there any way to export EWS 365 logs?
We have managed to create logs in our internal environment (Exchange on Premise), but it does not help for Cloud services.
Thanks,
Dor
No, you can’t get access to those server logs for O365.
You could consider changing to a model of blocking by default and using an allow list for approved applications.
Is there any way of limiting what’s available over EWS?
We have a policy of requiring 2FA for any access to email from outside the office. We’re using Azure MFA, ADFS and WAP to provide that for OWA. Outlook Anywhere isn’t allowed outside the firewall, clients using domain joined laptops on the road use a VPN or DirectAccess. EAS we can control using Intune and Conditional Access to make sure it only works with devices that users have registered using MFA. All this is fine.
EWS is a problem for us. Some staff were using the Mac mail clients at home with just username and password to access email, so we stopped publishing /EWS/ at the WAP proxy. That stops people downloading email, but also stops mobile Lync 2013 clients from downloading calendar information, meaning staff can’t use the tap-to-join feature for conference calls when they’re outside the office. It’s a bit messy.
Using the EWS Allow List feature you’re talking about here sort of works, in that we can whitelist Lync mobile clients, but if it’s just using a client ID string in the header it seems like it would be easy to spoof. If someone could download the EWS API bits from MSDN and build a client that would connect to our EWS, claim to be Lync 2013 for iPhone and then download the contents of a user’s mailbox using just username and password, then we’re really not complying with our 2FA/MFA requirement if we allow EWS.
Right now we can block all of EWS at the reverse proxy, but if we wanted to move to mail hosted in O365 in the future, that won’t be possible.
Is there any way you’re aware of to disable email access in EWS, be leave calendar/contacts access enabled? It really feels like there should be.
Simplest answer I have is to just pick your poison. Live with the broken Lync functionality, or live with the possibility of someone spoofing the Lync user agent.
More complex answer, maybe there’s something you can do about it using a WAF that limits EWS calls to Calendar only. I have never seen that implemented though so I have no experience to share.
That’s about where I’d gotten to as well, but neither of those options seems to work for Exchange Online.
I’m a little bit stunned that there’s not a better solution. Microsoft talk a lot about OWA in Exchange Online having full 2FA/MFA support and things like quarantining and Conditional Access to provide 2FA on EAS. The impression I got was that I could put all my mail in Exchange Online and have it protected by 2FA. But there doesn’t seem to be a way to stop people from downloading all the email in an account using just the username and password over EWS, short of disabling EWS entirely, which breaks all kinds of stuff.
It just seems like a surprisingly large hole given no-one appears to be talking about it. My default assumption when that happens is that I’ve missed something or misunderstood something, but I can’t work out what…
There may be something you can do with AD FS claim rules but I haven’t explored your scenario to be able to say for sure.
Nice post, Paul! Thank you for describing such thigs like EWS, it is really interesting and helpful