Basic Authentication and Exchange Online – September 2021 Update
Published Sep 23 2021 02:55 PM 1.1M 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.

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.

Proactive Protection Expansion

In 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: Sometime in second and third quarters of 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.

Limited Opt Out

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 don’t want us to take that action for any 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 button: (it’ll bring up the diagnostic in the Microsoft 365 admin center if you’re a tenant Global Admin):

DiagButtonBasicAuth.png

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.

 

The_Exchange_Team_0-1632432572284.png

The_Exchange_Team_2-1632432692361.png

When you click the button, you enter our self-help system. Here you can enter the magic phrase “Diag: Enable Basic Auth in EXO”:

The_Exchange_Team_3-1632432716629.png

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.

The_Exchange_Team_4-1632432739155.png

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.

 

The_Exchange_Team_5-1632432757422.png

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.

Frequently Asked Questions

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. Basic authentication (outside of SMTP) will be turned off for everyone in October 2022, including tenants who have previously opted out using our self-service tool.

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 about Office 365 operated by 21Vianet? Is that subject to this change too?
Yes it is, but the timeline is slightly different. We will turn off basic auth for all covered protocols on March 31st 2023. There will be no Proactive Protection Expansion as detailed above, but we will start to turn off basic auth for unused protocols during 2022.

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!

Summary

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

200 Comments
Brass Contributor

Thank you guys for going back to the hardline stance. This is fantastic news and gets my full support, keep it up Microsoft!

Iron Contributor

Peel this band-aid off already!

Steel Contributor

Awesome. Keep it up and don't back down!

Brass Contributor

How does this affect scanners and MFC devices using SMTP AUTH for scan to email?  Will they all fail come when this change goes live?

Brass Contributor

My question is also about MFC / MFP devices using SMTP for scan to email and how those should be managed.

Copper Contributor

.

Copper Contributor

Microsoft needs to keep this around to support legacy equipment like MFC, MFP and other such devices not designed for modern authentication.

Telling us to upgrade or buy new is not very eco friendly. 

We are not going to get rid of a piece of well working equipment just because Microsoft wants to be communist by dictating to what they think everyone should have or use.

 

 

Brass Contributor

@CISUPOORT  2FA/MFA is unrelated to disabling basic auth, disabling basic auth and moving to modern auth does not require you to use Microsoft's MFA. You can always use solutions like Duo, Okta and many others for alternative MFA solutions. 

 

@The_Exchange_Team Can you guys clarify your stance on SMTP AUTH? will you guys be disabling it effective October 1, 2022 as well?

"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."

 

Copper Contributor

.

Iron Contributor

@CISUPOORTThere are a lot of hacking methods that exploit how simple it is to run many combinations through basic authentication. Even if you implement modern authentication (sometimes called web authentication) and no other security controls, you protect your users from a variety of password attacks. In addition, additional login metadata is sent as part of your authentication, and authentication / risk decisions can be based on this.

 

As others have said, this paves the way for MFA, but that's a completely different topic.

Also, shared mailboxes work fine with MFA. Unless you had multiple people sharing a PASSWORD, in which case, you should stop doing that.

Copper Contributor

Cameron, Kdaylenhayes and groupsupport are correct we need to be crystal clear on this.

 

Please tell us you understand by doing this procedure you will disabling scan to email for every printer on the planet. That has nothing to do with security, it's an absolute requirement even for a lot of military based devices.

This seems insanely obvious but so does not asking admins to enter secret questions that we will have no idea of the answers in Windows 10 Pro setup so it must be specifically asked.

 

 

Iron Contributor

Only if those copiers are sending to recipients outside of your tenant do they need* to use SMTP Auth. Most of the time, a user walks up, scans something to themselves and then uses Outlook, etc to send along elsewhere if necessary.


If your MFC doesn't support modern auth, 2 of 3 scenarios in the article still apply: https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-dev...

e. * not "need", but easier.

Copper Contributor

Mike,

No offense but thats not a good answer, there are so many legitimate use cases for these types of services. I have no doubt they will force this because they dont understand what daily use cases are but that doesn't make it smart or the correct choice. When you have suits making these decisions with no understanding of what they actual mean in the field its always going to be this way.

What about website contact forms? Are you going to use the auth app to approve that account every time the token gets renewed?

I am sure there are many many more things I am not thinking of at the moment that will be affected.

