Disabling Basic Authentication for Exchange Online (Preview)

Suppressing Password Spray Attacks

Microsoft’s October 17 announcement of a new method (in preview) to disable basic authentication for connections to Exchange Online is very welcome. Why? Basic authentication means what it says – a basic mechanism to authenticate a connection to a service. Basic authentication is simple to use and simple to abuse, which is why attackers try to exploit its simplicity in exploits like password spraying attacks.

Exchange Online supports many different connection protocols from ActiveSync to POP3 to IMAP4 to MAPI. This is a good thing because it allows people to use their client of choice to connect to their mailbox. Unfortunately, the profusion of connection protocols creates a difficulty too because each must be secured to stop penetration by attackers.

Protocol Authentication Policies

The preview method now available introduces a new cmdlet set to create and manage protocol authentication policies. Running the New-AuthenticationPolicy cmdlet creates an authentication policy that disables basic authentication for all the protocols supported by Exchange Online. For example:

The only protocol enabled here is Log Export, which is probably not going to be used by an attacker.

Modern Authentication Needed

Before you block basic authentication, you must enable modern authentication for your tenant and be sure that users have clients that support modern authentication, like Outlook 2016. Enabling a block on basic authentication will have an immediate effect on older clients if you’re not careful. See this support article for more details.

Changing Protocol Authentication Settings

If you want to change a setting to allow basic authentication for a protocol, run the Set-AuthenticationPolicy cmdlet. For example:

You can have multiple authentication policies in a tenant, each of which allows basic authentication for different protocols.

Assigning Policies to Users

After you’ve created the authentication policies you need, you assign them to user accounts to tell Exchange Online whether users can connect using basic authentication.

In my tenant, I decided to have a single policy applied to all user accounts and implement the policy immediately, which means that you also reset the baseline for user refresh tokens. This has to be done with PowerShell, so I used a command to find all user mailboxes and use the Set-User cmdlet to assign the authentication policy and reset the refresh token for the account to the current date and time. This will force Exchange to request clients using basic authentication for connections to reauthenticate using modern authentication.

Checking Policies Are Applied to Accounts

To check that policies are in place as you intend, check the accounts by running the Get-User cmdlet. As shown below, you should see that each account is assigned the desired authentication policy and the refresh token is reset to the time when the Set-User command executed.

Defining a Default Protocol Authentication Policy

New user accounts are assigned the default protocol authentication policy for the tenant. Unless you define a default protocol authentication policy in the organization configuration, the value assigned to new accounts is $Null, meaning that no policy is assigned. To change this, run the Set-OrganizationConfig cmdlet and define a new default:

You can check the value with the Get-OrganizationConfig cmdlet:

 

All Good So Far

The block on basic authentication has been in place in my tenant for a few days now and no problems have been seen so far. Apart from finding out whether people use obsolete clients to connect to mailboxes, the biggest issue you might face is that disabling basic authentication for PowerShell forces accounts to use multi-factor authentication when they connect to Exchange Online.

If a problem was encountered, it’s easily fixed by reversing course and either removing the authentication policy from the affected user accounts or allowing basic authentication for a specific protocol. To remove a policy, run Set-User again:

No events are recorded in the Office 365 Audit Log to show that someone’s account was blocked for basic authentication. But this is a preview that’s designed to show customers what’s coming down the tracks and it’s likely that Microsoft will improve this aspect of the implementation when protocol authentication policies are generally available.

Limiting basic authentication for connections using a protocol policy only affects Exchange Online and has no influence over any other Office 365 workload.


Exchange Online is covered in Chapter 5 of the Office 365 for IT Pros eBook. Then again, Exchange is used by many Office 365 applications, so it turns up throughout the book.

10 Replies to “Disabling Basic Authentication for Exchange Online (Preview)”

  1. “Disabling basic authentication for PowerShell forces accounts to use multi-factor authentication when they connect to Exchange Online.”

    I know that disabling basic auth forces the use of Exchange Online PowerShell (which is available via EAC/Hybrid, of all places), but is it really the case that that module itself requires MFA? Yes, it’s closely associated with MFA, as supporting MFA was the reason that it was developed, but I thought that Connect-EXOPSSession worked without it.

    1. I think the case is that if you can’t use basic authentication and must use MFA, then Connect-EXOPSSession is the only way to use PowerShell.

      1. That must be it, since the normal way of connecting to Exchange Online in PowerShell seems to be working just fine here on pure basic auth (i.e. no exception for PowerShell). I think MS could have made this a tad clearer, since they said “If you block Basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell Module to connect.”

  2. To follow-up on the PowerShell/Exchange comment, I just hadn’t waited long enough. Refreshing the token apparently isn’t foolproof, since being cut off from PowerShell (for Exchange Online) took about a day (“AccessDenied”). So, it is true that pure basic auth forces the use of the new module, Exchange Online PowerShell, but it in turn doesn’t force MFA.

    1. What time did you set for the token refresh when you assigned the policy to mailboxes. If you set it to be the current time, all existing tokens are cancelled and access needs to be reauthenticated immediately.

      1. Yes, it was the same command that you show above, ending in UtcNow. But I ran my usual PowerShell batch many times in the day since then, and it always worked without incident, until this morning. Not a big deal, and it makes MS’s sentence about it exactly right, but my usual all-in-one script will need to be adapted for the new module (there are some lengthy threads around about how to do that). As a standalone, the new module works fine.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.