Disabling Basic authentication in Exchange Online – Public Preview Now Available

Published Oct 17 2018 07:01 AM 50.4K Views

Several months ago we added a feature to the Microsoft 365 Roadmap which generated a lot of interest. The feature was named Disable Basic Authentication in Exchange Online using Authentication Policies and as the roadmap items stated - it provided the capability for an Admin to define protocols which should allow Basic Authentication. Why was that so interesting? Well as you probably know, Basic authentication in Exchange Online accepts a username and a password for client access requests and blocking Basic authentication can help protect your Exchange Online organization from brute force or password spray attacks. Lately there has been an increase in the occurrence of these types of attacks, and so we are accelerating our release of this feature as it helps prevent them. If your organization has no legacy email clients or doesn’t want to allow legacy email clients, you can use these new authentication policies in Exchange Online to disable Basic authentication requests. This forces all client access requests to use modern authentication, which will stop these attacks from impacting your organization. We are still working on some aspects of this feature, and we’ll highlight those for you here, but in response to the increase of attacks we are seeing, we want to make authentication policies available to you now, and are therefore rolling this out worldwide immediately. There is already an excellent article describing how this feature works and we strongly suggest you read, understand and follow the article before enabling this feature. There are three important caveats to this feature:

  • There is a lack of telemetry for tenant admins allowing them to report on which users are using Basic Auth (and with which protocol) and once a block is enabled, whether such traffic was blocked. In other words, we can’t really tell you how well the block is working.
  • A policy change can take up to 24 hours to take effect, unless the admin calls a cmdlet (such as Set-User) to ‘tickle’ each user. (Note that ‘tickling’ is a technical term, first used here). So the block might not kick in right away, and you might have to take some action if you want it to happen faster.
  • If a user’s identity has not been replicated to Azure AD/Exchange Online, they will not be blocked and so any request received by Exchange Online will be routed to the authoritative Security Token Service (STS) where it is likely to fail. This same behavior also means that any authentication requests for unknown users in a tenant (such as might happen during a password spray attack) will also be forwarded to the authoritative STS for the domain.
We had been holding back on moving from private to public preview primarily due the first two of these - a tenant admin could misconfigure something and not realize until it’s too late due to the lack of reporting and the delayed effect of policy change. However, given the increasing frequency of these types of attacks we would rather give you access to the capability, knowing you will all carefully read the documentation before configuring. We’ll continue to work on improving the feature set, but you don’t need to wait for us. We acknowledge that for large customers, tickling every user using Exchange Online PowerShell (which can be unreliable for long running scripts) is challenging, but again we feel the benefit outweighs the negatives at this stage. It’s in all our interests to prevent these types of attacks from compromising our data and users, and we hope you find these tools useful and helpful. Use them wisely! The Exchange Team

Not applicable
I'd love to do this, but am having a hard time thinking of any of my customers that would be positive they don't have anything using basic auth. I do however see this as potentially useful in securing *specific* accounts, such as VIPs or other types of accounts that we know to be using modern auth... though conditional access could also do this.

Either way, thanks for the article, its a tool I'll throw in the box!

Not applicable
This block takes place at EXO when enabled Mike, before the on-prem STS or AAD get a look at it - take a look at the supporting doc.
Not applicable
Aha, gotchya, thanks. This would mitigate attacks against users who ARE already using modern auth then. Attacks that might otherwise circumvent/never reach the conditional access, etc workflow.

I have actually seen on-prem ADFS servers inundated with password attempts that weren't blocked by the customers security because they are proxied from Microsoft.

Not applicable
I saw a separate announcement that Basic Auth will be removed from EXO in 2020. Doesn't the Windows10 basic mail client, SurfaceHub, and Skype for Business meeting room devices all use "Basic Auth"? Are there any plans for those?
Not applicable
John, we announced Basic will be removed from EWS - https://blogs.technet.microsoft.com/exchange/2018/07/03/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/
Not applicable
while I like the idea, in practicality, its pretty useless to try and block basic authentication. 99% of the Mobile applications don't support modern authentication. I would argue that at least 80% of all user mailboxes also have a phone attached so blocking modern authentication for some protocols but leaving ActiveSync open is about as good as locking the front door but leaving the back door unlocked.

Intelligent hackers are going to attack the obvious point..which is the activesync protocol.

Not applicable
That's not correct. Modern Authentication now is full supported by the native IOS and Android apps, so if you have modern devices you should be ok.

If you have older devices (like Android 4.0 ) you shouldn't be worried because they don't support TLS 1.2 and therefore no chances to connect to O365 in the near (super close) future.

Not applicable
Kudos to Christian, he's spot on. The point of this feature is to force use of MA capable clients - if your clients aren't MA capable - then then this will force those users to upgrade them or be cut off - and that's a good thing for security. They have options, and Outlook mobile for iOS/Android is the best of them.
Not applicable
IOS's native mail app has Modern Auth since 11. https://images.apple.com/business/resources/docs/Whats_New_in_iOS_11_for_Business.pdf

