How to Disable Basic Authentication for Exchange Online Connection Protocols

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:

New-AuthenticationPolicy -Name "No Basic Auth"

RunspaceId : fd030e40-053a-404c-90f9-3cf9f2c2dcef
AllowBasicAuthActiveSync : False
AllowBasicAuthAutodiscover : False
AllowBasicAuthImap : False
AllowBasicAuthLogExport : True
AllowBasicAuthMapi : False
AllowBasicAuthOfflineAddressBook : False
AllowBasicAuthOutlookService : False
AllowBasicAuthPop : False
AllowBasicAuthReportingWebServices : False
AllowBasicAuthRest : False
AllowBasicAuthRpc : False
AllowBasicAuthSmtp : False
AllowBasicAuthWebServices : False
AllowBasicAuthPowershell : False
AdminDisplayName :
ExchangeVersion : 0.20 (

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:

Set-AuthenticationPolicy -Identity "No Basic Auth" -AllowBasicAuthPop:$True

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.

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Set-User -AuthenticationPolicy "No Basic Auth" -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

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 cmdlet executed.

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

DisplayName   AuthenticationPolicy StsRefreshTokensValidFrom
-----------   -------------------- -------------------------
Deirdre Smith No Basic Auth        18 Oct 2018 14:30:42
Tony Redmond  No Basic Auth        18 Oct 2018 14:31:06
TempAdminAC   No Basic Auth        18 Oct 2018 14:31:11

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:

Set-OrganizationConfig -DefaultAuthenticationPolicy "No Basic Auth"

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

Get-OrganizationConfig | fl DefaultAuthenticationPolicy

DefaultAuthenticationPolicy : No Basic Auth

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:

Set-User -Identity "John Smith" -AuthenticationPolicy $Null

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.

17 Replies to “How to Disable Basic Authentication for Exchange Online Connection Protocols”

  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.

  3. Those who did this back in the day might want to run the “Checking Policies Are Applied to Accounts” command above. When I did that again after all these years, I was surprised to find that about half the accounts did not have the (lone) existing policy applied, and this is despite having used the “Defining a Default Protocol Authentication Policy” command back then (it still shows set today).

    The accounts in question are all new ones from over the last few years (since implementing the policy). While these accounts are blank in the AuthenticationPolicy column, the StsRefreshTokensValidFrom for a great many of these same ones have 2020 and 2021 dates. I’m not sure what to make of that, but I think the former column holds more weight than the latter, right?

    In any case, today I ran the “Assigning Policies to Users” command for the first time since back then, and it all looks good again. But obviously I’ll have to set a reminder for myself to look at this a month or two from now to see what happens with newly created mailboxes. Maybe this was all a hiccup and won’t happen again.

    1. Yes, so new accounts are blank for AuthenticationPolicy despite a StsRefreshTokensValidFrom date. This suggests to me that new users are not included in the default policy, which is not good since it involves manual intervention each time.

Leave a Reply

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