Three ways to disable basic authentication and legacy protocols in Exchange Online
One of the most common (and often successful) attacks we see in the wild is a simple brute force / password spray against weak accounts. Especially against shared mailboxes. From that foothold, the most common next step attackers will take is to send out spam/phishing emails from the compromised account, and gain more footholds and greater access for data ex-filtration, ransom, or whatever. There has actually been an uptick in this type of activity lately.
Even with Modern Authentication and indeed Multi-factor Authentication enabled, you are still left open to these types of attacks. Reason being: Basic authentication is enabled by default, and Basic auth does not support MFA to begin with. And that means you can still get in with nothing more than a username and password.
For all other accounts, you might think that using stronger passwords (e.g. eliminate “Password1” or “Spring2019” etc.) may help mitigate these risks… But, when Basic Auth is left in play it means that attackers can brute force accounts all day long. How long before they hit an award-winning user/pass combo? App passwords for instance are all lower case and a predictable length. Far better to just disable basic auth as widely as possible.
Difference between Basic and Modern Authentication
Basic auth prompts look like this:
Whereas Modern auth prompts look more like this:
Switching completely to Modern auth and disabling basic (even without implementing MFA) is a major improvement in security. Modern authentication is not subject to the same types of attacks and exploits that are possible with Basic authentication.
For example, credentials in a modern auth compatible app are not stored on the client device, and whenever something about the connection or state changes, the client is required to re-authenticate. Additionally, we can layer MFA on top of modern auth to make client authentication even stronger.
So take the time to disable Basic auth. If your users all have modern clients like the latest Office 365 bits, Outlook for iOS/Android, etc., then you probably don’t need it. But, do check out your sign-in activity first, so you understand the impact in advance. Go to the Azure AD Admin center > Sign-ins and add the Column for Client App. Then you can filter based on “Other clients.” This can give you an idea of what is out there that still relies on legacy protocols and services.
More than likely you will see some failed attempts being made against your accounts from other parts of the world using these legacy protocols–that’s the bad guys trying to get in. That’s why we’re going to cover three strategies you can employ to button up the hatches a bit. The first two require no other licensing other than Exchange Online. The last would require an Azure AD Premium or Enterprise Mobility + Security subscription.
Difference between protocols/services and authentication
“Protocols” or “services” are different than authentication, and some people get this confused. They think that because they disable POP and IMAP they have disabled basic authentication. Not true. Likewise, disabling Basic Authentication on its own may not disable “enough” protocols.
If you disable basic authentication globally, this would effectively kill POP and IMAP since those protocols do not support modern authentication–they rely exclusively on basic/legacy auth. Other protocols such as EWS, however, support both basic and modern authentication, but often it does not need to be left enabled at all.
Remember, protocols or services such as EWS or EAS are different than authentication--you can disable protocols outright whether they are enabled for basic authentication or not. And it is best practice to turn off any services which you are not using–don’t leave the door unlocked for others to potentially open if you have no intention of walking through them yourself. (This would imply also that you should disable sign-in entirely for any accounts that are either inactive or “shared mailbox” accounts).
Method #1: Disable services per mailbox
The benefits of this method include ease of implementation, and also, it requires no additional licensing. However, it is important to note that rather than disabling basic authentication, we are simply disabling legacy or extraneous services that are no longer needed (especially POP and IMAP which only support basic authentication).
From the Microsoft 365 admin center, select a user account. Go to the “Mail” tab and select the option to Manage email apps.
From here it is very easy to turn off any legacy protocols that you know are not (or should not be) in use, such as POP, IMAP, etc. In the example below I’ve even disabled EWS (used by some third party apps) and Exchange ActiveSync (meaning mobile devices cannot connect).
You can see the same view in PowerShell on any given account using:
Get-CASMailbox -identity <[email protected]> | fl Name,OwaEnabled,MapiEnabled,EwsEnabled,ActiveSyncEnabled,PopEnabled,ImapEnabled
Of course, going one account by one takes forever. To modify mailboxes in bulk via PowerShell you could use the following:
Get-Mailbox | Set-CasMailbox -PopEnabled $false -ImapEnabled $false
-SmtpClientAuthenticationDisabled $true
This would disable POP, IMAP and SMTP, all at once. While
POP and IMAP are hardly ever needed anymore, it’s not a hard and fast rule. Also note that some apps/services that interface with Exchange Online require EWS or SMTP in order to work. So just be careful to note the potential impacts when disabling services. Again, best practice: if it isn’t being used, get rid of it. POP and IMAP are by far the most commonly exploited that I have seen, and really not needed by most people just using modern apps like Outlook–so start there.
What about newly created accounts? So that you don’t have to repeat this step for every new user account, you can also modify the defaults moving forward org wide, as follows:
Get-CASMailboxPlan | Set-CASMailboxPlan -ImapEnabled $false -PopEnabled $false
That command will make it so that any newly created accounts end up with both POP and IMAP disabled by default, for example.
Method #2: Use an Exchange Online Authentication Policy
This method will effectively eliminate both POP and IMAP, as well as basic authentication for any other services you want to button up (EAS, EWS, SMTP, PowerShell, etc.) The benefits of using an authentication policy are again that it requires no other licensing, and also that you can truly disable basic auth while leaving modern authentication methods available for all types of services. However, there is no GUI interface for authentication policies, and therefore they must be configured via PowerShell.
To create a new Exchange Online authentication policy, simply run this command:
New-AuthenticationPolicy -Name “Block Basic Auth”
Take a look at it using Get-AuthenticationPolicy. By default, a new authentication policy will have all basic auth disabled. You can then apply they policy across the organization globally using this command:
Set-OrganizationConfig -DefaultAuthenticationPolicy “Block Basic Auth”
Generally speaking, most orgs do not have an authentication policy set on their individual mailboxes, so the above would mean that if you have no policy defined yet, then this is your default policy. It is however possible to create exceptions simply by adding another policy and then assigning it to mailboxes individually. Example:
New-AuthenticationPolicy “Allow Basic Auth Exceptions”
-AllowBasicAuthImap -AllowBasicAuthWebServices
In this example, we can allow IMAP and EWS to use Basic auth, but leave it disabled for other services. To apply the policy to a specific user (such as a service account):
$ExceptionUser = [email protected]
Set-User -Identity $ExceptionUser -AuthenticationPolicy “Allow Basic Auth Exceptions”
And, to apply a policy in bulk to all accounts at once:
Get-User -ResultSize unlimited | Set-User -AuthenticationPolicy “Block Basic Auth”
More details on this here.
PLEASE NOTE: If you disable basic auth across the board, you must use the Exchange Online PowerShell module that supports MFA. You cannot connect with the old method where you Get-Credential and then pass that into a new PSSession. You’ve got to use modern auth (you don’t want that old pathway left open anyways).
Method #3: Use a Conditional access policy
This method requires at a minimum Azure AD Premium P1 (which you can also get via an Enterprise Mobility + Security or Microsoft 365 Enterprise plan). The benefit to this method is that you can disable legacy client authentication against other cloud apps like SharePoint Online, and not just Exchange Online. It’s also pretty easy to implement and make exceptions for. The downside is really just the licensing requirement.
Navigate to Azure AD admin center > Azure Active Directory > Conditional access.
Create a new policy and name it something like “Block legacy client apps” Choose All users, and under cloud apps pick Office 365 Exchange Online. You could also add other apps such as SharePoint if you wanted to.
Under the Conditions > Client apps blade, select only Mobile apps and desktop clients > Other clients.
Save these selections and under Access controls > Grant, choose Block access.
Now you can save and Enable the policy. If you find that you must make exceptions then use the Exclude tab under Assignments > Users and groups.
And that concludes today’s blog post. You should be implementing these controls if you haven’t already–the attacks taking advantage of basic auth have been increasing in recent months. Stay safe out there.
Comments (18)
Good article. So what are the options for EAS devices?
Thanks
You can leave EAS active, or move people to the Outlook app (my preferred option)
If we have CA, is there a benefit to blocking using an EXO Policy AND CA or should we just use CA?
I answered my own question through some additional research. Blocking it via policy will stop the request from ever hitting the back-end. Blocking it via CA achieves the same result but it needs to make a connection attempt in order to be denied.
Nice! Good detail to know.
You really only need one of those methods, although the Exchange policy allows you to get more granular–you could allow basic for specific protocols on specific user accounts, while blocking other protocols. In CA you can exclude users but not a single protocol.
When “Other Clients” is selected, can additional conditions be selected as well and be applied (device platform, sign-in risk, location) or are these not supported when blocking legacy access?
There would be little to no value in doing this. Blocking legacy auth is one of the best things you can do to protect your tenant from password spray–a ubiquitous attack, but if you needed to exempt a specific account or location you can still do that within the policy.
Oh, I agree completely that Legacy Auth should be outright blocked across the organization. However, we are in a situation where our client wants Legacy Auth blocked ONLY for mobile devices (Android and iOS) and to force their end-users to utilize approved client apps (which are configured with Intune App Protection Policies).
I should have been more clear in my first post but my question is specifically in regards to blocking Legacy Auth based on device/platform. From my understanding, POP3 and IMAP don’t specify device platforms when authenticating a user. Therefore, you cannot block Legacy Auth based on the device utilized. Am I correct in my understanding or is their a piece I’m missing?
Thanks
That is correct. When you close that door, it’s just closed.
Thanks for the article! The new security defaults have limitations that make them unusable in my org. Unfortunately, Microsoft disabled blocking legacy auth through a baseline CA policy when they enabled security defaults. I’m glad there is a way to do it manually through powershell. I just followed your guide for my org. However, the new policy isnt showing up in the AuthenticationPolicy column when I run the get-user command. And legacy auth is not blocked. Does this usually take a lot of time to propagate?
You can set the policy to the default for the whole org–that does NOT change it on individual accounts. You can also set it on each user individually, but if a user does not have a policy specified then they are subject to the one that is set in the organization config. Should be pretty much right away when you set it. Next time they go to sign in via basic it should fail.
Hi. New to all this so I’ve been doing a tonne of reading. MS docco says applyng an Auth Policy can take up to 24 hrs to take effect so you can force it as follows. This brings it down to within 30 mins.:
Set-User -Identity [email protected] -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)
https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online
FYI;
Only method #2 will prevent brute force and password spray attacks.
Using Method 1 and/or 3 only takes affect AFTER a successful login.
From my experience, Method 2 should be the first and most important method to get setup, followed by Method 1.
When you say “prevent” here, I want to be clear–you cannot “prevent” someone from attempting a password spray on your tenant. However, when they do, they are typically doing this against legacy protocols. No matter how you choose to disable them, the threat is mitigated, because their attempts will be unsuccessful, even if they happened upon a correct password in the process–they would be blocked anyway. So I don’t know if you are necessarily “more protected” with one method over another. And usually if you are watching failed logins against tenants, and you implement any method, after a couple days it goes pretty quiet as the people attempting the password sprays figure out that you’ve closed the gate, and they stop trying; you may still see an attempt later on, but again, to what effect? Microsoft recommends CA policies now to accomplish this as a primary mechanism–in fact it is how they rolled it out initially in their own tenant. All that having been said, I still like the Exchange policy approach simply because you can do that no matter which subscription level you have, and it can be included in an initial tenant configuration script. Whereas CA policy still requires Azure AD Premium P1.
To me, Method 2 (authentication policy) seems to stop the authentication process BEFORE either method 1 or 3 kicks in.. therefore, i feel as though it’s the most important one…
for example, our Azure AD Sign-ins log had dozens of hits each day with attackers attempting to sign into accounts via IMAP and/or ActiveSync.
So we disabled IMAP and ActiveSync protocols in our Office 365 tenant thinking that would put an end to those sign-in attempts, but it didn’t and our Sign-in Logs was still showing plenty of attempted sign-ins.
When i performed a test with my own user, i found that i could still SUCCESSFULLY login with the IMAP protocol, except i just couldn’t receive any email… but none the less, i could confirm whether or not the password was good or not…
Then with Conditional Access, again, it still didn’t stop all the sign-in attempts. the CA only kicked in after a successful login.
After enabling Authentication Policies for IMAP and ActiveSync, we have seen zero logs of sign-in attempts against those protocols.. I believe this is because the tenant isn’t even responding to those authentication attempts, it’s a hard no.
I think you are basically saying that seeing less sign-in attempts in the sign-in log is a better position to be in. Blocking IMAP (protocol) does not block authentication–that makes sense and the article calls out the difference. However, when you attempt to authenticate with CA policy in place your sign-in attempt is blocked AND logged. You cannot “successfully” sign in with a CA policy enabled that blocks authentication. I would personally rather retain the audit trail in many cases. So both are a “hard no” but you can actually see the evidence in one case, and in the other, you cannot. In some cases, when a company is being targeted specifically, having the audit trail with IP’s, timestamps, etc. can be helpful. So don’t discount it.
This article is awesome alone on the delineation between a Basic Auth logon box vs. an MFA one. Many thanks!