In the end it probably wont matter, shills will shill and MS will just pull the trigger and after it shells everyone they will recant, re-enable, provide hack work arounds and on and on.

 

Iron Contributor

None taken! I'm commenting so that at least some percentage of the readers can go away with alternate solutions. I get that some are going to have heartburn over this - but TBF, this is like 10 years in the making...

A website contact form could just use a shared secret or cert with application permissions, no?

SMTP AUTH - As mentioned in Basic Authentication and Exchange Online – July Update - Microsoft Tech Community and Basic Authentication and Exchange Online – February 2021 Update - Microsoft Tech Community we will not be completely disabling SMTP AUTH for those customers that still want to use it. We will only be disabling it for tenants we don't see using it. We'll clarify that in the blog above shortly. Sorry for any confusion. 

Copper Contributor

@Mike Crowley 100% agree.  When we migrate new customers to Office 365 that have MFD, legacy applications/services, etc.. we have them route/relay through a connector on their Hybrid Exchange Server or other on-premises SMTP Relay service/appliance to Office 365.  It's a simple solution for those devices and apps that need to relay to users outside the org via Office 365, but can't or don't need to login into a mailbox or do SMTP Auth and I have yet to see a customer where this solution doesn't work. 

Copper Contributor

Hi Mike 

Yes I think something like that can be done as long as you dont mind being forced further in to Azure but even that currently has lots of confusion surrounding it. I am more bringing that up as another example, I am sure there are a lot more....

 

https://techcommunity.microsoft.com/t5/azure-active-directory-identity/update-your-applications-to-u...

 

 

The point is its always done in an inconsistent way not matter what the roll out is. How can you have this many resources at your disposal and still have things this whacked out? Is it really necessary to have a major change notification 10 times a week. Can anyone really keep up with 30k users things are just endlessly changing for no good reason other than to move things around and charge more? Why not just charge more for E3 if you are so worried about security rather than saying hey if you want security you need P2 blah blah blah. 
It been abundantly clear for a long time those making the decisions have no idea what it means to this in the trenches. Its just endless non sense.

Copper Contributor
HSI
There are many small firms that don't have those resources at their disposal. There are lots of use cases that are outside each of our point of view. That is also a work around that should not be needed.

Anyway its Friday have a good day!

@CISUPOORT - you can move to Modern Auth without requiring/enforcing MFA. Your creds in the first instance are used to get tokens, from them on, it's just about refreshing tokens for continued access. 

Copper Contributor

Basic auth is currently disabled in our tenant with an organizational level default Authentication Policy.:

 

Set-OrganizationConfig -DefaultAuthenticationPolicy <PolicyIdentity>

 

However, we have a small subset of accounts which still require basic auth for EWS and IMAP so we have a second Authentication Policy which allows basic auth over these protocols, and this policy is applied individually to these accounts. This works as described in this doc: Note that the authentication policies assigned to users take precedence over the default policy. To ...  

 

When Microsoft disables basic auth in Oct 2022, will that override and break the Authentication Policy-based exception we have applied to our small subset of accounts which still need basic auth over EWS and IMAP?

Microsoft

@JPogue Yes. After Oct 2022, Basic Auth will be disabled service-side.

Copper Contributor

Not an Exchange admin by trade (so I apologize if I'm way off base), but we have several PowerShell scripts that require connecting to Exchange Online for tasks other than managing mailboxes (M365 Group management, audit searches, legal holds, etc...).  Will the Exchange Online V2 PowerShell module be affected by this change?  It currently requires Basic Authentication to be useful.  When connecting from a client where Basic Auth is disabled I get this error:

 

WARNING: Please note that you can only use above 9 new EXO cmdlets (the one with *-EXO* naming pattern).You can't use other cmdlets as we couldn't establish a Remote PowerShell session as basic auth is disabled in your client machine. To enable Basic Auth, please check instruction here https://docs.microsoft.com/en-us/powershell/exchange/exchange-online-powershell-v2?view=exchange-ps#...

 

New-ExoPSSession : Create Powershell Session is failed using OAuth
At C:\Program Files\WindowsPowerShell\Modules\ExchangeOnlineManagement\2.0.4\netFramework\ExchangeOnlineManagement.psm1:475 char:30
+ ... PSSession = New-ExoPSSession -ExchangeEnvironmentName $ExchangeEnviro ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [New-ExoPSSession], Exception
+ FullyQualifiedErrorId : System.Exception,Microsoft.Exchange.Management.ExoPowershellSnapin.NewExoPSSession

Iron Contributor

@RyanWalkerare you referring to the client-side basic auth as discussed here?

 

https://www.stigviewer.com/stig/windows_10/2020-06-15/finding/V-63335

 

If so, this is not what this article is about. The ExchangeOnlineManagement powershell module works with modern authentication / "legacy authentication" disabled on the tenant.

Iron Contributor

Here we go again. We're a 4 fte company and I'm the Office 365 admin. The product is supposed to be ideal for small companies that do not have the resources to run their own server. No IT management knowledge required.

Almost every day I get at least one "major change update notification" from the message center pointing me to pages like this one. I have NO IDEA what this is about but it scares the hell out of me. Every month something changes on our desktop keeping us from our own core business. Please, please, Microsoft, make something like Office 365 Small Business Basic LTS. We do appreciate to have our documents synchronized across all our devices but for the rest.... The Office 2003 apps would do the job for us.

Copper Contributor

@Mike Crowley, yes that's the client-side setup I'm referring to.  I just saw that Basic Auth was being disabled and remember seeing the warning message that I referenced above almost every day when I run my scripts from the wrong client.  Wanted to make sure that Microsoft wasn't requiring mutually exclusive settings (the support documentation referenced in the warning message that I provided shows/requires the exact opposite of the article that you referenced).

Thanks!

Copper Contributor

@DoveFromAbove 

All these clients support modern authentication:

Google is also headed down this path, but they have frozen their timeline temporarily. 
Google Workspace Updates: Less secure app turn-off suspended until further notice (googleblog.com)

It's just matter of time. 

@The_Exchange_Team just in time, have you heard about this publication on Autodiscover and how easy it was to use autodiscover.com.anyTLD to phish for BASIC authentication?
I am not a sec expert but I hope that this measure will at least be one part of the puzzle. 

Steel Contributor

Wish the past dates had stuck, but I appreciate the hard stance once again!

 

Ironically once basic authentication is dead, we'll likely be re-enabling legacy protocols like IMAP/EAS on mailboxes to gives users more flexibility in 3rd party apps.  If basic auth is not functional, they have to use something that supports that protocol *with* Modern Authentication.  (e.g. Thunderbird currently supporting IMAP with OAuth 2.0)  If it supports it, great, they do their MFA and carry on. If it doesn't, it just doesn't work because basic auth is dead. Right now we selectively enable IMAP on mailboxes but block basic auth for specific users via Conditional Access, so the above will let us stay hands-off again while allowing these 3rd party apps.

@ajc196 All the protocols that use Basic Auth and that we are shutting off already support OAuth already - so keep the protocol, just fix up the auth if you can. 

Steel Contributor

@Greg Taylor - EXCHANGE Yep, we are aware but we have a web of CA policies still allowing basic auth for various sets of conditions/scenarios that are still being addressed across several services, so we're not "untangling" said mess just yet. Basic auth being disabled & legacy protocols on by default is our ultimate goal.

@ajc196 ok, not sure I entirely follow, but it sounds like you know what you need to do. So good luck. Make sure you follow the opt out steps above so we don't touch your tenant inadvertently between now and October 2022. 

Brass Contributor

@The_Exchange_Team We fully support turning off basic authentication!


But please let the Outlook team add support for modern authentication in Outlook with POP/IMAP.

Now this is not available, but this functionality is very much needed!

@ExchangeOnline If you have Outlook, why use POP/IMAP? 

 

There are no plans to add support for Modern Auth to Outlook. If you have Outlook, use MAPI/HTTP. 

Brass Contributor

@Greg Taylor - EXCHANGE For some mailboxes there is a security requirement to immediately dowload the messages using POP.


Modern Auth in Exchange Online is available for POP, why not allowing it to use with Outlook?
 

@ExchangeOnline Why does a 'security requirement' determine the protocol that has to be used? Why POP? Why not IMAP? or EWS? or MAPI? If this is an app, use EWS, or even better, REST/Graph. 

Brass Contributor

@Greg Taylor - EXCHANGE we are familiar with the alternatives, but as you know POP, by default, removes the downloaded messages from the server.

The consequence of forcing Modern Auth means that POP/IMAP on Exchange Online with Outlook cannot be used anymore, that would be very dissapointing.

 

Copper Contributor

The FAQs state that "the Azure AD Sign-In log" can inform an administrator if there are existing uses of Basic Auth in the tenant.  However, it does not indicate how you do that.  How do I do that?  Looking at the Azure AD Sign-in log, I don't see any obvious fields being reported that indicate if Basic Auth was used for the sign-in.

 

 

Steel Contributor

@Kevin_Hamilton Check the ”Client apps” kolumn in Sign-in logs and you can filter on Modern Authentication apps and not.

Copper Contributor

I run the office365 logins for a school. I'm not up with the lingo, so an idiots guide to this change would be good, to enable me to understand if I need to do anything to my school setup or if this will effect us in any way or not - will we notice any change?

Copper Contributor

If MAPI is going away how will the Outlook client connect?

Copper Contributor

Hello. Will this change affect also SharePoint online? I see in Azure Sign-in logs:

Application: Office 365 SharePoint Online

Client app: Other clients

If I understood correctly "other clients" is Legacy authentication client.

Copper Contributor

@Fenner42  - You are able to use Direct Send, or any other number of options. Microsoft is not holding security efforts because you are unable to learn technology.

 

Further -- If you actually read the article in its entirety, SMTP Auth is the exception.

Iron Contributor

>If MAPI is going away how will the Outlook client connect?

@Damon Villar 

 

1) IMAP is not MAPI