I don't think Android has a native mail app with Modern Auth, yet, and I don't know if it's planned either.

As Greg and Christian point out, Outlook Mobile is the best mobile mail app experience on both platforms and it's modern auth capable.

Not applicable
In a bit of an obvious result the only option required is AllowBasicAuthActiveSync. I have also left AllowBasicAuthLogExport on (true) as this is enabled by default and I assume there must be a reason for this.
Not applicable
iOS supports Modern Authentication however anyone we enable MFA for has to use an app password still when using the native mail app regardless of version of iOS on their iPhone or iPad.
Not applicable

Long term Android user. The closest to a build-in mail app would be Gmail which doesn't support Modern Auth.

I'm slowly disabling basic auth as to see which components are required. Turning it off completely stops Gmail from working. I'm waiting a few hours between turning each one off. These are the ones I still have enabled at the moment.


-AllowBasicAuthLogExport (Seems to be enabled by default so won't change)


-AllowBasicAuthWebServices (turned off but still testing)

I'll update the list later this week once I'm finished.

Not applicable
Is there any chance you can explain the difference between this method of blocking and this article "Azure AD Conditional Access support for blocking legacy auth "?


I appreciate your efforts to help clarify the "what might break" in the excellent article you linked to as well.

Not applicable
Nick, we see this feature as a benefit to federated auth deployments primarily. This means Exchange will stop those auth requests from being proxied back to your on-prem STS. Azure AD Conditional Access support for blocking legacy auth is something that kicks in after that flow has happened, so wouldn't be used if you used Auth Policies to block basic for Federated Auth users. But it would apply to cloud identity scenarios. Yes there is some overlap, and we will be rationalizing that a bit.

The scenario this really helps with is password spray for federated domains. With this in place those auth requests (for users we know about) don't get to your STS at all.

Not applicable
Is there any way to find out how many connections made through basic auth in EXO ? How do we find if any application support basic auth or modern Auth ? as if i create the new auth policy by default its block the basic auth for the all protocol.Each admin does not wanted to get impacted to their application with with policy.hence if you have better idea to find out which protocol need to be exempted from the basic auth before?
Not applicable
Wonder if you guys could comment on how these new controls interact with client certificate based authentication to EXO?
Not applicable
Brilliant news. This in combination with an Azure Conditional Access policy for 'blocked locations' (aka countries my organisation doesn't operate in,) should prove very effective for blocking malicious actors.
Not applicable
For Set-User, -WhatIf does not work when combined with -AuthenticationPolicy

The policy will apply, be careful.

Not applicable
Can someone confirm if the behavior of the Office client app version "Microsoft Office 365 ProPlus" behaves the same way as Office 2013 where we have to add the "EnableADAL" registry key for modern auth? Back in 2017, we attempted to enable Exchange modern auth and our users experienced a password prompt loop and was told that even though we had Outlook 2016, that the ProPlus software behaved like Outlook 2013, and we'd need to deploy that registry key for modern auth to work.
Not applicable
Is there a way to connect to exchange online powershell other than basic authentication? Our company has disabled basic authentication for Windows 10 systems via GPO as part of the hardening policy and as a direct result I have to use a Windows 7 VM for my powershell work with Office 365. I haven't tried lately however the only value for -Authentication I was able to use successfully with New-PSSession was -Authentication Basic
Not applicable
Hi Greg,

Do you have this switch in your authentication policy set to true?


We use both modern and basic for specific modules to call:

Import-Module MsOnline

Connect-MsolService -Credential $credential

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid/" -Credential $cred -Authentication Basic -AllowRedirection

Import-PSSession $session

Not applicable
Hi Kerry,

We don't have an authenticationpolicy created at this time, get-authenticationpolicy returns no data. We are blocking basic authentication at the OS level for Windows 10 computers by setting Allow basic authenication to disabled in the GPO Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service.

Here is what I use to connect to Exchange Online via powershell:

Import-Module MSOnline

$O365Cred = Get-Credential

$O365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection

Import-PSSession $O365Session

Connect-MsolService –Credential $O365Cred

Connect-AzureAD –Credential $O365Cred


Not applicable
Hey Geoff,

We had a similar scenario and found that we needed to use the EXO PS module. It allowed us to have MFA w/modern auth as we are disabling basic auth from our federation point to O365.


Hope that helps.

Not applicable
I'm wondering what happens with "machines" like network printers when you do things like "scan to email". I'd like to do my whole tenant but am trying to figure out what other things might "break".
Not applicable
Those devices usually authenticate using SMTP (if you set them up to authenticate at all). So if you need to with this new authentication policy allowing us to enable/disable basic authentication per protocol you could probably set it up to allow basic authentication for SMTP on the specific mailbox(es) that the printers authenticate with and then disable it on your tenant.
Not applicable
Let's consider this scenario: Scanners/copiers are set to relay through an internal relay server. The authentication is anonymous however the ability to relay is restricted by maintaining the relay restrictions list and having it set so that only IP addresses in the list are allowed to relay through the internal relay server. There is a mail flow connector in place from the internal relay server to Office 365 and secured via TLS.

Since it's anonymous and not using basic authentication, I would hope that this scenario would not be affected by disabling basic authentication, right?

Not applicable
Hi everyone, just spent the last couple of days going through the documentation and implementing this.

I found multiple errors in the Powershell commands which held me up drastically. Here is what I ended up with, hopefully it will help others:

Create the authentication policy:

Set-AuthenticationPolicy -Identity "Block Basic Auth for Imap4/Pop3/Outlook Service(win10 apps)" -AllowBasicAuthActiveSync -AllowBasicAuthAutodiscover -AllowBasicAuthImap:$false -AllowBasicAuthMapi -AllowBasicAuthOfflineAddressBook -AllowBasicAuthOutlookService:$false -AllowBasicAuthPop:$false -AllowBasicAuthReportingWebServices -AllowBasicAuthRest -AllowBasicAuthRpc -AllowBasicAuthSmtp -AllowBasicAuthWebServices -AllowBasicAuthPowerShell

Configure the default authentication policy:

Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Basic Auth for Imap4/Pop3/Outlook Service(win10 apps)"

Assign the authentication policy to users

Individual user accounts:

Set-User -Identity user@domain.com -AuthenticationPolicy "Block Basic Auth for Imap4/Pop3/Outlook Service(win10 apps)"

All user accounts (my own creation with Andy Davids powershell brain help):

$Users = Get-User -ResultSize unlimited

$users =$users.WindowsEmailAddress

$users | %{Set-User -Identity $_ -AuthenticationPolicy "Block Basic Auth for Imap4/Pop3/Outlook Service(win10 apps)"}

Immediately apply the authentication policy to users within 30 minutes (despite other websites saying it's only 24 hrs):

Individual user accounts:

Set-User -Identity user@domain.com -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

All user accounts (my own creation with Andy Davids powershell brain help):

$Users = Get-User -ResultSize unlimited

$users =$users.WindowsEmailAddress

$users | %{Set-User -Identity $_ -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)}

Note: The very last command underlined above to immediately apply to all users threw some weird errors for every user as it went through but it did change the -STSRefreshTokensValidFrom on each user so I think it worked.

To check it had assigned to users and was visible I ran this against few users:

Get-User -Identity "Display Name" | Format-List

Look through the output to find these entries:

AuthenticationPolicy : Block Basic Auth for Imap4/Pop3/Outlook Service(win10 apps)

StsRefreshTokensValidFrom : 23/10/2018 14:04:47

Next thing to do is work out how to see it actually working.....should be fun!!

Not applicable
Let's say I want to block POP and IMAP.

What is the difference between creating Authentication policy and using Set-CASMailbox to disable protocols.

Not applicable
Hi Greg Taylor,

We are validating basic authentication block policy and found after block all protocol iPhone native mail client is not working. We have to enable active sync and autodiscover protocol to work native client. Could you please let me know do you have same understanding or anyone in this forum has any comments.

Not applicable
Any news on plans for which users are using Basic Auth (and with which protocol)? I don't see it possible to disable this until we have some reports.
Not applicable
You can see which users are in which policy, so you'll know who can use what:

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Get-User | Format-Table DisplayName, AuthenticationPolicy, Sts*

But determining specific protocol use is another matter. For that, you have to do some divining from the ADD Sign-in logs, which should be done before implementing policies.

What I'd like to know is once the policy has been applied company-wide in a non-hybrid environment (pure Office 365), and is in effect (more than enough time has passed and/or tickling has occurred), is it expected that bogus login attempts (and subsequent lockouts) from foreign climes against Exchange Online--a very common problem--should come to a halt or not? Some people say yes, it stopped them completely, but I'm seeing no change, they keep hammering away, and I don't know why.

Not applicable
"There is a lack of telemetry for tenant admins allowing them to report on which users are using Basic Auth"

Has there been any changes since, or any other routes, which would permit tracking basic auth usage across a tenant?

Not applicable
What happened to "AllowBasicAuthRest" attribute ?

Back in December it was editable, now it is not recognized by any of the commandlets.

Occasional Contributor

We use MDM with EAS.  Disable OWA across the board. 

Are we screwed? 

Occasional Visitor

Are these options to block basic authentication resulting in anything different then setting up a conditional access policy that blocks "other clients (imap,pop)"?

New Contributor

I am also asking what happened to AllowBasicAuthRest? it is not available in new or set-authenticationpolicy.

Version history
Last update:
‎Jul 01 2019 04:34 PM
Updated by: