Azure Active Directory’s Conditional Access feature is great for reducing risk during sign-in attempts, by analyzing the user and sign-in conditions and applying appropriate policy controls. These can include prompting for multi-factor authentication or blocking the sign-in attempt.
Unfortunately, some protocols don’t have the capability to be “interrupted” during their authentication workflow for a process like MFA – they demand a yes answer or they fail. They also don’t use tokens or tickets to cache a successful authentication attempt, so they send the user credentials with every connection attempt. This is seen with protocols like SMTP, POP and IMAP and is commonly referred to as “legacy” or “basic” authentication.
So, if we can’t interrupt the authentication workflow of these protocols to enforce a conditional access policy, how does the “Block legacy authentication” conditional access policy work?
To start with, you need to understand the difference between how authentication happens with legacy and modern protocols.
The authentication request process
Modern protocol authentication requests are received by the corresponding service (for example, logging into Outlook Web Access with a work or school AAD account hits Exchange Online) and are redirected to talk directly to Azure Active Directory for processing.
Legacy protocols talk to the corresponding service (for example, SMTP calls Exchange Online) and that service then proxies the authentication request to Azure Active Directory on behalf of the client.
Conditional Access policies are always applied after successful authentication, regardless of the protocol.
With a legacy authentication protocol, the client sends the authentication request to the service, with the credentials. The service validates the credentials with Azure Active Directory, then the only conditional access policy that is compatible with this proxied authentication request is to block the authentication request, if that policy is applied. If the block policy is in place, the service receives a denied response (even though the credentials were validated), and the client connection is rejected.
The following diagram shows this with a client using legacy authentication that has contacted Exchange Online, assuming Exchange Online itself has not blocked legacy authentication:
Where possible, we should also be looking to block legacy authentication at the service level.
Currently new tenants have Security defaults enabled automatically, which disables basic authentication.
For existing tenants, you can also turn on Security defaults or you can create and apply an authentication policy to block basic authentication.
How do I find legacy authentication attempts against my organization’s tenant?
If you want to see only the legacy authentication requests in your Azure AD sign-in logs, you can use the following Kusto Query:
SigninLogs | project ClientAppUsed, AuthenticationMethodsUsed, ResultDescription, ResultType | where ClientAppUsed != 'Mobile Apps and Desktop clients' and ClientAppUsed != 'Browser' | summarize count() by ClientAppUsed, AuthenticationMethodsUsed, ResultDescription, ResultType
The key here is the ClientAppUsed != (does not equal) Mobile Apps and Desktop clients or Browser. Those ClientApps only use modern authentication protocols so if we exclude them from our results, everything else should be a legacy authentication attempt.
If you are streaming your sign-ins to Azure Monitor, you can use the Azure AD Workbook “Sign-ins using Legacy Auth”. This requires an Azure AD tenant with a premium (P1 or P2) license, a log analytics workspace, and the appropriate roles documented in the article. You can then get a breakdown by app and by protocol:
You can also turn on the Conditional Access: Block legacy authentication policy and set it to Report-only. This will log when a legacy authentication request would have been blocked, if the policy was being enforced, but will still allow the request.