2) They aren't turning off MAPI or IMAP

3) They are turning off Basic / "Legacy" Authentication, but Exchange Online supports Modern Authentication for both IMAP and MAPI.
4) Most IMAP clients don't support Modern Auth. For example, Thunderbird does, but Outlook doesn't. However Outlook has no need to, since it it also supports (MAPI + Modern Authentication), which is a much more capable protocol.

Copper Contributor

In the article it states that MAPI is included in the list of protocols to be disabled. If this is the case than wouldn't full Outlook clients be effected by this? Should the Outlook client be using MapiHttp instead of just Mapi?

 

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.

Copper Contributor

With basic auth being disabled in 2022, will we still be able to use SMTP relay as mentioned in this article https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-dev... . We use this method with IIS 6 (couldn't find the MS article anymore so this one is the same) https://support.datasharp.uk.com/portal/en-gb/kb/articles/how-to-configure-iis-for-relay-with-office... 

Will this now not work with IIS 6 method once Basic Auth is turned off? What are our alternatives when the deadline hits?

Iron Contributor

@Damon Villar  No, this article does not discuss disabling any protocols. This article discusses disabling legacy authentication.

 

This concept has been the discussion of various Ehlo blog posts for the better part of a decade. Checkout some of these other articles:


https://duckduckgo.com/?q=%22modern+authentication%22+site%3Atechcommunity.microsoft.com%2Ft5%2Fexch...

Copper Contributor

What about unattended Powershell scripts (or other system services) that need authentication? 

Steel Contributor
Iron Contributor

@MichaelN645 If you previously used Send-MailMessage, you can move to Send-MgUserMessage. Shameless plug here: https://mikecrowley.us/2021/09/25/send-mgusermessage/

If you want to see how modern auth works with Thunderbird, check out Michel de Rooij's post here: https://eightwone.com/2020/07/01/configuring-exchange-account-with-imap-oauth2/
If you have more complex needs, check out Glen Scales' numerous, high-quality articles: https://gsexdev.blogspot.com/search?q=%22modern+auth%22

 

@QuiltersICT - as the first FAQ says, start here, or you wait for our MC posts to arrive. Start with the report would be my advice. 

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).

@Lyle_Epstein SMTP is not being turned off if it's being used in your tenant. Please read the blog and FAQ's again. 

 

@Damon Villar As @Mike Crowley said, we're not disabling any protocols, only specific auth types. They are not the same thing. MAPI(http, you are right, it's MAPI over HTTP, but we're just calling it MAPI in this case, but they are one and the same) is not being disabled. Basic Auth with MAPI is, but not OAuth. But yes, this change affects Outlook - but only if it is using Basic Auth with MAPI. 

 

 

 

Co-Authors
Version history
Last update:
‎Sep 01 2022 09:52 AM
Updated by: