Recently, an unexpected problem popped up with some ConditionalAccess policies: it is not possible to enforce controls. Applications show up as ‘excluded’ from the targeted resources when ConditionalAccess policies are evaluated. This behaviour allows users to access resources without MFA or compliant devices.

This is possible for Applications which use Entra ID as Idp or require only minimum Microsoft Graph permissions (PublicClients: email, offline_access, openid, profile, User.Read, People.Read).

In an article, Microsoft mentions a restriction for certain permissions, which could have something to do with this, but the actual behaviour seems to be quite random:
“In some cases, an All resources (formerly ‘All cloud apps’) policy could inadvertently block user access. These cases are excluded from policy enforcement and include.”

This post aims to bring more light on these cases and their implications for ConditionalAccess policy sets.

 

App registrations in Entra ID

Before we start: App-Authentication can be configured for our App in Entra ID as “Web applications” or ”Mobile and desktop applications”, whereat we have also different platform possibilities:

The connecting client can ether be public or confidential. The following blogpost describes the difference between the clients:

 

In my test I am authenticating as a public client to a test application called CodeGrant, which I created in my Tenant. The App uses delegated Microsoft Graph permissions which where consented by an administrator of the Tenant:

When coming to the Authentication Settings of the App, Public client flows are not allowed and three platform configurations where added:

  • Web
  • Single-page application
  • Mobile and desktop applications

 

In these tests, the OAuth 2.0 auth code flow (without certificate or secret) is used by simple http requests, switching the platform with the redirect uri:

https://login.microsoftonline.com/06917a81-XXXX-XXXX-XXXX-XXXXXXXXXXXX/oauth2/v2.0/authorize?client_id=f54384XX-XXXX-XXXX-XXXX-XXXXXXXXXXXX&response_type=code&redirect_uri=XXXDefinedURLXXX&response_mode=query&scope=offline_access https://graph.microsoft.com/user.read&state=XYZ5&prompt=select_account&code_challenge=XXXXXXXXX&code_challenge_method=S256

The behavior for other OAuth flows is differs again. For reference about the used flow, you can check the Microsoft Learn article:

 

 

A closer look at the behaviour

When examining the issue, two behaviors were identified where different results of Conditional Access policy evaluation and enforcement would be expected:

1 – Block or protect specific Access to specific App with ConditionalAccess Policy

Upon integrating a third-party application into the Entra ID Tenant, we followed the consent procedure as outlined by the software provider. The objective was to restrict access to the application and its data under specific conditions, such as when the accessing user is not within the office. To achieve this, ConditionalAccess is used to restrict access to the application from Trusted Networks (could be also Global Secure Access):

 

The access to the app was not blocked as expected and when checking the SignIn-Logs
the App is ‘not included’ even if in the policy configuration it is:

According to the article mentioned above, this could be interpreted as expected behaviour. Conditional Access is designed to protect resources (APIs) that are integrated with Entra ID and not applications. In this instance, since the user is not accessing any resources beyond the excluded scopes, Conditional Access policies are not enforced.

It seems thatConditional Access cannot enforce controls for certain specific applications when no resources or only excluded resources within Microsoft 365 are used, such as when Entra ID is used as an Identity Provider.

Until recently, it was generally understood that Conditional Access is applied to the applications in the Tenant and not just the resources behind them. Not sure if the renaming from “All cloud apps” to “All resources” was to address those wrong assumptions or if it was more than just a simple renaming and the policy enforcement behaviour changed.

Following this finding, it is advisable to verify whether any application is protected with MFA or compliant device enforcement with CA-Policies targeted to all applications.

 

2 – Protect all Applications with ConditionalAccess

Upon further inspection, it is observed that not all authentications to an application connected to Entra ID are consistently protected by Conditional Access Policies, even when these policies are targeted to “All resources” (previously referred to as ‘All cloud apps’). In some instances, access was granted without requiring a compliant device or multi-factor authentication (MFA).

A closer analysis revealed that Conditional Access policies may exclude specific applications for various reasons, such as the exclusion of any resource from a policy.

To illustrate this, a standard policy was created targeting all resources and client app types, necessitating either a compliant device, app protection, or MFA. The policy excludes one target resource, in this case “Report phishing”, but it could be ANY Resource.

This discrepancy highlights the necessity for thorough verification of Conditional Access policies, ensuring that applications expected to be protected are indeed subject to the intended security measures.

 

The Policy can have different user assignments, conditions or grant controls, the behaviour stays the same.

The application used in this tests has three platforms configurations for authentication:

 

 

Upon conducting the tests, it was anticipated that the Conditional Access policy would uniformly enforce multi-factor authentication (MFA) or require a compliant device/app for all authentication attempts. However, analysis revealed inconsistencies. Specifically, during two out of three authentication attempts, an authorization code was obtained and utilized with single-factor authentication, bypassing the expected MFA challenges or device compliance requirements.

When analysing the SignIn Logs, the App assignment is not matched and the App shows up as “App excluded” for these authentications.

Application platform Result Reason
Mobile and desktop applications CA Policy not applied App excluded
Single-page application CA Policy not applied App excluded
Web Require multifactor authentication All apps included

 

 

 

The only request, where the Policy was enforced correctly, requiring MFA was the one to the Web platform:

 

When testing further, the excluded resources where excluded, so that the CA policy now appears as follows:

 

When making the identical authentication requests as before the results are different, but finally as expected:

Application platform Result Reason
Mobile and desktop applications Require multifactor authentication All apps included
Single-page application Require multifactor authentication All apps included
Web Require multifactor authentication All apps included

 

After that result I did other tests, excluding completely random Apps from the policy, getting always the same result: the Policy is applied only to the Web platform, not covering “Single-page application” & “Mobile apps and desktop clients” authentication platform.

Further tests where done, excluding completely random applications from the policy, which repeatedly yielded the same result: The policy consistently applies only to the Web platform, while it does not cover the “Single-page application” (SPA) and “Mobile apps and desktop clients” authentication platforms.

 

Conclusion

This inconsistency poses a significant challenge for ensuring the security of applications, especially for third-party integrations where Entra ID is used as Idp.

The consequence of this behavior extend to Zero Trust and Secure Access Service Edge (SASE) implementations. Until an app is configured with the platform “Mobile and desktop applications” or “SPA” and doesn’t access other resources within Microsoft 365, ConditionalAccess is not enforcing controls such as compliant devices, networks (including GSA), or even blocking specific users from accessing certain apps. This limitation undermines the effectiveness of Zero Trust and SASE strategies, which rely on robust access controls to secure applications and data.

 

Author