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.

384 votes

Vote

(thinking…)

Facebook

Google

Forgot password?

Create a password

Signed in as (Sign out)

You have left! (?) (thinking…)

Sam Buccieri-Gillett shared this idea · January 10, 2018 · Flag idea as inappropriate… · Admin →

working on it ·

O365 Compliance and Protection Feedback responded · April 20, 2018

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.

11 comments

Add a comment…