Switching off legacy authentication for Exchange Online

Keeping legacy authentication enabled in your Microsoft 365 tenant should be avoided; however, going ahead and disabling has traditionally been difficult. Unless you already have a good understanding of your clients, it may present a risk.

Recent improvements to Exchange Online make this simple to configure, and you can now retrieve the information you need to identify potential clients that might be affected.

In this article, we will walk through the process to identify clients using legacy authentication, then utilize the new functionality available to Exchange Online to disable legacy auth for selected protocols.

Reviewing legacy sign-ins to Exchange Online

Before disabling legacy authentication for Exchange Online, it is essential to ensure that clients won’t be affected or prevented from signing in, or if they will, gather enough information so that you can inform people who will be impacted.

You can do this in the Azure Active Directory portal by reviewing sign-in logs using dedicated capabilities to filter based on legacy authentication. To do this, navigate to the Azure AD portal and then select Sign-ins under Monitoring.

Learn more: Introducing Certificate-Based Authentication for Exchange Online Remote PowerShell with Microsoft MVP Vasil Michev

In this section, you will see all sign-in attempts to Azure AD, including sign-in to all Microsoft 365 services from all your clients. We’ll first make sure the information we need is clearly displayed by adjusting the columns displayed by adding client app, as shown below:

client app

Next, we’ll use Add filters to add a filter based on client app:

add filters

The filter for client app will allow us to reduce the list shown to only relevant clients. To do this, expand the filter and from the drop-down list only select the protocols listed under Legacy authentication clients:

Legacy authentication clients

This list is likely to show us both successful and unsuccessful sign-ins. Whilst unsuccessful sign-ins are a concern; we will focus on successful sign-ins to gain insight into what should be real sign-ins from our users. We’ll do this by using Add filters to add a filter based on Status:

Status

We’ll then change the filter for Status to only show results that are a Success:

Status: success

You will then see what may be a long list of sign-ins from legacy authentication clients to Exchange Online. You can expand this using the Date filter to up to one month to gain more insights and use Download to export a list for review.

In the example below, we can see that many users widely use exchange Activesync. Therefore before disabling this protocol, we’ll need to move them to a modern-authentication capable client such as the Outlook App.

Learn more: How to Migrate Exchange Mailbox Permissions with Mike Weaver

If you examine the list and want to understand which legacy authentication protocols are not in active use and can be immediately disabled, then re-open the Client app filter and unselect protocols shown in your results. By unselecting Exchange Activesync, we will be able to see other protocols in active use then easily:

Exchange ActiveSync

We will repeat the process by removing other protocols in active usage until no results are shown. In the example below, we have discovered quickly that only Activesync and Exchange Web Services are in use, and there are no sign-ins over the last month from any other clients.

Exchange ActiveSync and Exchange Web Services

Selectively switching off legacy authentication

After discovering which protocols are not in active use, we are in a position where it becomes low-risk to disable legacy authentication.

Instead of using Exchange Online PowerShell, we can now use the Microsoft 365 admin center to disable legacy authentication for Exchange Online on a protocol-by-protocol basis affecting all users. To do this, navigate to Settings>Org Settings and choose Modern authentication from the services list. In the Modern authentication page, we’ll disable the legacy protocols no longer in use:

Modern authentication

You’ll note in the example above; we’ve disabled legacy authentication for IMAP4, POP3, Exchange Online PowerShell, and Autodiscover. For Exchange Online Powershell, this means you must use either the V2 module or the deprecated V1 module that supports MFA. By disabling legacy authentication to Autodiscover, we will prevent additional legacy clients from attempting to discover Exchange Online information.

Because we know legacy Activesync is in use in our organization and there is a small amount of active legacy Exchange Web Services usage, we’ll leave these protocols enabled.

Once we are happy with the settings, we’ll choose Save to apply these to all Exchange Online clients.

Disabling Legacy Authentication for all Exchange Online services

Using our sign-in log information, we will upgrade or reconfigure discovered clients to use modern authentication. After re-running the steps to filter Azure AD sign-ins and confirming we no longer have any active usage of legacy authentication, we’ll re-visit the Microsoft 365 admin center and disable legacy authentication for all Exchange Online protocols:

Modern authentication options

Further improving security for Microsoft 365 and Exchange Online

Disabling legacy authentication to Exchange Online isn’t the panacea of Microsoft 365 security – it is just one step towards helping keep the environment secure from particular threats, like password spray attacks.

Suppose you have Microsoft 365 E3, Microsoft 365 Business Premium, EMS E3, or Azure AD Premium licenses. In that case, you should consider configuring Conditional Access in your environment to selectively enable Azure Multi-Factor Authentication or configure rules to only allow access to your environment from Intune enrolled devices, Hybrid Azure AD domain-joined PC – or other criteria, such as IP address.

However, suppose you don’t have Conditional Access available. In that case, you may want to consider using Azure AD Security Defaults or (if you need it on a per-user basis) Office 365 multi-factor authentication. Azure AD Security Defaults is particularly useful if you wish to have a guided process over 14 days rather than immediately. It also provides additional MFA protection to privileged administrative actions in your tenant.  

About the Author

Steve Goodman

Chief Editor for Audio and Video Content and Technology Writer for Practical 365, focused on Microsoft 365. A nine-time Microsoft MVP, author of several Exchange Server books and regular conference speaker, including at Microsoft conferences including Ignite, TechEd and Future Decoded. Steve has worked with Microsoft technology for over 20 years beginning and has been writing about Exchange and the earliest iterations of Office 365 since its inception. Steve helps customers plan their digital transformation journey and gets hands on with Microsoft Teams, Exchange and Identity projects.

Comments

  1. Tim

    so we have disabled basic authentication through CA, however we have a large problem where occasionally a user will have a brute force attack on their account using basic authentication bots and locking out the account…mind you they dont even get to the CA level because the password is wrong, our users however are locking out constantly. Is there a method to disable basic auth. at a pre-authentication level? this way when these type of bot campaigns occur our end users wont be affected.

    1. Steve Goodman

      The methods in this article explain how to for Exchange Online. You can now control these settings directly in the Microsoft 365 portal, too. The reasons you’ve mentioned above are exactly why it’s worth doing this even if you disable legacy authentication via CA.

    2. Avatar photo
      Tony Redmond

      The thing about CA policies is that Azure AD applies them after authentication. It’s best to block attempts to authenticate using insecure basic authentication over protocols like POP3 and IMAP4 to stop attackers getting that far, and that’s why Exchange Online has authentication policies…

  2. McCount

    Hey Steve,

    So MS have plenty of guidance on blocking legacy auth via CA policies, but how do exceptions work? For example, allowing a specific user or mailbox access via legacy auth from trusted addresses? Or even a rule that allows legacy auth from said trusted source to the mailbox? Is this a scenario you’re familiar with?

    Thanks

    McCount

  3. carol

    Hi Steve, we have been told that we must switch off legacy authentication to allow guest access to Teams. Is there no work around to this?

    1. Steve Goodman

      Hiya,

      Disabling legacy authentication to Exchange Online isn’t a pre-requisite to allowing guest access to Teams. It’s advisable to do this anyway, but the two are not connected.

      Steve

  4. Eddie

    Hi Steve,

    How can I access a shared mailbox for a third party application that sends email on behalf of our company with Oauth?
    One reason for still allowing basic auth is this example, and I can’t figure out how to do this in the future.

    1. Steve Goodman

      The third party application will need to update their application to use Oauth. Unfortunately this will be required in the future, potentially this year, so it’s worth making sure they are getting ready.

  5. Tristan

    Hey Steve,
    Running through this i can see that our customer uses ActiveSync, Exchange ActiveSync, EWS, Mapi Over HTTP and Outlook Anywhere.

    What is the best course to getting them completely switched over to Modern Authentication? Is the process any different for Hybrid Exchange O365 Sites?

    Thanks

    1. Steve Goodman

      Hiya,

      The process to move them over from ActiveSync using Legacy Auth will be to either – move them to the Outlook App; or if they are using a modern-auth capable phone (such as an iOS device) they’ll need to re-add the profile, which *should* use Modern Auth.

      For EWS/MAPI over HTTP/Outlook Anywhere, then you need to check what client versions are in use. It should be Outlook 2016 or higher, which supports modern authentication and should switch over cleanly. If it’s 2013, then you can deploy registry changes to enable modern authentication, allowing a clean process to switch from basic to modern auth. For 2010 – they are very unsupported and will need a modern Office client installed.

      Steve

Leave a Reply