Feedback by UserVoice

How can we improve compliance or protect your users better in Office 365?

← Office 365 Security & Compliance

Add ability to deny EWS and MAPI clients using Basic Authentication, with Client Access Rules for Exchange Online

Currently, MFA for Azure AD / O365 is useless regarding protection of mailboxes in Exchange Online, as EWS and MAPI clients can still connect to mailboxes using Basic Authentication, even with Conditional Access rules in place to require MFA, and there's no way of denying this server-side on EXO.

The newly-released Client Access Rules feature promises this functionality in its documentation (see https://technet.microsoft.com/library/mt842508.aspx and https://technet.microsoft.com/en-us/library/dn913650(v=exchg.160).aspx), but unfortunately the functionality is crippled. You can only make rules in the following combinations (info from EXO Engineering team):

OutlookWebApp: BasicAuthentication, AdfsAuthentication
ExchangeAdminCenter: BasicAuthentication, AdfsAuthentication
RemotePowerShell: BasicAuthentication, NonBasicAuthentication
ExchangeActiveSync: BasicAuthentication, OAuthAuthentication, CertificateBasedAuthentication
IMAP4/POP3/OfflineAddressBook/PowerShellWebServices/ExchangeWebServices/REST: none

Note there is no mention of OutlookAnywhere (MAPI) in the above list, but from my own testing, it's impossible to create rules around that protocol. EWS is explicitly mentioned as not possible to restrict auth type for.

IMAP and POP are also bypasses for MFA, but it's easier to turn those off, but many things are dependent on EWS (including Outlook mobile apps), and Outlook (desktop) is of course dependent on MAPI (OutlookAnywhere). It would be useful to control REST too, as I understand some mobile apps will use that.

Yes, you can use CAR's to allow only certain IP's and users to connect with certain protocols, insist everyone VPN's in before connecting, and try to force compliance Outlook client-side, using GPO's to turn on ADAL and then lock down the registry, but this doesn't stop a phisher bypassing MFA for one of your users from whom they've phished username and password, and getting full access to their mailbox.

This is a pretty big security hole for us, and I'm surprised there isn't more noise about it across the internet. I just get blank or stock responses from support and escalation engineers on this, so I'm hoping this post helps.

404 votes
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
Sam Buccieri-Gillett shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
working on it  ·  O365 Compliance and Protection Feedback responded  · 

Thanks for taking the time to provide this feedback. We’ve updated the TechNet documentation (https://technet.microsoft.com/library/mt842508(v=exchg.150).aspx) to clear up confusion around which authentication type and protocol combinations are supported in CARs. Expanding support for more combinations could prevent bad actors with valid credentials from accessing mailbox content, but it wouldn’t help with scenarios like password spray attacks or malicious lockout attempts because CARs are evaluated post-authentication. There’s work underway on a solution that covers a broader array of basic authentication scenarios – we’ll share more details as soon as possible. In the interim, this blogpost (https://cloudblogs.microsoft.com/enterprisemobility/2018/03/05/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks/) outlines the recommended approach for forcing multi-factor authentication when using AAD and ADFS.

12 comments

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Neil McC commented  ·   ·  Flag as inappropriate

    For me there are two things at play here:
    1. Ability to prevent basic auth and stop circumventing MFA - my understanding is that this can be done using Authentication Policies applied per user. It would be better via CAR because in very large tenancies, I'd be managing a handful of rules rather than scripting a vast per user implementation.
    2. Ability to control client connection to EXO - it's this that brings me here. I have a scenario where I wish to block access to EXO from the Outlook desktop client, for certain users and this may also include outside of certain IP ranges. CAR includes Outlook Anywhere as a protocol so I can create the kind of rule that I want. However, unlike the OP's statement above, Outlook Anywhere <> MAPI, at least not exactly anyway. This means that a CAR to block Outlook desktop accessing EXO results in blocking the sending/receiving of email but does not prevent automatic download of the OAB, nor access from the client to the GAL because these use MAPI. The specific situation I want to prevent is a subset of users being able to connect Outlook from non-managed devices and export all users contact details. Even when I successfully deploy CAR to block 'OfflineAddressBook' and 'OutlookAnywhere', they do not stop the Outlook client connecting to EXO to acquire OAB and GAL data. This strikes me as a security hole also as the purpose of the CAR is surely to prevent 'access' to the service, not just to prevent mail.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Hi.

    Apologies for posting this here but there seems very little on this anywhere else.

    I am trying to test our security setup re: Basic Authentication using c# EWS.

    I am using the following lines to connect

    ExchangeService myService = new ExchangeService();
    myService.Credentials = new NetworkCredential(userData.EmailAddress, userData.Password);

    Am I correct in assuming that this is Basic Authentication and not Modern Authentication?

    Thanks

  • Steve commented  ·   ·  Flag as inappropriate

    EWS really needs to be changed to allow modern authentication to support 2FA.

  • Devlin commented  ·   ·  Flag as inappropriate

    We would also like the ability to completely turn off legacy authentication. We are planning to force all our users to MFA but cannot currently tell who is still using legacy authentication at this point. We want to avoid them having to setup per app passwords.

    Setting up ADFS properly with HA is not an option at our current size. I think you will find many of your smaller customers will find that far to much of an ask. The ability to set these conditionally via Azure AD would be great.

  • Nilis commented  ·   ·  Flag as inappropriate

    This is extremely important to have this option in CA policies!
    Just a simple CA policy with Require Modern auth for all EXO protocols e.g. EWS/MAPI/IMAP/POP3 etc or block authentication, where you could make exclusions for legacy printer user needing to do IMAP/POP3.

    @Anonymous, app passwords are not helping. This is not MFA in my opinion. Its just a "better" password.

  • Jared P commented  ·   ·  Flag as inappropriate

    +1
    Here is what i want to do:

    New-ClientAccessRule -Name 'Require modern auth for EWS' -Action DenyAccess -AnyOfProtocols ExchangeWebServices -ExceptAnyOfAuthenticationTypes OAuthAuthentication

  • Anonymous commented  ·   ·  Flag as inappropriate

    I am seeing this too. I think the simplest way for Microsoft to solve it is to allow us to use app passwords with conditional access.

Office 365 Security & Compliance: Advanced Security Management

Categories

Feedback and Knowledge Base

(thinking…)

Related Sites