Block legacy auth in Exchange Online


Today Microsoft announced the release of a new feature intended to help you put an end to all those password spray attacks we've been seeing lately. Namely, the feature allows you to configure a policy specifying which exact protocols to block legacy auth for, then apply this policy to some or all of your users.


As the block happens on the Exchange backend, before even hitting Azure AD for authentication, the feature might be a bit tricky to troubleshoot if not correctly configured. Make sure to check the documentation for all the details:


Here's also the original announcement:

5 Replies

I'd love to disable basic auth in my org as we've had instances where a mailbox has become compromised using a basic auth attack,  but as a 60k user base, we have a lot of legacy kit out there which just doesn't support modern auth.


Most users use Android too - and while we've explained they have the Outlook for Android app available some do prefer to use the native Android client.


One thing I was curious on though, using the article referenced in the announcement today, is that any different to disabling basic auth apps via a conditional access policy? As that would allow us to give the helpdesk staff targeted groups of users who we can disable for basic auth.

It is different from CA, the feature works by blocking the request at the Exchange server layer, even before redirecting to the auth provider.

Thanks for confirming


Am I right in thinking the end result would be the same though? Basic auth'd blocked using CA would be the same as blocking it on EXO?

Yup, but one of the benefits you get from this method, apart from the greater granularity, is that blocked/failed (or god forbid successful) logins will not trigger the lockout windows, as the request never reaches Azure AD. With CA policies, the block happens after authentication, at that point the account is compromised.

I did this for our Exchange Online a week ago but have seen no reduction in these login attempts (see below), which continue to pour in from places like China, as reported by the AAD portal.


Why?  Basic auth is disabled for all accounts, and it's definitely long since kicked in, since we've had several Apple users who've had to update their clients to login.


Does this suggest that hackers can be just as aggressive with modern auth?  Or that there's some piece of basic auth still around (aside from "AllowBasicAuthLogExport")?  This feature is in Preview, after all.

Status: Failure
error code: 50053
Failure reason: Account is locked because user tried to sign in too many times with an incorrect user ID or password.