When accessing Exchange Online from a client like Outlook or ActiveSync, clients have traditionally used Basic Authentication (also known as Legacy Authentication). You will have seen this in action if you’ve performed migrations to Exchange Online with clients like Outlook 2010, and a native password dialogue like this is shown to the user after the migration completes.

Blocking Basic Authenction native password dialogue box

The reason for this is because authenticating to Exchange Online can work in the same way as external users authenticate to an Exchange On-Premises infrastructure. This means it’s easier for older clients as they just see Office 365 and Exchange Online as another Exchange Server. However, it’s not as good when it comes to true single sign-on and security.

Modern Authentication was introduced to Exchange Online around four years ago and has been the default for clients such as Outlook 2016 since launch, and is used by the wider Office suite, including Outlook Mobile, Microsoft Teams and OneDrive for Business. Modern Authentication uses web-based sign via OAuth in allowing full single sign on, and rich multi-factor authentication processes.

In most cases, authentication prompts from clients like Outlook become non-existent. When they do occur, they look very different from the Basic Authentication prompt used with older versions of Outlook.

Basic Authentication prompt with older version of Outlook

What’s the problem with Basic Authentication?

Using Basic Authentication means you don’t get support for true Single Sign-On, but even if you are using Modern Authentication to access Office 365 and leave Basic Authentication enabled as a back-up you may wish to disable it for security reasons.

Today it’s necessary for many organizations to utilize Multi-Factor Authentication to protect accounts. Basic Authentication doesn’t support this, and instead the solution is to use App Passwords. App Passwords are simply a long password used instead of Multi-Factor Authentication and can be used to by-pass it. The security issues associated with Basic Authentication especially when an organization believes it’s locked down by MFA are well documented in the computing press and have resulted in data and monetary losses.

Even if you don’t have MFA enabled today and don’t wish to enable it, then you may wish to disable Basic Authentication due to the proliferation of password spray attacks. Because Basic Authentication uses simple HTTP login methods, rather than more complex OAuth-based authentication mechanisms, it’s much easier for a potential attacker to target a service like Exchange Web Services with a script or tool to attempt to guess user or admin passwords.

Should you use Azure AD Premium Conditional Access instead?

Conditional Access is part of Azure AD Premium Plan 1, which you will usually buy as part of Microsoft 365 E3 or EMS E3 licensing alongside Office 365 E3 plans.

Conditional Access allows you to define who, from what device and from where people can log into different Azure AD secured services like Office 365.

You may for example, allow user access to Yammer from anywhere, but only allow Exchange Online, OneDrive, SharePoint and Teams access from within Office locations.

You might allow external access to all your Office 365 services, but ensure that Multi-Factor Authentication is used, and access is only allowed from enrolled or domain-joined devices.

Because Conditional Access relies upon Modern Authentication to enforce policies, it provides the ability to switch off authentication using Basic Authentication. This applies not only to Exchange Online, but also to other services, like SharePoint, too. This will provide the same result, although configuring it in Exchange Online denies the request before authentication to the back-end provider occurs, rather than after.

If you don’t have Azure AD Premium or are choosing to use other methods – like AD FS – for enforcing conditions for access, then you will most likely wish to block Basic Authentication at Exchange Online.

New Policies in Exchange Online

This October, Microsoft released Authentication Policies in Exchange Online. Authentication Policies allow you to define which services block and allow Basic Authentication. You can switch on and off policies for these services:

  • ActiveSync
  • Autodiscover
  • IMAP and POP3
  • SMTP
  • MAPI HTTP
  • RPC over HTTP (Outlook Anywhere)
  • Exchange Web Services
  • REST API Access
  • Offline Address Book
  • Reporting Services
  • Outlook Service, used by Windows 10’s Mail and Calendar App
  • PowerShell

In the example below, we’ll define two policies to block Basic Authentication.

  • Block All Basic Authentication. We’ll apply this policy to a test user, and then apply to additional users until we are happy this should be the default.
  • Block IMAP, POP3 and SMTP submission using Basic Authentication. We’ll set this as the default policy for our tenant, as in our example organization, we know we have no users who should use these protocols.

Creating a policy and applying it to a user

We’ll create our first policy that blocks all basic authentication. This is straightforward, as we’re able to create a new authentication policy without any settings, because by default a new policy will block basic authentication for all protocols. We’ll use the New-AuthenticationPolicy cmdlet to create the policy. Once created, the Set-User cmdlet is used to assign it.

We’ll apply this to our test user, using syntax as shown below:

New-AuthenticationPolicy -Name "Block Basic Authentication"
Set-User -Identity "steve@goodmanuk.com" -AuthenticationPolicy "Block Basic Authentication"

