Update: The full timeline for retirement of Basic Authentication in Exchange Online is now published in Basic Authentication Deprecation in Exchange Online – September 2022 Update.
We previously announced we would begin to disable Basic Auth for five Exchange Online protocols in the second half of 2021. Due to the pandemic and the effect it has on priorities and work patterns, we are announcing some important changes to our plan to disable Basic Auth in Exchange Online. Please read this post carefully, as there’s a lot of detail.
The first change is that until further notice, we will not be disabling Basic Auth for any protocols that your tenant is using. When we resume this program, we will provide a minimum of twelve months notice before we block the use of Basic Auth on any protocol being used in your tenant.
We will continue with our plan to disable Basic Auth for protocols that your tenant is not using. Many customers don’t know that unneeded legacy protocols remain enabled in their tenant (Security Defaults takes care of this for newly created tenants now). We plan to disable Basic Auth for these unused protocols to prevent potential mis-use. We will do this based on examining recorded usage of these protocols by your tenant, and we will send Message Center posts providing 30 days notice of the change to your tenant. This work will begin in a few months.
The next change to the previously announced plan is that we are adding MAPI, RPC, and Offline Address Book (OAB) to the protocols included in this effort to further enhance data protection.
As clarified in previous blogs, Outlook depends upon Exchange Web Services (EWS) for core features; therefore, tenants using Basic Auth with Outlook must enable Modern Auth before Basic Auth for EWS is disabled. Outlook uses only one type of authentication for all connections to a mailbox, so including these protocols should not adversely affect you. If EWS has Basic Auth disabled, Outlook won’t use Basic Auth for any of the other protocols or endpoints it needs to access.
At this time, we are not including AutoDiscover, another protocol and endpoint used by Outlook. There are two reasons for this. First, AutoDiscover doesn’t provide access to user data; it only provides a pointer to the endpoint that the client should use to access data. Second, as long as a tenant has some EWS or Exchange ActiveSync (EAS) usage, AutoDiscover is necessary for client configuration. Once Basic Auth is disabled for the vast majority of tenants, we’ll consider disabling Basic Auth for AutoDiscover.
Finally, we are aligning our plans with those for SMTP AUTH. We had previously announced that we would begin to disable SMTP AUTH for newly created tenants (and have already done so), and that we would expand this to disable SMTP AUTH for tenants who do not use it. We are continuing to do that, but we will include SMTP AUTH in all future communications and Message Center posts to make it easier for you to track the overall plan.
In summary, we have postponed disabling Basic Auth for protocols in active use by your tenant until further notice, but we will continue to disable Basic Auth for any protocols you are not currently using. The overall scope of this change now covers EWS, EAS, POP, IMAP, Remote PowerShell, MAPI, RPC, SMTP AUTH and OAB.
We will publish a major change Message Center post to your tenant 30 days prior to disabling Basic Auth for any protocols in your tenant. Major changes also trigger email notifications. We will also publish a Message Center post when we have made the actual change.
If your tenant is using any of these protocols in the 30 days prior to us randomly selecting your tenant for potential inclusion, we won’t disable them. Should you find a Message Center post to the contrary, please let us know (details on how to let us know will be in the Message Center post) and we’ll exclude you from the change. You’ll be able to do this right up until we disable these protocols for good (at a future date).
If you aren’t sure if you are using Basic Auth with any of the impacted protocols you can use the Azure AD Sign-In Logs to look at usage in your tenant. Read more about that here.
We are building the capability to allow you to re-enable the protocols yourself via Support Central in the Microsoft 365 admin center. If you find yourself in this situation, you’ll be able to request help in the Microsoft 365 admin center, and we’ll allow you to re-enable these protocols until we disable them in the future.
The switch we use to disable Basic Auth for unused protocols is not available to tenant admins. You won’t see any changes or additions to your existing authentication policies (if you have any) and our change will take precedence over any policies you might have. We understand this might be a bit confusing, so we wanted to note it here.
We hope this change is good news for those of you who needed more time to complete a transition from Basic Auth.
The Exchange Team
I am disappointed that Microsoft is not taking a stronger stance against basic authentication and disabling it (excluding SMTP) outright. Microsoft should have given a firm disabling date and disabled it then. Covid 19 is not a valid reason to back down from doing the right thing.
For more then 2 years we are pushing vendors and our developers to move to more secure and modern authentication flows. We push by saying it's the whole industry is disabling it as it has a significant security risk. And now they will just see another excuse to postpone and this time it's "until further notice" :(
This is definitely not helping to ease the transition in my opinion.
@The_Exchange_Team thanks for the update!
When will Outlook support modern authentication for POP/IMAP for Exchange Online?
More information: Can't connect to Outlook with POP/IMAP and Modern authentication - Exchange | Microsoft Docs
As the others have said. We have worked for nearly two years to push our app developers both internal and external to modern auth. We've put in a tremendous amount of work and now Microsoft is backtracking on this. Yes, we can remove Legacy Auth for our own tenant, but we may now run into third party developers that won't make the leap. We've already encountered a few in our last group of accounts to convert.
Microsoft not disabling it implies consent to use and will result in third party developers avoiding the update. This is very disappointing news.
We're not stopping anyone from blocking Basic Auth to their tenant today. They can, and they should. Tenant admins can enable security defaults and it's done.
We're not backtracking, if anything, by increasing the number of protocols we're covering we're actually doing more in the long term. Timing is the biggest challenge, nothing more. We're lucky enough to have a lot of customers, and it's going to take them a while. We have to balance the security of the data and our customers ability to access it. It's their data after all.
@ExchangeOnline - Outlook will not add support for Modern Auth for POP and IMAP. If you are using Outlook, use MAPI/HTTP. If you can't, use OWA. Or use a third party client. Thunderbird supports OAuth for POP and IMAP.
Understood, Greg, but it takes bold moves by industry leaders like Microsoft to persuade vendors to move away from dangerous auth mechanisms.
Sure, you can disable Basic auth in Exchange Online with an authentication policy, but if a vendor only supports Basic auth, they'll tell you to turn it back on. They'll likely point back to this article saying that even Microsoft is not committed to removing it.
I think we proved we're being industry leaders and bold by taking this stand to begin with.
If you read this article and got the sense this showed a lack of commitment maybe I need to go back and add some more !'s. We're serious. We're adding more protocols that we previously had, and we're going to start turning off things customers don't know they left enabled. Then when we think enough customers are ready, we're counting down.
Not committed? I promise you we are, and if any vendor points a customer at this blog saying we're not, to the customer - drop me a line. grtaylor at the place I work.
In my opinion Its because of these announcements that vendors are continuing to delay their updates to Modern Auth and cause us to maintain exceptions and be at risk.
While with the right push those vendors would be doing the right thing and move. We have the capabilities to block it and we do so but we are not safe with those few exceptions still lingering around ...
@Greg Taylor - EXCHANGE 2 years in advance notice, and now 2 broken promises with no hard date for when you're going to disable basic authentication. No Microsoft is not being a leader, it's being simply being a follower. Commit to a change and do it, stop going halfway. Just to it.
@Greg Taylor - EXCHANGE Outlook POP/IMAP modern authentication for Exchange, Outlook.com, and Gmail but not for Exchange Online? Thunderbird.... I hope you are joking.
As we have a requirement for POP, this is really a HUGE disappointment.
@Tonino Bruno if you block Basic including 3P apps as you said, why are you not safe? Because some other tenant didn't? That's not how a multi-tenant service like ours works...
We block 3rd party apps and we block basic auth in EXO by default but we have to maintain a series of 3rd party apps in our tenant because the business needs them. We had great success with many vendors and internal developers but sadly there are many that take a lot of time to move and without a sense of urgency they will take another year to be ready.
During this time we need to mitigate the risks with conditional access policies, keep pressure on those vendors and have though discussions with our business. Instead we could be focussing on new innovations like VIVA instead ☺️
By when will it be possible to have more fine grained control to block certain legacy protocols using Azure Conditional Access?
We can only choose between EAS and others, correct? It would be useful to allow discovery protocol while blocking most other legacy protocols using Conditional access.
Whereas I normally harp on the @The_Exchange_Team and have griped in the comments of many announcements, ironically I like this announcement quite a bit. It's going to do a few things that many customers and partners will come to appreciate:
So, glad to see this one, and thanks. A current state on this grey area is something everyone will appreciate.
@The_Exchange_Team we are tried of Microsoft changing dates, same thing happened to us . when Microsoft changed the date the vendor will delay the process now we dont know . If we dont have date nothing will move. If you are working on Security, you have to be strict on time line. You know that user risk,sign in risk and many features will not work without enforcing. we are not happy with this change and all our work and preparation wasted.
@Greg Taylor - EXCHANGE Thanks for the update.
Is there any update on for patching WinRM client so that it is no longer necessary to enable WinRM basic authentication to send the Oauth header for the ExchangeOnline PS Module v2 commands?
Because of this continued issue, we have to make company wide changes to our insight manager policies for WinRM to allow basic authentication just for a couple of Exchange admins.
Is this even on MS roadmap? Is MS working of a solution to this issue?
@PeteMitch99 No, this is currently not on the roadmap. There are discussions about it, but nothing is currently committed.
It is best, though, to keep that separate from the subject at hand, because that particular problem is not related to the Basic auth disablement (as you pointed out, OAUTH is used to authenticate to the service in that scenario, it is a local machine requirement).
@Nino Bilic is there a UserVoice so that I can upvote @PeteMitch99 's comment on WINRMS. Huge pain for our org too.
@Nino Bilic thanks very much for the response. At least I know now!
The reason for raising it here is i don't think it is a totally separate issue. my limited understanding was the Exchange Powershell module v2 WinRM workaround was primary necessary to enable the use of the old commands which still used Exchange PowerShell while enabling modern auth for connection?
Other modules like AzureAD and the MSgraph new EXO commands seem to deal just fine without it. So I would infer its a problem caused by Modern Auth and not having full MS graph PowerShell commands for Exchange?
I assume it is going to be fixed at some point by either patching WinRM or moving all Exchange commands to MSgraph? I assume either is a big headache and can't be done overnight.
However, the point i was trying to make was that there isn't a great deal of visibility around what path MS is taking to solve the issue long term or what the timescales might be.
If you point me to another location that deals with this then I will happily copy this comment there!
@Sankarasubramanian Parameswaran - you have the ability to enforce Basic Auth in your tenant today, and have done for some considerable time. You don't need to wait for us to block Basic to stop it being used in your tenant, none of that work has gone to waste, far from it, your company is benefitting from it.
We're not turning off Basic for those companies who have chosen to still allow it. Yet. We will, but not just yet.
The link Nino shared is not totally the same as it predates the Powershell EXO v2 module so there wasn't an option to use Modern Auth then, - so i opened another below.
That is terrible news. As long as you let it be used, it will be used. Because other vendors will say "microsoft supports this, so it cannot be a bad practice". Very disappointing. By introducing basic auth to the internet you did a bad thing security wise, now you are doing even worse by not terminating it.
On some of the comments here saying this is bad, while it's understandable the desire to disable basic auth outright, there are issues for many developers moving away from it.
In particular EWS applications cannot always move to using OAuth because this requires full_access_as_app permission for an application in Azure AD and many IT policies will block this as it's granting an application full access to ALL mailboxes.
While Graph API is preferred and provides granular mailbox permissions, this is a lot of time and investment to migrate to Graph API, and it has a number of issues. It also isn't support on-prem, so developers have to maintain both an EWS and Graph API implementation to support both on-prem and online installations.
See Cannot segregate access by user mailboxes using EWS · Issue #5659 · microsoftgraph/microsoft-graph-d...
@tjmoore FYI, on February 5th, they announced support for EWS with the EXO Application Access Policies. This means your concern is now addressed and you can now narrow that permission down to mailboxes in a specific security group.
Probably good to note that there is a limit of 100 Application Access policies. Really hoping Microsoft will increase that. We have thousands of internal apps and given the nature of Application permissions, I see it becoming a problem very quickly.
@Jeremy Bradshaw - That's great news! It sounds like that would solve the immediate issue and customers can be assured they can roll out with OAuth without opening up wide access.
I'm not a fan of disabling basic SMTP AUTH via a kill switch. so many printers will be rendered completly useless. At least allow usage of:
Set-CASMailbox -Identity email@example.com -SmtpClientAuthenticationDisabled $false
else legacy devices won't be able to send emails.
@schmitch ,are you able to get away with Set-CasMailbox to set client SMTP submission disabled to true, on all the mailboxes except those where they need it, and then use Set-CasMailboxPlan to make it disabled = true for all new /newly migrated mailboxes?
I think that should let you NOT disable it at the tenant level while still having it disabled for mostly all mailboxes, including new ones going forward, but still enabled for the ones that truly need it.
@Jeremy Bradshawt hat is what we do/plan unfortunatly new tenants might need to ask support, to enable that option. we have customers with tons of xerox printers, which will probably never support xoauth2. we are also a company that develops software and we are planning to roll out msgraph and xoauth2 later this year in our software, so that they delay it a little bit, helps us testing it more, but it is a pain in the **bleep** for web applications that also runs on premise, because you either need to tell your customers to create an application by themself or you need to have some kind of proxy to have a static redirect uri.
We only plan to disable SMTP AUTH for customers not using it, and admins will be able to re-enable SMTP AUTH even after we have fully turned off all the others. We know there are many devices out there that cannot be updated. If we (or better yet, you, the admin) turn off SMTP AUTH at the tenant level, you can then re-enable at the user level for the long tail of devices that can only use Basic.
@Jeremy Bradshaw Are you able to disable SMTP Auth with Set-CASMailboxPlan? I just checked and this is not an option we have available in our tenant? PopEnabled & ImapEnabled exist but not the SMTP protocol, which would have been a nice addition indeed.
@Tonino Bruno I just checked and confirmed, nope I cannot. I was hoping, but not in a place to double check when I responded to @schmitch . But as @Greg Taylor - EXCHANGE stated, you can go about it from the opposite angle - disable at the tenant level, then only enable for the necessary accounts. So essentially the same result, but not using my hopeful suggestion:).
well, today unfortunately without any notice SMTP Auth was suddenly disabled on tenant level. despite using SMTP AUTH withing my tenant.
We didn't receive a major change Message Center 30 days prior. MC237741 was released on 4th of Feb and today is 25th
It's available on Set-CASMailbox (-SmtpClientAuthenticationDisabled). Does it not work as part of Set-CASMailboxPlan then?
@Ala_Aljundi - I very much doubt we did that. If you can DM me your tenant name I'll check into it.
Not part of CASMailboxPlan, but probably should be.
I was wondering if you could please tell me if a certain form of authentication is classed as basic and potentially should be replaced. I am currently developing an Outlook add-in that needs to save the emails and attachments of clients to our database. I've used the Microsoft document "Get attachments of an Outlook item from the server" that uses Office.context.mailbox.getCallbackTokenAsync and Office.context.mailbox.ewsUrl to get a valid token to pass to our API. The API then coding ExchangeService service = new ExchangeService, Credentials = new OAuthCredentials(request.AttachmentToken), Url = new Uri(request.EwsUrl). Is the above methodology classed as basic and needs updating?
I am very happy with microsoft.
@GreatOfficeAddins the info you provided shows EWS API using OAuth authentication and therefore no, it isn't using Basic. Not sure if you already would've received an answer elsewhere,but didn't see one here.
@Jeremy Bradshaw thank you for responding, that was the answer I was hoping for. Good to hear that I can still use the EWS API for awhile (hopefully years) as I tried to implement Microsoft Graph authentication in my Outlook add-in on desktop via MSAL, but the user experience wasn't great with all the Dialog boxes constantly popping up. I couldn't use SSO authentication either as my API is on a different domain to my web. I've also read on the Office-js github page there is a few issues with Office.context.auth.getAccessTokenAsync.
i have a user with multiple profiles on outlook
on multiple tenants
one of these tenants arent multifactor enabled
and the outllook always asking for password but the screen dont appear for the password
Our Offline Address Book (OAB) stopped updating for the on-prem user when they are working on Cached mode within outlook application from 18th Feb, but OAB is updating for online o365 users and on-prem users using online mode along with OWA.
Just wanted to know if this plan caused the issue?
We have on-prem Exchange server 2010.
Please advise, as it is affecting alot of users within our organization.
@Abhishekkumar1 - no, nothing to do with this. This is an on-prem issue as you said, something changed in your on-prem environment. Call support if you need help.
I've recently been granted a new Office 365 account with 2 factor authentication and have been trying to set it up with Thunderbird on Windows 10. Have been able to set up IMAP fine including logging in, downloading email and having Thunderbird granted access as a trusted app via the admin. However I'm having problems getting SMTP set up on the specified settings
smtp.office365.com Port: 587 Encryption method: TLS or STARTTLS
I assume you would prefer we use TLS as it's more secure. You don't say in the guidance.
In any case being unable to get SMTP configured even using the same account details and password that work for IMAP and having thunderbird approved as a trusted mail client, it still doesn't work. I guess you've done a proprietary hack for Outlook clients.
I asked why this was the case and on two separate occasions got back a response that amounted to:
"SMTP is a legacy protocol that is blocked by our enhanced security, and will soon be blocked by Microsoft in any event. If you would like more information on this, check out this link:
With a link to here.
I appreciate it's been a while since I completed my Masters thesis in email protocols, but this sounds rather like <removed by profanity filter />
Can you give me an answer why this appears to work seamlessly with Outlook but not with Open source email clients?
Is this the intended solution? https://answers.microsoft.com/en-us/msoffice/forum/msoffice_outlook-mso_other-msoversion_other/thund...
Be as technical as you like, but be accurate.
@siliconglen when you say "Outlook works seamlessly" are you saying you setup Outlook to use IMAP and SMTP against the same server settings and it works? If not, then FYI Outlook doesn't use IMAP and SMTP by default for Exchange accounts. But if so then please report back to confirm.
My assumption is that you didn't realize Outlook uses something other than IMAP/SMTP, and basic auth has been disabled for SMTP on either your account or your tenant, and that is why Thunderbird is having that issue.
I logged into exchange and granted access to Microsoft to modify the app settings. There being no way to inspect the settings I was assuming it was SMTP. I'm guessing now it's MAPI, but was concerned about the zero day exploits earlier in the year.
Mail collection via IMAP/TLS and OATH2 is fine. Does the admin need to go through the same process to enable SMTP the same as IMAP as there seems to be no way to request this? Since most of the rest of the world uses SMTP what's the way to set this up in the most secure way with exchange? You're really going to block SMTP?
Does this also mean that app passwords wil not work anymore to download mail and calendar in iOS?
Good that Basic Auth will be intact for now as there are issues with the Powershell EXO v2 modules (see https://techcommunity.microsoft.com/t5/exchange-team-blog/modern-auth-and-unattended-scripts-in-exch...). Hope they can fix things so we can say goodbye to basic auth.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.