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:
Next, we’ll use Add filters to add a filter based on client app:
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:
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:
We’ll then change the filter for Status to only show results that are a 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:
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.
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:
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:
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.