Creating a policy and applying it as the organization default

Our second example will be used to block IMAP, POP3 and SMTP. We’ll use the same syntax to create a policy, and then use the Set-AuthenticationPolicy to selectively re-enable Basic Authentication for protocols other than IMAP, POP3 and SMTP.

New-AuthenticationPolicy -Name "Block Basic Auth - IMAP POP3 and SMTP"
Set-AuthenticationPolicy -Identity "Block Basic Auth - IMAP POP3 and SMTP" `
    -AllowBasicAuthWebServices -AllowBasicAuthOutlookService `
    -AllowBasicAuthReportingWebServices -AllowBasicAuthActiveSync `
    -AllowBasicAuthRest -AllowBasicAuthPowershell -AllowBasicAuthMapi `
    -AllowBasicAuthOfflineAddressBook -AllowBasicAuthAutodiscover `
    -AllowBasicAuthRpc 

We can check that worked, by using the Get-AuthenticationPolicy cmdlet. If we filter on AllowBasicAuth* we will see which services have Basic Authentication enabled with this policy:

Get-AuthenticationPolicy -Identity "Block Basic Auth - IMAP POP3 and SMTP" | fl AllowBasicAuth*


AllowBasicAuthActiveSync           : True
AllowBasicAuthAutodiscover         : True
AllowBasicAuthImap                 : False
AllowBasicAuthLogExport            : True
AllowBasicAuthMapi                 : True
AllowBasicAuthOfflineAddressBook   : True
AllowBasicAuthOutlookService       : True
AllowBasicAuthPop                  : False
AllowBasicAuthReportingWebServices : True
AllowBasicAuthRest                 : True
AllowBasicAuthRpc                  : True
AllowBasicAuthSmtp                 : False
AllowBasicAuthWebServices          : True
AllowBasicAuthPowershell           : True 

If we are happy that this will be the default configuration for all users who do not have an Authentication Policy assigned, then we can use the Set-OrganizationConfig cmdlet to set the default policy for all users within the organization:

Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Basic Auth - IMAP POP3 and SMTP"

A word of caution

As there’s not any reporting available today to understand whether your users are using clients that support Modern Authentication, nor reporting on which clients are currently using Modern Authentication, enabling Authentication Policies could have undesired effects, such as calls from users no longer able to connect. Therefore, ensure you read Microsoft’s guidance on Authentication Policies to ensure you have supported clients, and use a thorough testing process before mass rollout where there is uncertainty.

Summary

You can use Authentication Policies in Exchange Online to block Basic Authentication to your Exchange Online tenant. This is an excellent change as it doesn’t require additional Azure AD Premium licensing to take advantage of, so is extremely useful for organizations using the core Office 365 licensing.

About the Author

Steve Goodman

Chief Editor for Audio and Video Content and Technology Writer for Practical 365, focused on Microsoft 365. A nine-time Microsoft MVP, author of several Exchange Server books and regular conference speaker, including at Microsoft conferences including Ignite, TechEd and Future Decoded. Steve has worked with Microsoft technology for over 20 years beginning and has been writing about Exchange and the earliest iterations of Office 365 since its inception. Steve helps customers plan their digital transformation journey and gets hands on with Microsoft Teams, Exchange and Identity projects.

Comments

  1. Pete

    Hello quick question, for a customer that has a tenant prior to authentication policies being a thing therefore the tenant had no authentication policy, when creating a new authentication policy and making it the default policy for the organization, is it expected that users authentication policy is still listed as “null” ?

    1. Tony Redmond

      If an account doesn’t have an authentication policy assigned, Exchange uses the default policy for the organization (the one managed through the Microsoft 365 admin center). If you want to assign a non-default policy to accounts, you need to run the Set-User cmdlet to do this, and remember to do so to assign the policy to new accounts after creation.

  2. chabi

    If I block basic authentication in exchange online, will the azure ad sign-in log?
    Will exchange online implement user blocking due to brute force attacks?
    Or, Is the user not locked?

  3. Winston

    Hi, I ran into an issue.

    Step 1
    Get-CASMailbox -identity | fl Name,OwaEnabled,MapiEnabled,EwsEnabled,ActiveSyncEnabled,PopEnabled,ImapEnabled

    Showed that all 6 are True, so next

    Step 2
    New-AuthenticationPolicy -Name “Disable all BasicAuth”

    Step 3
    Get-AuthenticationPolicy -Identity “Disable all BasicAuth”

    It showed all to false

    Step 4
    Set-User -Identity -AuthenticationPolicy “Disable all BasicAuth”

    Step 5
    Set-User -Identity -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

    Step 6
    Get-User -Identity | fl auth*

    Result
    AuthenticationPolicy : Disable all BasicAuth

    Last Step

    Get-CASMailbox -identity | fl Name,OwaEnabled,MapiEnabled,EwsEnabled,ActiveSyncEnabled,PopEnabled,ImapEnable

    It still shows as True, any thoughts

    1. Nezgar

      This is because the authentication policy only disables Basic Auth for the protocols, the protocols themselves are not disabled. You could still auth with Modern Auth. The CasMailbox attributes disable the protocol entirely.

  4. Alex Moss

    Hi Steve
    Great article, I am sure you will be getting lots of hits on this now that is being enforced in October this year. The Feb update we just received suggested this can now be reported on it which will really help seeing what admin’s are up against. https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-auth-and-exchange-online-february-2020-update/ba-p/1191282

    This will also help identify older clients prior to Outlook 2013 that will not support modern authentication.
    Thanks Alex

  5. Manento Kitururu

    Hi Steve

    We are using Exchange2016 and all our client PC are connected to the DOAMIN…We still have this problem when users connect to outlook it prompts for the password..Could you please assist me on this,how do i get a permanent solution?

    Regards,
    Manento.

  6. NYer

    Hi

    Thanks; but you are missing a HUGE piece of the puzzle.

    How about the fact that legacy clients are not IP location aware? Clients that use basic authentication are NOT IP aware so using method above simply turns off basic authentication for everybody inside and outside. So if you have users inside the network that have outlook 2010/2013 then they won’t be able to connect even if you do IP exclusions!!!

    How do you block basic authentication ONLY externally as I had mentioned before; you can’t do it with Azure Conditional access or above method?

    1. Ted

      Add reg keys to support modern auth for Office 2013

  7. Chris

    Hi Rick
    Just to confirm ActiveSync depends on Basic Authentication and if we turn that off we must recreate the mail profile?
    Is Microsoft moving away from Basic Authentication completely?

    Thanks!

  8. Mark Wilson

    As Rick already mentioned, I am confused here with the EXO PowerShell cmdlets. I’ve seen a few blog posts claiming that Basic auth is not required any more, in the context of using MFA. I don’t have MFA enabled and when I attempt to use either Connect IPPSSession or Connect-EXOPSSession then I find I get the WinRM Basic auth is not enabled error (it’s locked down by GPO in my environment) – leading me to believe it is still attempting to use Basic auth even though I appear to have done the modern auth dance with the popup…

  9. Patrick Harrington

    Steve, great article. Just a heads up to those planning on doing a more restrictive policy that this may clobber iPhone native mail for a lot of users. We noticed that despite modern authentication being turned on for almost a year. Some user’s devices still held on to the Basic authentication profile when transitioning from one phone to the next. With no reporting on which devices are actually using OAUTH vs. Basic, it’s critical to take a measured approach when implementing. The painful fix for this is to delete the IOS native exchange profile and recreate it.

    1. Rick

      Good to know. And from what I’ve found, you need iOS 11.3.1 (or higher).

      Mail in macOS is apparently 10.14 (or higher).

  10. Rick

    I haven’t found a command to list which accounts have been added to one of these policies. Does that exist?

    Also, it’s worth noting that one of the things affected is the ability to connect to Exchange Online with PowerShell in the usual way. Apparently, you must instead use Connect-EXOPSSession, which is most often associated with MFA. It’s unclear if this means that MFA then becomes required.

    1. betty stolwyk

      To list accounts and any assigned authentication policy

      Connect-AzureAD
      Get-user | where recipienttype -eq usermailbox | ft identity,authenticationpolicy

  11. James

    Hi Steve, useful tips thanks. If I want to remove the policy later should anything arise, what would the command for that be?

  12. Steve Goodman

    No date has been announced that I am aware of.

  13. Magnus Björk

    I did som test with this last week and I think there might be some issues… I created a block policy, assigned that to one user and then I also assigned it as my tenants default policy. Note, I did not assign it to any other accounts. But the day after I did that we had problems with some functions like our scanner. After creating a new allow policy for them and assign that they worked again.
    So I suspect there is something not really working as intended.

    1. Steve Goodman

      If you’ve assigned it as the default policy, would you not expect it to affect all clients?

      Steve

  14. Ananta

    Hi Steve.

    Thanks for this post. Did Microsoft give any date by which they will disable the legacy authentication for Exchange Online?

  15. Rkast

    Hi Steve,
    Maybe a good idea to post the cmdlet in text/code instead of a picture so we can easily copy it from this great blog post instead of typing it over.
    Peace out

    1. Steve Goodman

      Hiya,

      Apologies – that was unintended on my side and the article has been updated ?

      Steve

      1. Rkast

        /Tips hat
        Thank you sir.

Leave a Reply