In February 2021, we announced some changes to our plan for turning off Basic Authentication in Exchange Online. In summary, we announced we were postponing disabling Basic Auth for protocols in active use by your tenant until further notice, but that we would continue to disable Basic Auth for all protocols not being used. The overall scope of the program was also extended to include Exchange Web Services (EWS), Exchange ActiveSync (EAS), POP, IMAP, Remote PowerShell, MAPI, RPC, SMTP AUTH and OAB.
Today, we are announcing that, effective October 1, 2022, we will begin to permanently disable Basic Auth in all tenants, regardless of usage, with the exception of SMTP Auth.
Basic Authentication is an outdated industry standard, and threats posed by Basic Auth have only increased in the time since we originally announced we were making this change. The original announcement was titled ‘Improving Security – Together’ and that’s never been truer than it is now. We need to work together to improve security. We take our role in that statement seriously, and our end goal is turning off Basic Auth for all our customers. But every day Basic Auth remains enabled in your tenant, your data is at risk, and so your role is to get your clients and apps off Basic Auth, move them to stronger and better options, and then secure your tenant, before we do.
Even though we announced we were putting the work on hold, we didn’t stop improving security. Back in June we provided an update that we had already begun to disable Basic Auth for tenants not using it, and we described the process. We also explained how you could re-enable an affected protocol if you really needed to use it. This work has already protected millions of Exchange Online users.
Today, we have more news on how to prepare for this important change.
Beginning early 2022, as we roll out the changes necessary to support this effort, we will begin disabling Basic Auth for some customers with usage on a short-term and temporary basis.
IMPORTANT: Beginning early 2022, we will selectively pick tenants and disable Basic Auth for all affected protocols except SMTP AUTH for a period of 12-48 hours. After this time, Basic Auth for these protocols will be re-enabled, if the tenant admin has not already re-enabled them using our self-service tools.
During this time all clients and apps that use Basic Auth in the selected tenants will be affected, and they will be unable to connect. Any client or app using Modern Auth will not be affected. Users can switch to other clients (for example, use Outlook on the Web instead of an older Outlook client that does not support Modern Auth) while they upgrade or reconfigure their client apps.
If you receive a Message Center post between now and October 2022, informing you that we are going to disable Basic Auth for a protocol in your tenant due to non-usage, or you get one saying we know you are using Basic Auth, but we intend to proactively disable it for a short period of time, and you don’t want us to take that action for protocols in your tenant, you can use a new feature in the Microsoft 365 admin center to request that we not disable specific protocol(s).
We added this feature to the self-service tool to help you minimize disruptions as you transition away from using Basic Auth. But we really want you to use this feature only if you really need Basic Auth. Not just because you think you might, or just in case. Customers are compromised through Basic Auth every day, and the best way to prevent that happening is to disable it and move to Modern Auth.
The exception process was outlined in an earlier blog post but here it is again, with specifics for ‘opt out’ requests.
You can now go directly to the Basic Auth self-help diagnostic by simply clicking on this link: Enable Basic Auth in EXO (it’ll bring up the diagnostic in the Microsoft 365 admin center if you’re the tenant admin). Or you can open the Microsoft 365 admin center and click the green Help and support button in the lower right hand corner of the screen.
When you click the button, you enter our self-help system. Here you can enter the magic phrase “Diag: Enable Basic Auth in EXO”.
Whichever path you took to get here, click Run Tests to check your tenant settings to see if we have disabled Basic Auth for any protocols, and then review the results. If we have not disabled Basic Auth for any protocols in your tenant, and you are running the diagnostic before September 1, 2022 (one month before the October 2022 start date), we’ll offer you the option to opt out.
Select the protocol to opt out from the dropdown, click the check box, and then click Update Settings. Repeat this process for each protocol to opt out.
That’s it. Once you submit your opt out request, we won’t disable Basic Auth for the selected protocol(s) in your tenant, whether there is usage or not, until October 2022. Every tenant can request an opt out for each protocol (or set of protocols in the case of Outlook), until the start of September 2022. Starting September 1, 2022, we will remove the opt out option, and starting October 1, 2022, we’ll begin turning off Basic Auth in all tenants, regardless of usage.
Note: Self service re-enablement of Basic Auth does not currently work for GCC tenants. For GCC tenants, please open a ticket with our support team to re-enable Basic Auth.
To reiterate, requesting an opt out for protocols you aren’t sure about, or just in case, puts your tenant data at risk. If you really aren’t sure, let us turn it off and wait to see what happens (or use Security Defaults or Conditional Access to do it today). You can always re-enable it for the time being using the opt out process, and while this might cause some disruption, the upside is it will help you identify the affected clients and apps, and the work you need to do prior to October 2022.
How do I know if my tenant is using Basic Auth?
Take a look at the Azure AD Sign-In log, as it can help identify ‘unexpected’ usage. We’re also going to start sending Message Center posts to tenant admins summarizing their usage (or lack of).
How will I know if this change will affect my tenant?
If the Azure AD Sign-In log shows Basic (legacy) Auth usage, this change will affect your tenant.
I thought you said you were not going to completely disable SMTP AUTH?
You’re right, we did, in blog posts here and here. We’re going to continue to disable SMTP AUTH for tenants who don’t use it, but we will not be changing the configuration of any tenant who does. We can’t tell though if the usage we see is valid or not, that’s down to you to determine. So you still should move away from using Basic and SMTP AUTH though if you can, as it does leave you exposed. Don’t forget, you can disable it at the tenant level, and re-enable on a per-user/account level as described here.
I can’t re-enable SMTP using this feature, but I can request an opt out – huh?
Well spotted! We didn’t build logic into the re-enablement tool for SMTP as you can already do that easily using PowerShell, but we wanted to make sure you could request an opt out for disabling of SMTP AUTH, so we included it here.
How can I get a longer exception? I still want to use Basic Auth after October 2022
We are not providing the ability to use Basic Auth after October 2022. You should ensure your dependency on Basic Auth in Exchange Online has been removed by that time.
What if I request an opt out, do the necessary work, and then want you to disable Basic Auth?
First of all, we’ll say well done, we appreciate you doing the work. Then, what we would advise would be to use Security Defaults or Conditional Access to block legacy auth. We might not get to your tenant right away, so better for you to take action and secure your tenant when you are ready, and then we’ll come back and disable it fully in time.
What if you’ve blocked some protocols, but I want to request an exception for others?
You won’t see the opt out dialog unless no protocols in your tenant are blocked. But that’s ok, as all you have to do is ‘re-enable’ that protocol (even though it’s not disabled at the time), and we’ll consider that an opt out request for it.
If I’ve set up Authentication Policies, or Conditional Access to block legacy auth, how will I know it’s safe to remove these and not re-open myself to the risks posed by Basic Auth?
Keep watching the Message Center in your tenant; we’ll send Message Center posts in advance of us making a change to your Basic Auth configuration, and again once we’ve made the change.
What are you doing with Application Access Policies? We’ve been trying to get our apps to use these to secure them more granularly, but with only 100 policies available, that’s impossible!
We know many of our larger customers are already working on migrating thousands of service principals to our modern APIs, and we’ve heard the feedback that the existing limits with the current Application Access Policies code which allow only 300 service principals (we've increased from 100 to 300) is not enough. We’re announcing today that we plan on supporting 10,000 or more of these assignments per tenant. We’ll have more news on this update soon, so don’t let this issue stop you; it’s time to start planning to migrate your Basic Auth and legacy API applications to Microsoft Graph and Modern Authentication.
While we’re on the subject of Application Access Policies, we also want to say that we are aligning our Application and Administrative access control models to allow the full flexibility of Role-Based Access Control to apply to service principals in Exchange Online. And we’re bringing a unified management experience for scoped application access to the Azure AD Identity portal where admin permission consents are managed today. More details will be announced soon!
We know many of you will be happy about this announcement, as shutting down Basic Auth access to Exchange Online is a very good thing from a security perspective. And we also know that many of our customers have been focusing on other problems over the past year, and this will mean they might need to do more work in this area to be ready on time. We hope that giving you 12 months’ notice will give you sufficient time to prepare.
The Exchange Online Team
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.