Why is Legacy Authentication BAD?
Legacy Auth, or Basic Auth as it’s also called, is a term used to refer to authentication protocols used by applications that do not use Modern Authentication such as:
- Older Office clients (e.g., Office 2010 client)
- Clients that use mail protocols such as IMAP/SMTP/POP
Modern authentication is based on the Active Directory Authentication Library (ADAL) and OAuth 2.0.
Attackers prefer the legacy protocols – nearly 100% of password spray attacks use legacy authentication protocols! Because legacy authentication protocols don’t support interactive sign-in, which is required for additional security challenges like multi-factor authentication and device authentication.
So I strongly advocate blocking Legacy Authentication in your Office 365 environment as well as on-premises if possible.
These are the areas you can block legacy authentication in Office 365:
- Exchange Online
- SharePoint Online
- Configure AD FS Extranet Lockout
- Configure AD FS Extranet Smart Lockout (ESL)
- Everything else with Azure AD Conditional Access
Basic authentication in Exchange Online uses a username and a password for client access requests. Blocking Basic authentication can help protect your Exchange Online organization from brute force or password spray attacks. When you disable Basic authentication for users in Exchange Online, their email clients and apps must support modern authentication.
The steps in federated authentication are described in the following diagram:
- The email client sends the username and password to Exchange Online. Note: When Basic authentication is blocked, it’s blocked at this step.
- Exchange Online sends the username and password to the on-premises IdP.
- Exchange Online receives a Security Assertion Markup Language (SAML) token from the on-premises IdP.
- Exchange Online sends the SAML token to Azure Active Directory.
- Azure Active Directory returns a user ticket to Exchange Online and the user is authenticated.
When it’s blocked, Basic authentication in Exchange Online is blocked at the first pre-authentication step (Step 1 in the previous diagram) before the request reaches Azure Active Directory or the on-premises IdP. The benefit of this approach is brute force or password spray attacks won’t reach the IdP (which might trigger account lock-outs due to incorrect login attempts).
Your organisation may have clients that use Legacy Authentication or App passwords, logs need to be investigated before enabling this policy. This policy can be assigned to selected users to test the effect. The policy also allows Admin to use PowerShell with basic authentication under certain circumstances. Admins can be exempt from the AAD Conditional Access policy which blocks Legacy Auth in order to be able to manage exchange with PowerShell. If necessary you can set exceptions on the users or the network locations that are still allowed to use legacy protocols. It is however important to understand that PowerShell using Legacy Auth is an attack vector used in brute force and password spray attacks.
You manage all aspects of authentication policies in Exchange Online PowerShell.
Set the “Block Basic Auth” authentication policy as the default for the organisation
Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Basic Auth"
Typically, when you block Basic authentication for a user, we recommend that you block Basic authentication for all protocols. However, you can use the AllowBasicAuth* parameters (switches) on the New-AuthenticationPolicy and Set-AuthenticationPolicycmdlets to selectively allow or block Basic authentication for specific protocols.
For email clients and apps that don’t support modern authentication, you need to allow Basic authentication for the protocols and services that they require. These protocols and services are described in the following table:
|Protocols and services
|Older EWS clients
|• Autodiscover • EWS
|Older ActiveSync clients
|• Autodiscover • ActiveSync
|• POP3 • Authenticated SMTP
|• IMAP4 • Authenticated SMTP
In the new Admin center, under Access Control, “Apps that don’t use modern authentication” – Select “Block Access”
This can also be done via PowerShell and it’s advised to confirm the setting with PowerShell:
- To check if legacy auth is disabled open SharePoint Online Management Shell.
- Run the commands
Connect-SPOService -Url https://<tenant>-admin.sharepoint.com
- Check the property “LegacyAuthProtocolsEnabled”. If this is set to true then Legacy Authentication is enabled else disabled.
Configure AD FS Extranet Lockout Protection
Extranet lockout provides the following key advantages:
It protects your user accounts from brute force attacks where an attacker tries to guess a user’s password by continuously sending authentication requests. In this case, AD FS will lock out the malicious user account for extranet access
It protects your user accounts from malicious account lockout where an attacker wants to lock out a user account by sending authentication requests with wrong passwords. In this case, although the user account will be locked out by AD FS for extranet access, the actual user account in AD is not locked out and the user can still access corporate resources within the organization. This is known as a soft lockout.
Configure AD FS Extranet Smart Lockout (Additional Feature in AD FS 2016)
ESL enables AD FS to differentiate between sign-in attempts from a familiar location for a user and sign-in attempts from what may be an attacker. AD FS can lock out attackers while letting valid users continue to use their accounts. This prevents and protects against denial-of-service and certain classes of password spray attacks on the user. ESL is available for AD FS in Windows Server 2016 and is built into AD FS in Windows Server 2019.
Everything else with AAD Conditional access
Conditional Access policies are enforced after the first-factor authentication has been completed. Therefore, Conditional Access is not intended as a first line defense for scenarios like denial-of-service (DoS) attacks.
It can take up to 24 hours for the policy to go into effect.
Before you put your policy into production, take care of:
- Service accounts – Identify user accounts that are used as service accounts or by devices, like conference room phones. Make sure these accounts have strong passwords and add them to an excluded group.
- Sign-in reports – Review the sign-in report and look for other client traffic. Identify top usage and investigate why it is in use. Usually, the traffic is generated by older Office clients that do not use modern authentication, or some third-party mail apps. Make a plan to move usage away from these apps, or if the impact is low, notify your users that they can’t use these apps anymore.