Table of Contents
Suppressing Password Spray Attacks
Updated: 1 October 2022
Microsoft’s October 17, 2018 announcement of a new method 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 and business email compromise. An Exchange authentication policy is a simple and effective way to stop attackers because it blocks attempts to connect to Azure AD accounts before authentication occurs.
Exchange Online supports many different connection protocols from Exchange 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.
Update: On October 1, 2022, Microsoft entered the final phase of its project to remove basic authentication connectivity for seven email protocols. Organizations that want to protect themselves from drive-by password spray attacks before Microsoft disables basic authentication by deploying an authentication policy to block the protocols most exploited by attackers like IMAP4, POP3, and SMTP. The great advantage of an authentication policy is that it blocks a connection before it gets to Azure AD authentication. Because the policy refuses connections over blocked protocols, attackers never get to test stolen or made-up credentials against a tenant.
Creating an Exchange Authentication Policy
The 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 (15.0.0.0)
The only protocol enabled here is Log Export, which is probably not going to be used by an attacker.
If you don’t want to use PowerShell, you can also manage the default authentication policy through the Microsoft 365 admin center.
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.
Very neat and crisp article
“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.
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.
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.”
Yep. That’s mentioned in https://office365itpros.com/2018/10/24/disable-basic-authentication-exchange-online/
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.
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.
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.
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.
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.
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 new users created after the authentication policy being made default is still listed as an authentication policy of “null” ?
I think I answered the same question on the Practical365.com site just now… The answer is that when a user account shows null for the authentication policy, Exchange Online applies the default organization policy (the one managed through the Microsoft 365 admin center). If you want to use a non-default policy, you must assign the policies with Set-User and remember to do this when new accounts are created.
Hello Tony, Thanks for the quick reply! This makes sense now, I created an authentication policy and made it the default policy via PowerShell, and I now see the settings I made to block basic auth are visible in the “Modern Authentication” service in “Org Settings” on the M365 admin center. I was just hung up on the fact new users auth policy was still null, I was expecting to list the policy name (even if its default)
Thanks Again!
Peter, I’m glad you brought this up (I had the same question in July). Since it’s not really practical to continue to revisit this as new users are added (something that I didn’t even know was needed until I happened to notice it in July), and also because no customization is needed here, I just ditched our circa 2018 policy and went with the one that Admin creates automatically (augmented by manually disabling AllowBasicAuthOutlookService and AllowBasicAuthReportingWebServices, since they aren’t otherwise covered), and then applied that to all existing accounts.
As I understand it, that should be the end of this going forward; new accounts, as Tony suggests, will fall under this “default” policy and actually see it applied to them. It’s unclear to me why the original policy (now gone) created via PowerShell, especially since it was the default (and only) policy, wouldn’t have enjoyed the same benefit for new users.