Basic Authentication and Exchange Online – June 2021 Update

Published Jun 16 2021 01:08 PM 58.7K Views

Update: For latest information related to basic authentication in Exchange Online, please see Basic Authentication and Exchange Online – September 2021 Update.

It’s been a few months since our last update on Basic Authentication in Exchange Online, but we’ve been busy getting ready for the next phase of the process: turning off Basic Authentication for tenants that don’t use it, and therefore, don’t need it enabled.

We have millions of customers who have Basic Auth enabled in their tenant, but only use Modern Auth. Many of them don’t know Basic is enabled, and the risks that it presents – so we are going to do our bit to help secure their data by turning it off for them.

Over the last few months, we have been building the supporting process and tools we need to do that at scale, and now we’re ready to start rolling it out.

The Process

As we’ve said before, we’re only currently planning to turn off Basic Auth for those customers who are not using it. For customers that use still Basic for some or all the affected protocols*, we are not touching authentication settings for those protocols (for the time being).

(*as previously announced these are: Exchange Web Services (EWS), POP, IMAP, Exchange ActiveSync (EAS), Remote PowerShell (RPS) , Outlook (EWS + MAPI, RPC, and OAB) and SMTP AUTH)

We have been busy analyzing Basic Auth usage data for our customers and now have a solid understanding of who uses it and who does not. And we’re going to start turning it off for those who are not using it.

The process is: We’ll randomly select customers with no usage in any, or all affected protocols, send them a Message Center post informing them that in 30 days we’re going to turn off Basic Auth. 30 days later, we’ll turn it off and send another Message Center post to confirm it was done. Customer protected... check!

We’ve already done this for a pilot set of tenants so we feel good about how this works, but before we scale up we wanted to build a tool to help our customers just in case we get it wrong. Why would we get it wrong? Well, very low usage is hard to detect if connections are rare, and some customers might even suddenly start using Basic auth. On that note….

You should know that we can’t really tell if Basic auth usage is legitimate usage, or an account that has already been compromised – we just see this as someone logging in to the mailbox, and in this case will not disable the protocol. Now therefore is another great moment to plug the Azure AD Sign-In log, as it can help surface ‘unexpected’ usage.

What if we do not spot that new usage , and we disable Basic? What then? Well, that’s where a new tool we’ve been building comes in – a tool that provides self-service re-enablement.

We’ve built a new diagnostic into the Microsoft 365 admin center. You may have seen this before for things like EWS migration throttling, or you read this excellent recent post about it. These diagnostics have proven really popular with customers, so we simply built on that technology.

Self-Service Re-Enablement

If you want to re-enable a protocol that we have disabled for Basic Auth, or want to see what protocols we have disabled, open the Microsoft 365 admin center and click the small green ? symbol in the lower right hand corner of the screen.


Once you do that you enter the self-help system which, (in case you didn’t know) can use some very clever logic to help you find a solution to all kinds of problems. But if you want to get straight to the new Basic Auth self-help diagnostic simply enter the magic phrase “Diag: Enable Basic Auth in EXO”.

(Don’t tell anyone, this is our little secret. Published on one of the most popular blogs we’ve ever had at Microsoft. Shhh.)

Once you do that, you’ll see a page very similar to this:


Once you click Run Tests, the tool will check your tenant settings to see if we have disabled Basic Auth for any protocols, and then display the results.

If we have not disabled Basic Auth for any protocols we’ll tell you just that. But assuming we have done something, you’ll see a list of protocols that are disabled. My tenant has the full set of protocols disabled as you can see from the following:


Now that’s great, you can see what we did, but the best thing is, you can also re-enable the protocols yourself (if you want to). You can simply select the protocol (or a group of protocols, in the case of Outlook), check the box to agree to the warning (you know turning Basic Auth back on is bad right?) and then click Update Settings:


If you want to re-enable another protocol (again – why would you do that…?) re-run the diag and you can do just that.

That’s it – that’s how you can re-enable a protocol if we turn it off as part of this larger security effort. This is the only way to re-enable 8 of the 9 protocols included in the scope of this effort. (Up until the point at which we start to disable Basic Auth for protocols which are in-use – we are still planning on doing that and will have news on that later this year)

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.

The only protocol you cannot re-enable in this way is SMTP AUTH – that’s not a part of this diagnostic because there’s already a lot of diagnostic wizardry available to help you with SMTP AUTH, and you can already switch SMTP AUTH on and off yourself by using the Set-TransportConfig cmdlet. Because unlike the other 8, all we’re doing to disable Basic Auth for SMTP AUTH is set SmtpClientAuthenticationDisabled to $True for tenants, and you can just go right ahead and turn it back on (set to $False) if you subsequently decide you need and want to use it.

One other notable difference in behavior with SMTP AUTH compared to the others is that the switch for SMTP AUTH controls Basic and OAuth client submission, they are not individually switchable. You can still enforce the use of OAuth using Conditional Access, but it’s a little more involved than just on or off for Basic, you can read more about authenticated SMTP submission here.

So how are we controlling the use of Basic Auth for the other 8 protocols? Good question, so good in fact we added that to the list of other excellent questions you might have below.

Some Questions and Answers

Why do I need this diagnostic tool? Why can’t I just go look at the Authentication Policies in my tenant and disable/delete them if I do not want Basic disabled for any protocol?

Good question! We are not turning off Basic using Authentication Policies. Therefore, Authentication Policies setting has no effect on the way that we will disable (and you can re-enable) Basic Auth using this diagnostic.

I use Basic Auth still for <insert your device, third party app, home grown app, etc. here> and I do not want you to turn it off!!

As long as your app checks mail or does whatever it does pretty regularly, we’ll consider that ‘active usage’ and not touch the authentication settings for the protocol it uses for the time being.

How exactly is Microsoft turning Basic Auth on or off on a per-protocol level?

We’ve added a new org level parameter that can be set to turn Basic Auth on or off for individual protocols within a tenant. Admins can view the parameter (-BasicAuthBlockedApps) using Get-OrganizationConfig. It’s not something you can change, and the values we store in there aren’t very user friendly, but luckily Exchange Online knows how to read and enforce them. A value of Null there means we’ve not touched your tenant. A value other than Null means we have, and the diagnostic is the way to determine what is disabled there.

I just got the Message Center post but I know I have an app that still needs to use Basic Auth. Please do not turn it off, I don’t want to have to re-enable it.

We are looking to add ‘opt-out of Basic Auth disablement’ functionality to this diag quite soon so you can do just that. The idea is that once you get the Message Center post you can use the diag to say “please don’t disable basic auth for IMAP” for example. And we’ll respect that. However… we strongly encourage you to request an opt-out only for the protocols you know you need, and don’t just ask for them all. Leaving unused protocols enabled for Basic Auth is a huge security risk to your tenant and your data.

When is Microsoft going to start turning off Basic Auth for protocols that we are actively using?

As announced earlier this year we’ve paused that program for now, but it will be coming back, so make sure you keep an eye on the blog and the Message Center for that announcement and keep working to eliminate the need for Basic Auth in your environment!

The Exchange Team

Occasional Visitor

How does this jive with blocking Basic Auth with Authentication Policies (Set-AuthenticationPolicy) and blocking Basic Auth with Conditional Access Policies?

I have tenants that have already blocked Basic Auth with one of the above.

@mikerocode This is blocked an entirely different way as the blog says. And our way of doing it overrides all (sorry, the house always wins) other methods. We're also not looking to see what policies you might have, we're just looking at usage. So, if your usage is zero (perhaps because of your policies), we might go ahead and put this block in anyway. If you then were to remove your Auth Policies or CA polices, Basic will still be blocked. 


But aside from that, good job for already putting those blocks in. You win. 

Occasional Visitor

@Greg Taylor - EXCHANGE Makes sense and was actually the answer I was hoping for. Thanks for responding!


Thanks for the excellent post! I would just like to point out the following tiny typo in order to make this amazing post even more amazing!

Original: can already switch SMTP AUTH on and off yourself by using the Set-TransportConfig cmdlet. Because unlike the other 8, all we’re doing to disable Basic Auth for SMTP AUTH is Set- SmtpClientAuthenticationDisabled to $False for tenants...

Suggested: can already switch SMTP AUTH on and off yourself by using the Set-TransportConfig cmdlet. Because unlike the other 8, all we’re doing to disable Basic Auth for SMTP AUTH is set -SmtpClientAuthenticationDisabled to $False for tenants...


@The_Exchange_Team  @jettan - Thanks for providing an update to this touchy subject. Dare I ask whether there are any other improvements in the pipeline to help us identify and eliminate basic auth usage? In a large tenant, working with the sign in logs is still clunky. For example, the JSON export contains a lot of information that is lost when you import it into Excel. If the export is too large, the download of the JSON fails. Since the search result doesn't show how many entries will be downloaded, this turns into a hit and miss as to how many days can be included in one download to prevent a failed download.


The screenshots in one of the referenced pages shows a download limit of 250,000 records. In our tenant, this limit is 100,000. What can I do to do to get this increased?


Lastly, I usually struggle with double negatives, but doesn't -SmtpClientAuthenticationDisabled set to $False mean that you are enabling Basic Auth for SMTP AUTH for your tenant whereas the paragraph above states this is the cmdlet to disable it?


Occasional Visitor

How long does it take for the protocols to be enabled after running the diag tool?

What would happen if I were to retry enabling the protocol multiple times due to some error?


@jettan Thanks, fixed that!

@Kreera House Thanks - fixed the typo!

@Kreera House - good catch on the True/False switch - I too hate double negatives, and clearly they are too much for me sometimes. The 100 vs. 250k limit - let me look into that. Thanks for highlighting. 


@itzadeeb about an hour at the most. If you get an error trying to re-enable protocols and it doesn't sort itself out - open a support ticket. 



@Greg Taylor - EXCHANGE I'd like to second Kreera's comment about identifying basic auth users, specifically ActiveSync. It's very clunky and difficult to rationalize when you have 70k+ users with multiple devices.


It would be nice to get a report in the Message Center like MS has done in the past with other announcements.



Senior Member

Any ETA on removing Basic Authentication for the legacy Office 365 reporting services
Or on replacing it with something modern?

@Steven Johnson It's something we've been thinking about. If we were to send customized MC posts though they would only be able to tell you how many users are using Basic for each protocol, not the details of which users are using Basic. We don't have access to that kind of data (usernames). Would that still be useful? If you know which protocols have the most usage you could focus on those in the sign-in reports you have access to (which will show you the usernames). 


@dmbuk not yet, work in progress with no news to share at the moment. 

@Greg Taylor - EXCHANGE yes! That would be helpful. At minimum, we could compare with the numbers we're collecting via sign-in logs. Thanks for the reply!

@Steven Johnson great, ok. Let me think about that some more. It'll be the mother of all mail merges. 

Occasional Visitor

I confirm there is an issue with numbers of rows returned raised by @Kreera House .

"The 100 vs. 250k limit - let me look into that."
In my case only Exchange Active Sync Sign-in end up with 100k and this covers only 2 days...

Occasional Visitor

Update to my previous comment. Now it's clear. There is 'old experience' and 'new experience' at SignIns. In older interface it is written:
You can download up to 250,000 records. If you want to download more, use reporting APIs. Click here to learn more.
but in new experience, it's written:
You can download up to a maximum of 100,000 records per file (e.g. if you are downloading the interactive and non-interactive sign-ins files, you will get 100,000 rows for each file). If you want to download more, use our reporting APIs or export to a storage account, SIEM or Log Analytics through "Export Data Settings". Click here to learn more. 


@Slawomir_Lipski thanks for the follow up! That's correct - we generally recommend that customers use Azure Event Hubs, Azure Storage, or Azure Monitor to export and analyze large amounts of log data. 

Exporting sign-in logs data from Azure AD requires a premium license for your Azure AD tenant. You can use the following methods to export logs:

  • In general, we recommend customers prioritize data export to Azure Event Hubs, Azure Storage, or Azure Monitor. Those export pathways are all capable of handling the load even from customer tenants with hundreds of thousands of users. Stream Azure Active Directory logs to Azure Monitor logs | Microsoft Docs
  • Customers can also use Graph APIs to export sign in logs, but we recommend customers implement the recommended MS Graph paging logic to ensure they can pull all their logs. Access Azure AD logs with the Microsoft Graph API | Microsoft Docs
  • Customers can also download logs, but the amount of data in the sign in logs can cause browser timeouts for large customers. Currently, in browser downloads are limited to 100k events. 
Senior Member

Our organisation would gladly migrate it's email provisioning and mailbox management tools from using Basic Auth if we could get the OAuth2 method working effectively.  Our testing indicates that the remote PS we need to use is unworkable using the new connectivity method with certificate thumbprint owing to connection delays and possibly general slow response.  In many cases the connection delay for each action is up by an order of magnitude over basic auth.  This results in a terrible user experience and in most cases of complex / repeated actions, actual timeouts which break the processes.  We have heard (somewhere) that Graph API is being updated to have more  mailbox functionality added which will apparently work much better.  Hopefully when we see this it will allow functionality equivalent to PS get-mailbox, Get-MailboxStatistics, Get/Add/Remove-MailboxPermission etc? 


Does anyone have any indication of what the timeline is for either an improvement in connectivity speed for thumbprint connection or a  suitable extension to Graph API?

Occasional Visitor

We run the hybrid agent for onprem-to-o365. Is this something that is definitely going to affect us? 


@cball985 - no. It will affect any users whose mailboxes are in EXO, and who are using Basic Auth. The Agent itself doesn't use Basic Auth. 


@pmtelstra work in progress is all I can share at the moment. 

Occasional Visitor

Any update on sync-modernmailpublicfolder.ps1 script?

Occasional Contributor

Very good article, thank you! What happens to Tennants that are recreated in the future? Is the Basic Auth. automatically disabled there? If so, can you still activate it?

@krishraja - it's being worked on. 

@JanMartenHohnroth first off, thanks! Secondly, good question. New tenants get created with Security Defaults enabled already today - but we are making a change so that new tenants will also have Basic Auth disabled too - that should start happening in the next few months. 


Occasional Visitor

How does this affect Infopath? I think it might be using Basic Auth but surely there must be loads of people using it?

Occasional Visitor

If we wanted to disable Basic Auth for each of the protocols one-at-a-time before MS takes the steps, is there a cohesive primer for doing so?   Thanks.

Frequent Visitor

OMG I had a ticket open with Microsoft for over a MONTH because I could not get basic authentication to work for a script I needed. Then they finally showed me this article.   You would think they would know about it, and you would think that the other online tools that you can use to disable/enable basic authentication should maybe mention "Oh by the way check this place also other wise your settings here don't matter".   </rant>



Version history
Last update:
‎Sep 24 2021 07:44 AM
Updated by: