Improving Security - Together
Published Sep 20 2019 07:00 AM 241K Views

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.

For many years, client apps have used Basic Authentication to connect to servers, services and endpoints. It is enabled by default on most servers and services and it’s super simple to set up. Basic Authentication simply means the application sends a username and password with every request (often stored or saved on the device).

Simplicity isn’t at all bad in itself, but Basic Authentication makes it easier for attackers armed with today’s tools and methods to capture users’ credentials (particularly if not TLS protected), which in turn increases the risk of credential re-use against other endpoints or services. Multi-factor authentication (MFA) isn’t easy to enable when you are using Basic Authentication and so all too often it isn’t used.

Simply put, there are better and more effective alternatives to authenticate users available today, and we are actively recommending to customers to adopt security strategies such as Zero Trust (i.e. Trust but Verify) or apply real time assessment policies when users and devices are accessing corporate information. This allows for intelligent decisions to be made about who is trying to access what from where on which device rather than simply trusting an authentication credential which could be a Bad Actor impersonating a user. 

With these threats and risks in mind, we’re taking steps to improve data security in Exchange Online.

What We’re Changing

Last year we announced we are turning off Basic Authentication for Exchange Web Services on October 13, 2020. Today, we are announcing we are also turning off Basic Authentication in Exchange Online for Exchange ActiveSync (EAS), POP, IMAP and Remote PowerShell at the same time – October 13, 2020.

We want your help in getting users to move away from apps that use Basic Authentication, to apps that use Modern Authentication. Modern Authentication (which is OAuth 2.0 token based auth) has many benefits and improvements that help mitigate the issues present in Basic Authentication. For example, OAuth access tokens have a limited usable lifetime and are specific to the applications and resources they are issued for so they can’t be re-used. Enabling and enforcing MFA is also very simple with Modern Auth.

Please note this change does not affect SMTP AUTH – we will continue supporting Basic Authentication for the time being.  There is a huge number of devices and appliances that use SMTP for sending mail, and so we’re not including SMTP in this change – though we are working on ways to further secure SMTP AUTH and we’ll share more on that in due course. Nor does this change affect Outlook for Windows or Mac assuming they are already configured and using Modern Auth (and they really should be).

How This Impacts You

This change might affect some of your users or apps, so we wanted to provide additional information to help you in identifying and deciding upon an action plan.

Remote PowerShell

Firstly, how does this impact your own tenant administration? You probably use Remote PowerShell (RPS) to access Exchange Online, hopefully with the MFA module. If so, you might also consider switching some of your day to day usage to using PowerShell within Azure Cloud Shell. We are also making significant investments in RPS to make the MFA module work better and we’ll be sharing some more information on that in due course.

Finding impacted users

The next action you really need to be thinking about is assessing client impact. The first question you probably have is – so how do I know who’s using Basic Authentication in my tenant? Great question, and soon we’ll make a report available to help you easily answer that question for yourself. It’s a report that provides tenant admins with a simple way to determine who is using Basic Auth so you, the admin, can see how large of a task you have on your hands.

Once you understand what your users use, and know if they are using Basic or Modern Authentication, what can you do about it? Each of the impacted protocols have options.  

POP and IMAP

So let’s talk about POP and IMAP. We know there’s still some usage out there, not much, but some. We’re planning on adding OAuth support to both POP and IMAP in the next few months. If you want to keep using these protocols, you’ll need to update the app to one that supports Modern Auth. Or better yet – get the user to use a more modern client (did you know we’ve added shared mailbox support to the Outlook app for iOS and Android? That’s one reason some people have been using POP and IMAP), or get the application developer to start using OAuth.

Exchange ActiveSync

The client app you might have the most usage with probably uses Exchange ActiveSync. There are many users out there with mobile devices set up with EAS. If they are using Basic Auth (and many of them are), now’s the time to do something about that. What are your choices?

Without doubt, we believe the best mobile device client to use when connecting to Exchange Online is Outlook mobile. Trusted by over 100M users across the world, Outlook mobile fully integrates Microsoft Enterprise Mobility + Security (EMS) enabling conditional access and app protection (MAM) capabilities. Outlook mobile helps you secure your users and your corporate data, and it natively supports Modern Authentication.

There are of course other email apps for mobile devices that support Modern Authentication too, so that’s another option.

For users that don’t want an app, or for users that have a device for which there is no app, they could switch to the browser on their mobile device. Outlook on the Web is used by millions of users every month, it’s feature-rich and we have a version ideal for mobile browsers. You can access it on a mobile device by navigating to https://outlook.office365.com. We’ll know it’s a mobile device you are using so we have a special experience just waiting for you. Go try it.

Summary

We know the change from Basic Auth to Modern Auth will potentially cause some disruption. For some users, any time they have to do something different, it’s challenging for them, but we want to do this together to improve security and protect your data and your users data. Disabling Basic Authentication and requiring Modern Authentication with MFA is one of the best things you can do to improve the security of data in your tenant, and that has to be a good thing.

The last thing to make clear - this change only affects Exchange Online, we are not changing anything in the Exchange Server on-premises products. We think turning off Basic Auth on-premises is a great idea too, by the way, and here’s something we published recently on that subject.

We know this is big news and we’re here to help. Please do leave us comments or questions and we’ll do our best to help.

The Exchange Team

140 Comments
Copper Contributor
Great news! Wish we could have gotten modern auth IMAP sooner though... But surely, isn't it possible to add OAuth2 to SMTP as well?
Copper Contributor

A bit disappointed at some of these changes to IMAP, particularly since I have yet to run across any non-interactive email program (i.e. for automated systems) that can use OAuth2.  Are there any plans to provide a workaround like per-application passwords, or manually re-enabling basic authentication on a per-account level?

Steel Contributor

At last! I’ve been looking for a forced move to more secure authentication. A lot of customers will not like this - but it has to be done.

I really hope that by this time you will also have support for using service principals or app based auth so that we still have the possibility of doing automation with Exchange online. 

Brass Contributor

finally!!! great initiative

At the same time ( or earlier) can we switch OFF pop3 smtp imap and exo PowerShell for newly created users please? (enabled by default currently)

As admins can always switch them ON, on an "as required" basis.

I believe this will have the biggest impact in security in ExO.

 

Copper Contributor

@SpartanWaycomau, you can disable POP3 and IMAP for new mailboxes by default by disabling it on the mailbox plan. 

 

Get-CASMailboxPlan -Filter {ImapEnabled -eq "true" -or PopEnabled -eq "true" } | set-CASMailboxPlan -ImapEnabled $false -PopEnabled $false
Brass Contributor

@Tony Federer thank you for that.

We've been disabling it in the user provisioning scripts for all our customers tenancies for 18 months....

My point is that it should be disabled by default, which is not.

Microsoft is making leaps and bounds in security, which is very refreshing, as we've been constantly drumming about these issues. Would be good to get this one done as well.

 

Thanks for all the comments so far. 

 

@NeedsCoffee  - we mentioned in the post we have plans for SMTP AUTH - we're working hard on those and will announce more when we're ready. 

@silverts and @Jan Ketil Skanke  - same answer as above. Yes, we have plans. Will announce what when we're ready. Work still to be done. 

@SpartanWaycomau - we agree and while this post is all about October next year we are going to be changing defaults for new customers sooner. We can't easily change something like this for existing customers like you without notice, that's part of our terms of service with you. But we do want new customers secure by default and we are considering turning off Basic for customers we know don't use it. We are also going to be sending tenant admins Message Center posts specific to their own tenant's usage. So look out for that. 

Brass Contributor

@Greg Taylor - EXCHANGE 

Understand and agree. Awesome you guys are doing this and taking into consideration . We all want both security and reputation being upheld. Thank you for listening and acting.

:thumbs_up:

 

Copper Contributor

Thanks for this post, @Greg Taylor - EXCHANGE. Do you have any further info on this KB article regarding disconnected mailboxes after enabling modern auth? This could cause us some problems in our organisation where the resolution of recreating the profile could be painful.

Hey @Michael Peebles  - the builds that contain the fix are in the KB, so the best advice is simply to make sure those are the builds you have deployed before enabling MA. 

Copper Contributor
1. https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Azure-Cloud-Shell-Now-Supports-Exchange-On... says "if you don’t touch the machine for more than 20 minutes (approx.) we will reclaim the session. We anticipate that the current timeout should work for most ad-hoc management scenarios but if you intend to execute long-running scripts then Cloud Shell is not the best tool for the job" How do we overcome this? What is the alternative solution for long-running scripts? 2. Will there be support for App password or Azure AD Application credentials in RPS?
Copper Contributor

So when will IMAP be included so can use GMail account without having to allow legacy clients

Copper Contributor

Thank you for the information and update. Have a query with regards to Skype for Business side changes if any (required) with respect to this change, as Lync.exe will interact with EWS/EXO regardless of the user placed over SfB On-Prem or Online if his exchange is Online. Pls let know. 

Copper Contributor

Hi, I have a query with f1 licence, the people that use this licence will use modern authentication? Or what mechanism will connect to exchange online?

  • Thanks.
Deleted
Not applicable

Please fix the sync frequency for Outlook for Android first.

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_outlook-mso_amobile-mso_o365b/set-sync-f...

 

I don't need the mobile Outlook notifications when I am sitting in the office and have the desktop Outlook open.

Copper Contributor

 

@silverts - yes, absolutely yes. We personally use an automated e-mail fetching system that integrates into our core business, we use IMAP with an app password for it and that breaking will leave us at a standstill, and it's not OUR app so it's not something we can code an update to. Being at the mercy of other app developers to update an (admittedly aging) app, before the deadline. Ouch.

 

@Greg Taylor - EXCHANGE - I know you said there is plans, but just reinforcing the fact that we need to allow an override for this to use an app password on a per-account basis or something, there's lots and lots of uses for IMAP/POP right now using basicauth, not just a little bit. Many businesses may be using an older application that will NOT get an update, and for them an immediate transition to a new app may not be an option for them, yet they've already fully committed to using Exchange Online, so this change effectively breaks their businesses. 

 

Copper Contributor

We use EAS only.  No access to OWA.

 

Whats the options with EAS with MDM?

Brass Contributor

(did you know we’ve added shared mailbox support to the Outlook app for iOS and Android? That’s one reason some people have been using POP and IMAP)

This hasn't actually hit GA yet and is limited to TestFlight participants only.  There hasn't been any info about what the hold-up is, but hopefully in the next few months we'll see it.  https://www.microsoft.com/en-us/microsoft-365/roadmap?featureid=32571

Copper Contributor
Will IMAP/POP's implementation of OAuth2 work with SAML-based IdP federation, or will it require ADFS?
Copper Contributor

While i like this in principal, as a manufacturing company this is going to be very disruptive.  When you have a bunch of physical tools/devices deployed that have very basic configuration options, and each tool costs millions of dollars, its a hard sell to management to get them to replace it.  I would like to second the app password/bypass for specific account approach that some others have already mentioned.

Brass Contributor

@Eric Watkins @CoryCTI

While I personally accept the argument, with all due respect, this is not solely an Exchange matter, it's an  Identity and Authentication one. I don't think this will happen anytime soon on a per-protocol or per-user basis.

As far as I know, you cannot selectively switch on or off MA at user level, but at the endpoint and organisation.

https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/enable-or-disable-mo...

Iron Contributor

Does this mean that App Passwords will no longer be usable on native Android mail / contacts / calendar app? 

 

If so, please make sure Outlook for Android can do complete, automatic, in the background, two-way sync with our contacts stored on Exchange Online, similar to the way it works with Outlook 2016/2019 for Windows Desktop. 

 

It is vital that we be able to update contacts on our mobile devices and have them sync to the cloud reliably and transparently, and that contacts modified on other mobile or desktop devices update on all devices.

@bhoobalan - we are working on a solution for scripts/automation. 

@anameihavetoenter - Don't understand your question. 

@Venkata_R - Lync client doesn't support Modern Auth afaik, but nor should it be trying to connect to EXO for any users which I assume are homed on-prem. 

@David Abad - F1 users can use OWA (this change has no impact on that), Outlook for iOS/Android and POP/IMAP. Outlook for iOS/Android already support Modern Auth and uses it already, so POP/IMAP are the two to think about - if you want to keep using them then you'll need to find a client that support POP/IMAP with OAuth. 

@CoreyCTI and @Eric Watkins - Sorry, but we're not adding app passwords for IMAP. We're providing 13 months notice of this change, you need to start reaching out to the developers of those apps. 

Gary Smith - there are plenty of solutions in the market - or you could try switch to Outlook mobile - it is a great client. 

@Philip Kluss - good point, thanks. Soon

@Jesse Thompson - it won't depend upon ADFS. 

@Steven Seligman - correct, no more app passwords. OAuth ftw. What you are asking for should already work in Android. Sync of contacts from your mailbox, to Outlook on your device, to your local contacts store - and vice versa.  

Brass Contributor

@Greg Taylor - EXCHANGE 

Good, solid, firm answer.

Love it. Something needed to be done and looks like you guys are doing it.

I think (and no doubt you ran the numbers in the impact assessment) 99% of organisations are going to be better off thanks to this.

Yes, there will be pain-points, but so has evolution.

 

Copper Contributor

@Greg Taylor - EXCHANGE  - Thank you for the reply and feedback. We have enabled MA support for SfB online (not directly related to this topic) and also we have implemented ADAL support as described here - https://docs.microsoft.com/en-us/skypeforbusiness/troubleshoot/hybrid-exchange-integration/allowadal..., however, we still see Lync.exe making EXO connects over Basic Auth as reported from the sign-in logs from Azure AD. Requesting to provide insights if there are any specific actions needed to support this cutover at EXO.

Brass Contributor

@The_Exchange_Team This are great news for optimizing the security of out O365 Tenants. 

@Greg Taylor - EXCHANGE , we have migration scenarios where the EXO IMAP Migration is not suitable and we have to do a similar IMAP Migration Method which is triggered from the customer on-prem service. Are there plans for this kind of o365 migrations to allow legacy IMAP Auth temporarly?

 

Hi, will also PST Export Tool support modern auth prompt with MFA?
Copper Contributor

@The_Exchange_Team

 

Can you clarify, for those of us with SMTP/IMAP apps today, what can we do right now to begin to test a new configuration and talk to app developers??

 

From what I've seen apps already support OAUTH flows for SMTP/IMAP to support gmail, but no support for O365 is present because MS hasn't enabled any protocols server side.

 

.. and splitting the delivery date of IMAP and SMTP enablement is going to be horrible. I think in practice app makers will wait until MS enables OAUTH on both before doing anything. A split configuration is just an awful user experience. Meaning we will probably only have a few months before the deadline when completed, released, software is available to migrate!! I hope MS can now seriously expedite delivering OAUTH on both protocols.

@Jason_Gunthorpe - we'll have some new on SMTP AUTH soon, so hold on a bit longer for that. We understand you need both, but given OAuth 2.0 and how we use it in O365 is well understood, it should be possible to begin contemplating what this change means, even if it can't be tested today. 

@Petr Vlk - no plans to do that. 

@jakobschaefer - are you referring to an IMAP migration into EXO, pulling from on-prem/somewhere else? I don't think this change impacts that, as the auth flow is in the opposite direction there. EXO is using Basic to authenticate to your remote IMAP target, you aren't using Basic to auth to EXO. I'll check though. 

Copper Contributor

@Greg Taylor - EXCHANGEcan you at least commit which standard Microsoft will follow in the implementation? Will MS be using Google's AUTH=XOAUTH2 scheme? RFC7628's AUTH=OAUTHBEARER? Something else?

Brass Contributor

@Greg Taylor - EXCHANGE: For Example: Right now we´re in a migration from a solution which only is accessible via IMAP. Unfortunately there are technical reasons why we can´t use the regular o365 imap migration which pulls the mails via imap to EXO. We have to make use of another tool (IMAPSync) which exports the mail via IMAP (with special settings) and pushs it into exo. In the future, when this security improvement in EXO is implemented, i couldnt use this or similar tools anymore, because IMAP supports no Modern Auth Methods.

Brass Contributor

@jakobschaefer 

As @Greg Taylor - EXCHANGE  pointed out, it appears that you're reading IMAP from a non ExO system for migration to 365... so not sure how auth changes will impact that, as it will be outbound from ExO auth to an IMAP system, not inbound to ExO

So @Greg Taylor - EXCHANGE, how to exactly export PST from eDiscovery after this enforcement? It downloads ClickOnce app to download results with the basic auth seems. Will it stops works also? If yes, we need some solution to export such data and build the hybrid for that is little bit unfortunately.

 

And other example is the recovery process. eDiscovery running couple of minutes, but Restore-RecoverableItems runs like hours or days to restore the same. 

Brass Contributor

@SpartanWaycomau , sorry, but no :). I read it from the non EXO via IMAP, "caching" the items, and then i connect to EXO via IMAP again to migrate the items into EXO. This is imapsync https://github.com/imapsync/imapsync it´s a very helpfull tool for handling easy imap migrations. But this is just an example for a IMAP Migration Method.

@Jason_Gunthorpe - we'll tell you as soon as we can.

@jakobschaefer - so you're using a system in the middle, pulling from the source, and pushing to O365? If so, then yes, that app/tool will need to add OAuth support. 

@Petr Vlk - I'll double check and come back. 

Steel Contributor

@The_Exchange_Team Does this mean that you also will (automatically) switch all old tenants Exchange Online configuration to use Modern Authentication from Basic Authentication? I mean all those tenants created many years ago that defaulted to Basic Authentication and tenant admins who never have bothered to change to Set-OrganizationConfig -OAuth2ClientProfileEnabled $true.

Jonas, we've been doing some of that already, and letting customers know via Message Center posts if their tenant is getting switched. It depends on whether those customers use Federated auth or not. If customers do not (they use just cloud identities or PTA or PHS etc.) then we're switching them. We're not switching those using Fed Auth yet. 

 

It's really important customers make this change, there are a lot of benefits - we're continuing to push for this in various ways. IT Pros like those reading this blog can help, let's get off Basic Auth. 

Steel Contributor

I agree. I do that for all customers even though they don't see the reason when I have the permissions to do it. But we have some customers who manage their own tenants and have more better things to do (according to them) and it's good to know their tenant will be switched whether they want or not - then I don't have to take that struggle :)

Brass Contributor

This may be a dumb question but will this affect MAPI??

 

Clarification within this article would be beneficial.

 

 

Brass Contributor

Can you give a timeframe on the reporting tool for basic auth? We'd like to get ahead of this, and are getting hit with credential harvesting on basic auth endpoints, like ActiveSync.

@Luke_Page - MAPI will not be affected - but that doesn't mean Outlook won't. Outlook uses MAPI and EWS (and OAB and AutoDiscover too of course), so if Outlook is still trying to use Basic then features that use EWS might be impacted. It's very important to get Outlook switched to Modern Auth therefore. 

 

@chrisbuesold - as the article said, soon. 

Brass Contributor

 

@Greg Taylor - EXCHANGE, cheers for that.

 

I'm guessing the case is the same with RPC?

 

 

Copper Contributor

I understand the importance of security.I agree with that in the future.
But the deadline is not realistic.


So, we strongly request the withdrawal of the deadline.

We are a tenant administrator for 70,000 accounts.
And because it's a university, they allow their own email clients.
We have 2,000 IMAP/POP users.

 

What do you say to end users when there is no email client that can connect to Exchnage Online using OAuth + IMAP?

 

Don't set termination until Exchange Online supports IMAP/POP with OAuth and some popular email clients support it!

Brass Contributor

@昇 谷村 

How many security incidents related to this weak authentication is your SOC or OPS team dealing with please?

If anything (not calculating the data and further identity theft actions), think about the expense of effort.

Someone older and wiser once taught me: risk=cost.

Some people like us, security and forensics, would love to keep the status quo, but we observe a code of conduct to do what is right. I suggest you start educating your users now. There's plenty of time.

I got some tenancy of 120,000 . Rule them before they rule you.

RC

Copper Contributor

I understand we should push app vendors to support OAuth, but like many people I have apps which use IMAP for mail flow.  JIRA is a good example, it is unlikely this will support Ouath.  What about printing devices which may not have firmware updates?  

 

Not having application/imap specific passwords is a significant limitation.  What is the logic behind that? Is it the implementation effort or is there real world data on the abuse of application specific passwords.  While there is risk of misuse/theft, most things are a trade off between security and usability.  Not having basic auth/app password support improves security, but I now I cannot use O365 mailboxes with a lot of systems.  Where an application vendor cannot update to support Oauth it means I need to setup an internal mail server, which seems a step backwards.  

 

"Sorry, but we're not adding app passwords for IMAP. We're providing 13 months notice of this change, you need to start reaching out to the developers of those apps. '     Given the impact of this change on your customers, it would be nice to have bit detail on why no app passwords.  13 months is not a long time in development cycles.

 

 

 

 

 

Copper Contributor

@rajeev_Kap, from what I have been able to understand it looks like Microsoft expects a server application like Jira to use the OAUTH client credentials grant using an app password to get the OAUTH token. (see here https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow). This seems to have a nicer enrollment and security flow in general, but is a big disruption.

 

It is also fairly unclear how this should be setup to allow the daemon/server account to access a mail box.

 

We really need some migration documentation from MS for common use cases, ie  a Jira server that needs to ingest and send email is a good use case to describe.

 

I also hope MS staff will contribute patches to some of these popular open source projects to make them work, or at least offer up some free Azure accounts to open source for testing integration.

@Luke Page - yes. 

@昇 谷村 - client apps are adding OAuth support to IMAP. I know of at least one. 

@rajeev_Kap - server apps really need to move to Graph and OAuth - not IMAP. Graph gives those apps all they need in terms of access to mailboxes. App passwords are Basic Auth, still subject to all the same issues Basic Auth is. 

@Jason_Gunthorpe Graph is the path, and work is underway to help app developers understand how to integrate Graph and OAuth into apps. 

 

https://developer.microsoft.com/en-us/graph/ 

 

Iron Contributor

@Greg Taylor - EXCHANGE- Can you comment on whether Samsung has committed to upgrading their native Contacts, Calendar, and Email apps for Android Pie and above, to conform with this Microsoft initiative by the October 2020 deadline?  If you don't know, do you have a Samsung resource that you can tap to try and find out?  You may be aware that Microsoft CEO Nadella participated in Samsung's unpacked event in August, and announced a strong integration initiative between the two companies going forward.

 

You previously replied to my question about robust two-way contact sync between O365/People and Android Outlook App with the following:  "What you are asking for should already work in Android. Sync of contacts from your mailbox, to Outlook on your device, to your local contacts store - and vice versa. "

 

I've been testing since your reply and have found many anomalies.

 

Thank you.

I can't comment on their timeline but I can tell you our dev teams are working together. 

Co-Authors
Version history
Last update:
‎Sep 01 2022 08:11 AM
Updated by: