How To: Exchange Authentication Policies

Exchange logo

There are several ways how you can protect and limit access to Exchange Online. Conditional Access, Client Access Rules, the older ActiveSync Device rules and, the topic of this post, Authentication Policies. These policies are available in Exchange Online and Exchange Server 2019 since CU2. This article will show you how to implement this.

Why use Authentication Policies?

Authentication Policies only do one thing: enabling or disabling legacy or basic authentication (I use both terms) on protocols used by Exchange Online. Why would you want that? Well, basic auth only requires a username and a password and that's it. There are no additional checks before allowing access, this means that malicious attackers just need those two pieces of information. If users have re-used their passwords, any leak outside of your control could potentially provide access to your environment. You will likely find a lot of failed logon attempts on SMTP or IMAP protocols when you check sign-in activity in Azure Active Directory,

When you enable Modern Authentication, this does not disable legacy authentication. Even if you have Conditional Access and/or Multi Factor Authentication (MFA) in place, it is still wise to implement Authentication Policies. Especially now that Microsoft has delayed the removal of legacy authentication on some of the Exchange protocols. It only takes one forgotten account with leaked credentials to gain access.

Preparing

Do not forget to check your environment before implementing these security measures. For Exchange Online, use Azure AD Sign-in reporting to investigate which accounts are still using Legacy Authentication. The Exchange Team blog has an excellent blog post on how to find those legacy sign-in accounts.

It's possible you have applications or appliances that still use older protocols like IMAP or POP to access mailbox content or require authenticated SMTP. Microsoft has been working on adding OAuth authentication (or Modern Authentication) to those protocols. OAuth is currently available on IMAP, SMTP and recently POP. Be sure to read those articles, there are some things to consider. Obviously, your application etc. must support the use of OAuth, be sure that you vendor supports this or will be supporting it soon. You may have to upgrade or change applications. Be sure to check that ASAP as this feature might not be a priority for your vendor and you might be stuck with some mailboxes on your on-prem Exchange environment. It's comparable with the TLS1.2 impact I blogged about in early 2018.

Implementing

I always create multiple policies with different protocols having a different legacy authentication state. While most of your clients should already use Modern Authentication, there are still line-of-business applications or devices that can only use legacy auth. You might need to create exceptions. Below is an example of creating several policies:

New-AuthenticationPolicy "Enable all BasicAuth" -AllowBasicAuthActiveSync -AllowBasicAuthAutodiscover -AllowBasicAuthImap -AllowBasicAuthMapi -AllowBasicAuthOfflineAddressBook -AllowBasicAuthOutlookService -AllowBasicAuthPop -AllowBasicAuthReportingWebServices -AllowBasicAuthRpc -AllowBasicAuthSmtp -AllowBasicAuthWebServices -AllowBasicAuthPowershell
New-AuthenticationPolicy "Disable all BasicAuth"
New-AuthenticationPolicy "Allow only BasicAuth PowerShell" -AllowBasicAuthPowerShell
New-AuthenticationPolicy "Allow only BasicAuth PowerShell, EWS" -AllowBasicAuthWebServices -AllowBasicAuthPowerShell
New-AuthenticationPolicy "Allow only BasicAuth SMTP" -AllowBasicAuthSMTP
New-AuthenticationPolicy "Allow only BasicAuth EWS" -AllowBasicAuthWebServices
New-AuthenticationPolicy "Allow only BasicAuth SMTP, EWS" -AllowBasicAuthSMTP -AllowBasicAuthWebServices
New-AuthenticationPolicy "Allow only BasicAuth IMAP" -AllowBasicAuthImap
New-AuthenticationPolicy "Allow only BasicAuth SMTP, IMAP" -AllowBasicAuthSMTP -AllowBasicAuthImap

Create these policies as needed and set the most restrictive as an organization default which is in this case "Disable all BasicAuth". Setting this default ensures that every user account is no longer allowed to use legacy authentication. You do this with the Set-OrganizationConfig cmdlet:

Set-OrganizationConfig -DefaultAuthenticationPolicy "Disable all BasicAuth"

For the accounts that still require legacy authentication, you specify a less restrictive policy. You can use the Set-User cmdlet for this. In this example the user still requires PowerShell and Exchange Webservices with legacy authentication. Configure this as needed with:

Set-User -Identity troy.winger -AuthenticationPolicy "Allow only BasicAuth PowerShell, EWS"

This user can now use legacy authentication only on those protocols. Do note that you must perform this on the user authenticating, not on the target mailbox. This also means this user can connect to every mailbox with legacy authentication. You should provide access to a specific mailbox and not more than is required.

After implementing, be sure to check your Azure AD Sign-in report again to confirm no legacy authentication is being performed anymore, besides the exceptions you've implemented. Monitor those exceptions closely and remove them when Legacy Authentication is no longer required. You will reduce your attack surface with each step you take by removing Legacy Authentication.

Update July 17, 2020

Joshua Bines commented to me via LinkedIn that enabling Authentication Policies might have some negative consequences when migrating from on-premises to Exchange Online. See this Microsoft article to learn more. Also, fellow MVP Gareth Gudger has a blogpost discussing similar issues you might run into when moving mailboxes with some mitigating solutions.

Leave a Reply

Your email address will not be published. Required fields are marked *

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