Conditional Access policies are at the heart of Entra ID zero trust policy engine enforcement. They collect various signals (identity, device, network location, protocol, client app type, real time sign-in risk, accessed resource) and enable enforcement of company's resource access policies.
In the article below, I assume the reader has moderate level of familiarity with conditional access concepts.
Since Conditional Access policies operate on established signals, like user identity, device identity, network location, sign-in session risk and others, they're applied only after successful primary authentication.
It's important to remember this especially if your access requests are getting blocked by conditional access policy and you aren't sure why.
Don't start with troubleshooting the authentication credentials of the affected users - if they were blocked by conditional access policy, their primary authentication factor (most likely password, sadly) was successfully validated.
Instead, dive into Entra ID sign-in logs and analyze generated errors:
How does the conditional access policy blocking legacy authentication work?
In short, it blocks protocols allowing client applications (like Outlook 2010 on Windows or built-in Mail app on old version of iOS) to collect user's logon credentials and pass them to a backend service to authenticate the user.
It means every time you see the app prompting you for explicit credentials, there's a high chance that it uses legacy authentication protocol (e.g. SMTP, IMAP4, POP3 and many others).
Client applications using modern authentication protocols behave differently:
- They send you through their configured, trusted identity provider, which validates your credentials and returns ID or access token that is later consumed by the app/service you're accessing.
- They never collect and process your credentials directly.
Back to conditional access and legacy authentication blocking - you should implement it and strive for minimal exceptions. Good documentation on how to achieve this is available here. This solves blocking on authentication platform side.
Shall you do more than this though? Absolutely! Remember, the behavior of conditional access policies is - they apply after successful authentication (see Tip #1).
In a legacy protocol authentication scenario including attackers who are using password spray or stuffing techniques, if they're blocked by conditional access, it means they were able to successfully validate the password because policy enforcement is performed post-authentication...
From IT security prevention and risk reduction perspective, it is better to block such attempts at the protocol level and simply deny credential validation attempts against Entra ID.
Most of the legacy authentication protocols were disabled by Microsoft in 2022 (see this), but it's always a good idea to double check your configuration and reinforce its desired state.
To reinforce legacy authentication blocking on service/resource-side (i.e. on Exchange Online or SharePoint Online)
| M365 workload | How to disable legacy auth (PowerShell) | Privilege needed to execute the commands | Relevant documentation |
|---|---|---|---|
| Sharepoint Online and OneDrive | Import-Module Microsoft.Online.SharePoint.PowerShellConnect-SPOService -URL <YOUR_TENANT_SPO_ADMIN_URL>#Disable legacy authentication in Sharepoint Online/OneDriveSet-SPOTenant -LegacyAuthProtocolsEnabled $False |
Sharepoint Administrator Entra ID role | MS Learn |
| Exchange Online | Import-Module ExchangeOnlineManagementConnect-ExchangeOnline#Enable modern authentication in ExO organizationSet-OrganizationConfig -OAuth2ClientProfileEnabled:$True#Create policy disabling legacy authentication for all available protocolsNew-AuthenticationPolicy -Name "Baseline - Block Basic Auth Protocols" -AllowBasicAuthAutodiscover:$False -AllowBasicAuthActiveSync:$False -AllowBasicAuthImap:$False -AllowBasicAuthMapi:$False -AllowBasicAuthOfflineAddressBook:$False -AllowBasicAuthOutlookService:$False -AllowBasicAuthPop:$False -AllowBasicAuthPowershell:$False -AllowBasicAuthReportingWebServices:$False -AllowBasicAuthRpc:$False -AllowBasicAuthSmtp:$False -AllowBasicAuthWebServices:$False#Set default authentication policy for the organizationSet-OrganizationConfig -DefaultAuthenticationPolicy "Baseline - Block Basic Auth Protocols"#Disable SMTP Basic auth at the transport layerSet-TransportConfig -SmtpClientAuthenticationDisabled:$True |
Exchange Administrator Entra ID role | MS Learn |
By executing steps above, you're effectively adding another layer of defense - service-side legacy authentication blocking (1st layer) + conditional access policy blocking (2nd layer).
When it comes to IT security controls, you must be prepared for control failures and remember: "Two is one, and one is none!" & "An ounce of prevention is worth a pound of cure."
Tip #3 - Policies do not apply to headless identities (service principals, managed identities) by default.
This is somehow a repeat from my previous article. But it's worth repeating 😄
Conditional Access policies, regardless of how well thought out they are, in a tenant with Entra ID P1/P2 licensing without any add-ons don't apply to service principals.
To partially fix that:
- License your tenant with appropriate amount of Entra ID Workload Identities Premium licenses.
- Design, configure and apply policies (with limited configuration options) to service principals associated with applications you've created in your tenant.
As of now, you can't apply conditional access policies to govern third party application and service principal access - you must risk accept it.
You might have implemented set of conditional access policies enforcing controls based on network location signals.
Example scenarios include - requiring additional assurance (e.g. MFA) for authentication requests originating from outside of defined IP address ranges or simply blocking access outside of these ranges.
You might be convinced that by defining these network-based constraints, your externally accessible cloud resources are secured from unauthorized access outside defined network address ranges. However, it's not the case by default.
If you haven't properly configured your network locations in Entra ID and didn't enable certain options in your conditional access policy configuration, all of that allows for the scenario where tokens sent to your cloud service (e.g. Exchange Online) can originate from outside of approved network location and still be accepted by that service (source).
This frequently happens in token theft scenarios, where attackers attempt to reply stolen access/ID tokens from unauthorized locations.
However, if you correctly define all IP address ranges of your clients2 and enable 'strictly enforce location policies' session control in CA policies relying on network signals, you gain almost real-time revocation of these tokens. Strict location enforcement offers extra protection and considerable risk reduction against token replays outside of authorized network boundaries.
Note
Only CAE capable clients and resources support this functionality. Compatibility list currently includes: Exchange Online, SharePoint Online, Microsoft Teams, Microsoft Graph and most of first party native and web clients.
1/ Define network locations (don't use countries - they don't work with CAE)
Caution
Before you enable 'strictly enforce location policies' in conditional access policy you must ensure that all IP addresses from which your users can access Microsoft Entra ID and resource providers are included in the IP-based named locations policy. Otherwise, you will block your users.
2/ Include locations in policy configuration
3/ Enable strict location enforcement
All work is licensed under a Creative Commons Attribution 4.0 International License.
