none
EWS email access and MFA RRS feed

  • Question

  • I have a security problem that I can't seem to find the answer to, and I'm hoping someone here who knows EWS better than I do can point me in the right direction.

    We have a policy of only allowing access to files and email externally via methods that support 2FA/MFA. We use Azure MFA with ADFS and WAP to protect our Remote Desktop, SharePoint and OWA external access. For EAS we've been using device quarantining and we're now looking at moving that to Conditional Access via Intune. For all of these access methods, Microsoft have good solutions for integrating MFA.

    We're looking at moving our mail from on-prem Exchange to Exchange Online in the near future, and all of the above methods work well for Exchange Online as well. No hassles there.

    EWS is a problem for me. I'd always vaguely thought of EWS as a way for desk phones to display calendar details or look up contacts, that sort of thing, but of course EWS can be used to access email too. Most of the various Mac mail clients that support Exchange use EWS. Unfortunately, I can't seem to find a way of making EWS and MFA play nicely. None of the clients that connect using EWS can handle MFA. Right now I block EWS at the WAP reverse proxy, so it's only available to internal clients, and that complies with our security policy. That approach has two problems:

    a) offsite clients that use EWS for calendar lookups (e.g. Lync 2013 mobile client on company-owned iPhones) are semi-broken without EWS, and

    b) as I understand it, I won't be able to do this with Exchange Online. EWS will become available from everywhere. Staff will be able to use EWS clients to download their entire mailbox with only username and password.

    Going forward on Exchange Online, I can see only two options:

    1) Disable EWS across the board, breaking all sorts of things. Lync/Skype4B stops working properly, UM voicemail breaks, Lync desk phones become semi-functional, and I don't know what else breaks, but I'm sure plenty of other stuff will.

    2) Use an EWS Allow List to whitelist certain client types that don't download email (e.g. Lync iPhone client), while blocking things known to download email.
    https://exchangeserverpro.com/managing-exchange-web-services-in-office-365/

    The problem with the second approach is that it's just matching a string that the client sends. It wouldn't be hard at all to download the EWS API bits from MSDN and build a client that spoofed the known client header of the Lync iPhone client. I don't think I can really argue that this meets our requirement for MFA on email access.

    What I really need is something like Conditional Access blocking unknown clients from connecting to EWS as well as EAS. Or, better yet, the ability to toggle in an organizational config policy which types of content can be accessed over EWS. If I could say Calendar and Contacts objects are allowed, but Email objects are blocked via EWS everywhere, then I could happily allow EWS without MFA.

    Does anyone have any suggestions for me on properly securing EWS? We're running Exchange 2013 CU10 at the moment, but have SA on our Exchange licenses and CALs and I'd be happy to upgrade to 2016 if that gave me a feature that helped with this problem.

    Monday, October 12, 2015 12:34 AM

All replies

  • Hi Ryan,

    Thank you for the detailed explaination.

    This is what I understood, what you are asking is Exchange Web Services(EWS), exposes a way to access emails hence you want to use Multi-Factor Authetication (MFA) to secure it.

    OWA,OutlookAnywhere,ActiveSync works fine with MFA, but EWS doesn't. Hence you can't have EWS at the open internet.

    Your concern is once you move to Exchange Online, you can no longer use Mac Clients, due to your company's security policy to block un-secured EWS.

    If I understood correctly, the question arises, how to make "EWS and MFA play nicely", as per your compnay standards?


    Regards,

    Satyajit

    Please“Vote As Helpful” if you find my contribution useful or “MarkAs Answer” if it does answer your question. That will encourage me - and others - to take time out to help you.


    • Edited by Satyajit321 Monday, October 12, 2015 11:48 AM
    Monday, October 12, 2015 11:45 AM
  • OWA,OutlookAnywhere,ActiveSync works fine with MFA, but EWS doesn't. Hence you can't have EWS at the open internet.

    Your concern is once you move to Exchange Online, you can no longer use Mac Clients, due to your company's security policy to block un-secured EWS.

    If I understood correctly, the question arises, how to make "EWS and MFA play nicely", as per your compnay standards?




    Sort of, but not quite what I was asking. I don't need to support Mac clients using EWS for mail, I'd be very happy to block those. I do need to support EWS for all the internal things that require it. I know there's a lot of integration between Lync/Skype4B and Exchange and that some of that happens over EWS. We have the Lync clients save their conversation histories into Outlook, there's contacts lookup in the Lync client, calendar lookups for conference call details, UM for voicemail and the Lync clients checking the Exchange mailbox in order to display the voicemail notification properly. Most or all of these things use EWS in some manner.

    If I can't stop the EWS service in Exchange Online from letting people download email without MFA, or stop it letting people access email at all over EWS, then I'll need to completely disable EWS on our Exchange Online tenancy. That will break lots of the integration features with Lync.

    Microsoft have put quite a bit of effort in the last few years into supporting MFA on OWA and EAS, but it feels like a wasted effort if EWS is sitting there like a gaping back door, allowing you to download email without MFA. The fact that I can't find anyone really talking about this online makes me think that I've missed something and that larger companies who have gone to O356 and Exchange Online with MFA must be doing something I don't understand to lock down EWS email access. I just can't work out what it is that they're doing.

    Is it really that MFA isn't that heavily used and therefore no-one has run in to this problem yet? Or am I missing something?

    Wednesday, October 14, 2015 12:19 AM
  • You are not alone (not that it helps...)  We have almost identical concerns here... Any sort of "conditional access" would be helpful.  We continue to run with reduced functionality on mobile for Lync, and are struggling with how to (securely) expose EWS to the Internet to enable the additional functionality. 
    Tuesday, November 3, 2015 11:34 PM
  • So here's where I've gotten to so far.

    Everything I've read online about this problem just recommends using the EWS Allow List to whitelist certain apps, e.g.
    http://blogs.technet.com/b/matabra/archive/2012/08/23/block-mobile-apps-that-use-exchange-web-services.aspx

    The MSDN article on controlling access to EWS does however have a large security note pointing out that this is not a security feature, as the user agent string is too easy to spoof.
    https://msdn.microsoft.com/en-us/library/office/jj900165(v=exchg.150).aspx

    I can confirm this with a little more searching. ExQuilla is a plug-in for the Thunderbird mail client that lets it download mail using EWS. It's one of the programs that originally made me realise that MFA on OWA and EAS wasn't enough. Here's the ExQuilla doco on changing the user agent string to bypass EWS Allow List whitelisting.
    https://exquilla.zendesk.com/entries/41164327-Custom-User-Agent-string

    If you know an organisation uses Skype for Business internally and is using an EWS Allow List to prevent you from using ExQuilla or Apple Mail to download email, you just need to change ExQuilla's user agent string to UCCAPI/16.0.6001.1043 OC/16.0.6001.1043 (Skype for Business on PC) or UCWA/6.0.0.0 iPhoneLync/6.0.1445.0000 (Skype for Business on iPhone) and you're able to download email again.

    For now, the only safe answer seems to be blocking EWS from the outside world.

    On-prem, I can do this pretty easily at the reverse proxy that publishes our Exchange server. /OWA/* and /ExchangeActiveSync/* are allowed, /EWS/* is blocked.

    If we move to Exchange Online, it looks like I can do this with ADFS claim rules.
    https://technet.microsoft.com/en-us/library/hh526961%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396

    As long as your offices all have known, static public IP addresses, you can set up a claim rule that says "if client IP is this, and client is requesting /EWS/*, allow, otherwise reject". I haven't tested this yet, but it should work.

    Another option we're investigating is using Intune to deploy Skype for Business to iOS devices with a per-app VPN. That would make Skype on the iPhone sort of internal, and allow it to access EWS over the VPN. As long as the VPN only accepts client certificates issued by our Intune setup to known, trusted devices, that should work.
    http://blogs.technet.com/b/microsoftintune/archive/2015/02/03/how-to-set-up-per-app-vpn-using-microsoft-intune.aspx
    Cumbersome as buggery tho.

    What I really want is one of two options:

    1) EWS to be protected by the same Intune Conditional Access framework and EAS. They both provide access to staff email, I can't understand why only one of them is covered by Conditional Access.

    2) A server-side switch on Exchange to control what data types are available over EWS. I should be able to switch Email, Calendar, Contacts, Tasks, and Notes on or off using either Set-OrganizationConfig or Set-CASMailbox, just like I control the other EWS access settings. If I could block Email and Notes, and allow Calendar and Contacts org-wide, I'd be happy to expose EWS to the world with only username/password auth.

    Obviously option 2 requires changes from the Exchange team and probably won't happen until at least the version after 2016. Intune is a more agile product, so I'm hoping option 1 becomes available sooner.

    I'm really starting to think that half the problem is that lots of people don't realise email can be downloaded over EWS. The more I google and the more forum and blog posts I read on the topic, the more this seems to be an unwelcome surprise to admins who *thought* they had everything locked down.

    So if you ended up on this thread just browsing the forum, spread the word. I don't think we're going to get a fix for this until there's a fair amount of noise =)

    • Proposed as answer by Aaron Marks Sunday, October 30, 2016 8:20 PM
    Thursday, January 28, 2016 1:01 AM
  • Hi,

    Did you make any progress with this, we've got the exact same concerns with EWS and it does appear to be quite a big hole in their thinking.

    As our staff email is hosted internally ATM I am looking at doing an IP restriction on the EWS site in IIS, this might cause a few niggles for people that might have Skype on their mobile devices and will definitely upset a few people with Mac's or non-standard mobile mail clients like Spark that have been circumventing our security procedures but I think we are willing to do that.

    It might be more of a problem should we decide to go down the O365 route for emails or a Hybrid configuration, as our Students use O365 mailboxes, but it is currently kept fairly separate from the staff email system.

    Thanks

    Jeff

    Monday, May 1, 2017 6:34 PM
  • Hi Jeff,

    No progress at all I'm afraid. We are blocking /EWS/* in our WAP reverse proxy, and yes it does cause problems for the Skype for Business mobile app. The list of upcoming calls is blank and there's a "we can't connect to Exchange" banner at the top of every page. This does also block the Apple mail app on Macs and Outlook on Macs, but we're OK with that. We block Outlook on personally-owned PCs too, by not allowing RPC/HTTP or MAPI/HTTP from outside the firewall. Anything that caches mail needs to either support remote wipe (e.g. iPhones using EAS) or meet password and full disk encryption requirements (company laptops with bitlocker). Home PCs and Macs are both told to use remote desktop or webmail.

    We're getting closer to moving mail to Exchange Online, but still don't have a real fix for this. The best I've come up with is messing with ADFS claim rules to only permit requests for EWS if the source IP of the request is the static public IP of one of our offices. That's not elegant, and I haven't gotten it working yet, but it seems to be all there is for now.

    And no, I'm not happy about that ;-)

    Tuesday, May 2, 2017 3:47 AM
  • Sounds like fairly similar concerns.  We've got a lot of high profile Mac's internally so do need EWS to work internally, I don't publish that via WAP, but as suggested I think I can achieve the same outcome by doing IP filtering on the virtual app\folder in IIS.  Although, anyone that takes their MacBook home will not work and I'm not sure how many people that will upset.

    We do have a small number of people with DirectAccess, but these devices are owned by us with BitLocker enabled as well.

    For EAS we only activate that for people if they accept the remote wipe policy and a 6 digit PIN on their phones.

    We have two Outlook Anywhere users that I suspect will be getting moved to DA very soon, but that is less of an issue as on Exchange 2016 you can set per user whether it is enabled onsite and offsite, so we have just disabled it offsite for all other users.  This would fall down a bit for Exchange Online as technically everything is offsite from MS.

    Ideally some kind of trusted device using certificates or something would be a good way of achieving what we want, that would use our CA and only certificates we authorise, but I'm not sure MS see it that way.

    MFA offers some protection but not the scenario where someone downloads work onto a home PC.

    Jeff

    Tuesday, May 2, 2017 8:48 PM
  • Not very clear at the moment, but as per Nov 2016 update it seems, EWS is covered if connection to Exchange is enforced with Modern Authentication only blocking all the client not supporting Mordern Auth.


    App password might be used to bypass, but it would act as a 2FA auth.

    For Exchange Online, if you enable Office 365's MFA then EWS can't be accessed unless it is by a supported client or by using the app

    https://duo.com/blog/on-vulnerabilities-disclosed-in-microsoft-exchange-web-services
    However, in Office 365, Microsoft has added a new mechanism called "Modern Authentication", which requires clients to authenticate using the Azure AD Authentication Library (ADAL). When enabled, Modern Authentication can be used to require multi-factor authentication for all access to Office 365 e-mail, including via thick-client protocols - although doing so will entirely disable e-mail access from legacy e-mail clients that do not support ADAL.

    Modern authentication for Outlook 2016 for Mac is supported with this release.

    Multi-Factor Authentication in Exchange and Office 365

    https://blogs.technet.microsoft.com/exchange/2016/11/04/multi-factor-authentication-in-exchange-and-office-365/

    Plan for multi-factor authentication for Office 365 Deployments

    https://support.office.com/en-us/article/Plan-for-multi-factor-authentication-for-Office-365-Deployments-043807b2-21db-4d5c-b430-c8a6dee0e6ba


    Regards,

    Satyajit

    Please “Vote As Helpful” if you find my contribution useful or “Mark As Answer” if it does answer your question. That will encourage me - and others - to take time out to help you.

    Sunday, July 9, 2017 7:12 PM
  • Hi,

    I don't think modern authentication\ADAL is supported with On-prem Exchange?  Haven't seen anything to say it is.

    Jeff

    Tuesday, July 11, 2017 5:41 PM
  • Hi Jeff,

    OnPremises don't think so, my response was for Exchange (Online).


    Regards,

    Satyajit

    Please “Vote As Helpful” if you find my contribution useful or “Mark As Answer” if it does answer your question. That will encourage me - and others - to take time out to help you.

    Saturday, July 15, 2017 9:45 AM
  • So there's a possible new solution to this in Exchange Online Client Access Rules.

    https://technet.microsoft.com/en-au/library/mt842508.aspx

    I haven't had time to play yet, but it looks like this would allow me to set a rule telling Exchange Online to allow EWS from my offices public IPs, but not from anywhere else. This would give us a situation similar to what we have with on-prem Exchange, and EWS blocked at the firewall, where internal clients can EWS with just a password, but clients on the internet at large can't use EWS at all.

    Again, I haven't looked into it in depth, but the AuthenticationTypes condition may allow me to do something like allow EWS with basic auth from my office IPs, and also EWS from the internet as long as it has 2FA.

    Client Access Rules are now on my to-do list for this year =)

    Monday, January 1, 2018 10:48 PM
  • We are on prem and we are trying to figure out how to block /ews at our IIS AAR reverse proxy that publishes exchange, lync and a few others.

    I thought putting an inbound url rewrite rule ordered at the top of our lists with the condition input {HTTP_HOST} matches the pattern: email.domain.com/ews to trigger action 403 Forbidden would be the answer.  Unfortunately it is not blocking and entering https://email.domain.com/ews on my iphone (which is outside of our network) still results in a username and password prompt.

    What is the best way to block this from off network?  I want to keep it on for on network so our Skype for Business / Lync 2013 clients still integrate with Outlook (free/busy information, conversation history, contacts sync, etc...).  I also don't want to potentially introduce a problem with our phone system integration to email (like voicemail to email etc...).

    We really just want to close the hole where our DUO MFA is not honored from external sources trying to access EWS.  In fact we had a professional pen test done and they were able to phish a user's password.  They were pleased to see MFA on VPN and OWA, but using the EWS backdoor they were able to go through this employees mailbox and screen shot some very confidential information to show us this weakness.  Now we paid this company to do this so we can learn what our vulnerabilities are and try to mitigate them, but had this been a malicious actor, we would have been screwed.


    • Edited by kjstech10 Thursday, February 1, 2018 10:02 PM
    Thursday, February 1, 2018 10:00 PM
  • I'm hoping they might fix this loophole in Exchange 2019 later this year, but not holding my breath.

    Jeff

    Sunday, February 4, 2018 5:22 PM
  • If you want to look at requiring MFA for on prem Outlook users, perhaps this may help:

    https://blogs.technet.microsoft.com/exchange/2017/12/06/announcing-hybrid-modern-authentication-for-exchange-on-premises/

    Sunday, February 4, 2018 5:49 PM
    Moderator
  • We are on prem and we are trying to figure out how to block /ews at our IIS AAR reverse proxy that publishes exchange, lync and a few others.


    Retire your IIS ARR and replace it with a 2012R2 or 2016 box running the Web Application Proxy role. WAP was built from the ground up to do this.

    Duo also integrates with ADFS and WAP to do 2FA at the proxy, without all your internal servers having to be set up for it.

    Tuesday, February 6, 2018 3:36 AM
  • If you want to look at requiring MFA for on prem Outlook users, perhaps this may help:

    https://blogs.technet.microsoft.com/exchange/2017/12/06/announcing-hybrid-modern-authentication-for-exchange-on-premises/


    That only applies to MAPI over HTTP, not to EWS.
    Tuesday, February 6, 2018 3:39 AM
  • I've now got my Exchange Online Client Access Rules set up and blocking EWS from any public IPs that aren't my offices. Working well, EWS works here and fails when you take the device anywhere else. Exactly the same outcome as using Exchange on-prem with WAP blocking /EWS/*

    Would still be really good to be able to configure EWS to only allow calendar or contacts and block email across the board. But for now, this is good enough.

    Tuesday, February 6, 2018 3:48 AM