Power Platform’s protection — Azure AD Conditional Access

Having spent some time during the last months working on securing Power Platform, I thought it could be interesting to write a series of articles regarding this topic to share what I learned.

And what would be a better place to start than talking about securing access to Power Platform through Azure AD Conditional Access policies?

Overview of Azure AD Conditional Access

What is Azure AD Conditional Access?

The main goal of Azure AD Conditional Access is to use “signals” (like “is the user in the scope of the policy”, “is the service or application in the scope of the policy”, IP location, device configuration…) to determine if an identity can access a service or an application.

Illustration of the Signal > Decision > Enforcement flow in Azure AD Conditional Access

In summary, Azure AD Conditional Access applies an if-then statement to access request to identify what needs to be done.

Example: If a user in group A tries to access Dataverse from outside of the United States, block the request.

Important points to consider regarding Azure AD Conditional Access is that “[…] policies are enforced after first-factor authentication is completed” and it “[…] isn’t intended to be an organization’s first line of defense for scenarios like denial-of-service (DoS) attacks, but it can use signals from these events to determine access” (source: What is Conditional Access in Azure Active Directory? — Microsoft Entra | Microsoft Learn). In other words, Azure AD Conditional Access policies apply during the authentication, but after that the rules are not continuously checked. If a token has been generated under valid conditions, it can be used in different and invalid conditions during its lifetime.

This conclusion regarding the continuity of the evaluation of the Azure AD Conditional Access policies is not entirely accurate. Indeed, in some scenarios, Continuous access evaluation (a capability of Azure AD Conditional Access) will reevaluate policies rules with a latency up to 15 minutes.

Before closing this introduction section, I wanted to leave you with 2 points that I also consider pretty important:

• Think carefully about the organization and the naming convention for your Azure AD Conditional Access policies. You definitely don’t want to be confused going through the list of policies, but rather to be able to easily and clearly understand what’s the role of a policy is and also understand quickly which enforcements will be applied in which scenario.
• Manage your Azure AD Conditional Access policies (and other related assets like named locations) like any other core asset of your information system — using code, testing your policies and monitoring them.

The Microsoft.Graph.Identity.SignIns PowerShell module, part of the Microsoft Graph PowerShell SDK, seems to offer a great way to manage Azure AD Conditional Access policies (and other related assets like named locations) with code. You can find an interesting sample in the microsoftgraph/msgraph-sdk-powershell GitHub repository.

Testing can be done by initializing an Azure AD Conditional Access policy in “Report-only” mode or by using the “What If” tool to simulate a scenario and validate the expected enforcement.

Monitoring of Azure AD Conditional Access policies can be done using Azure AD sign-in logs or leveraging the integration of Azure AD with Azure Monitor, simplifying the analysis of the logs.

Protect Power Platform services

The first key area we will explore will be securing access to key Power Platform services (like Power Apps maker portal or Dataverse) by a user.

Currently the “apps” related to Power Platform you can consider configuring in an Azure AD Conditional Access policy are:

• Common Data Service: for Dataverse (accessing data or capabilities)
• Microsoft Flow: for the Power Automate maker portal (configuration or running components like cloud flows)
• Microsoft PowerApps: for the Power Apps maker portal (configuration or playing an app)

Power Platform “apps” available in Azure AD Conditional Access policies

You will find below a few examples of Azure AD Conditional Access policies you could consider to secure the access to these Power Platform services by your users:

• Requiring multifactor authentication (MFA) for Power Platform Administrators accessing Power Platform services

If the user is only eligible to the Power Platform Administrator role, the policy will apply the enforcement (MFA in our example) only if the Azure AD role has been activated through Azure AD Privileged Identity Management. Also, if you assign Azure AD roles through group membership, based on some tests, it seems the Azure AD Conditional Access policy will not apply the enforcements as expected.

Requiring MFA for Power Platform Administrators — Included apps

Requiring MFA for Power Platform Administrators — Selected grant control

• Blocking a user trying to access Dataverse data from a desktop app (like Excel)

Block access to Dataverse from mobile / desktop — Included apps

Block access to Dataverse from mobile / desktop —Selected client apps as condition

Block access to Dataverse from mobile / desktop — Block access

Block access to Dataverse from mobile / desktop — Test result from Excel

• Redirecting to Defender for Cloud Apps users accessing Dataverse from outside United States to apply more security rules (like blocking files download)

Redirect access to Dataverse from outside United States to Defender for Cloud Apps — Included apps

Redirect access to Dataverse from outside United States to Defender for Cloud Apps — Location condition

Redirect access to Dataverse from outside United States to Defender for Cloud Apps — Custom policy for Conditional Access App

Redirect access to Dataverse from outside United States to Defender for Cloud Apps — Test result from Canada

We will explore further this scenario in an upcoming article about Defender for Cloud Apps.

As you can see, Azure AD Conditional Access offers many ways to protect the consumption of Power Platform services by your users by checking signals and applying enforcement if necessary.

Protect individual canvas apps

Please, keep in mind that this capability is still presented as in preview state in Microsoft documentation.

In the case of canvas apps not using Dataverse, the policies presented in the previous section would not be really useful. Fortunately, there is a way to clearly identify a canvas app in Azure AD Conditional Access by configuring an Authentication Context to be able to apply policies to it.

Azure AD Conditional Access Authentication Context to link to a canvas app

To link an Azure AD Conditional Access Authentication Context to a canvas app you need to use the “Set-AdminPowerAppConditionalAccessAuthenticationContextIds” PowerShell command. And you can also use the “Get-AdminPowerAppConditionalAccessAuthenticationContextIds” command to check if there is an Azure AD Conditional Access Authentication Context linked to a canvas app.

By going through 2 more examples of Azure AD Conditional Access policies, we will see how we can also protect the access to a canvas app not using Dataverse:

Canvas apps considered in the examples — Only using the “User()” object

• Blocking the access to a canvas app for a user if not on a specific device configuration (browser not allowed)

Block access to canvas app if user not on an iOS device — Included authentication context

Block access to canvas app if user not on an iOS device — Condition on device platform

Block access to canvas app if user not on an iOS device — Block access

Block access to canvas app if user not on an iOS device — Test result from a browser on a Windows device

• Requiring multifactor authentication for a user with accessing a canvas app with a medium user and sign-in risk

Require MFA for a user with medium user or sign-in risk — Included authentication context

Require MFA for a user with medium user or sign-in risk — Medium user risk condition (medium sign-in risk below)

Require MFA for a user with medium user or sign-in risk — Require MFA grant control

With this additional capability of Azure AD Conditional Access (Authentication Context), we can secure access to Power Platform by users pretty well and cover lot of different scenarios.

Workload identities and Dataverse scenarios

Users are not the only identity type which can interact with Dataverse. In the context of integrations where other systems need to communicate with Dataverse we often used workload identities.

Even if it requires additional licenses, Azure AD Conditional Access offers a way to apply policies to workload identities protecting access to Dataverse from this angle too.

There is a trial plan for “Microsoft Entra Workload Identities” you can access by following this link: Microsoft Entra Workload Identities | Microsoft Security

For example, we could configure an Azure AD Conditional access policy to block the access to Dataverse by a workload identity if the authentication does not come from an Azure Functions app in the Canada East Azure region.

First, we need to configure a Named Location using the IP ranges of the AppService Azure Service Tags for the Canada East region:

1.Get the IP ranges of the AppService Azure Service Tags of the Canada East Azure region using the “az network list-service-tags” command from Azure CLI

Get AppService.CanadaEast Azure Service Tag IP Ranges

2.Create a Named Location with IP ranges in Azure AD Conditional Access with the result from step 1 using the “New-MgIdentityConditionalAccessNamedLocation” command of the Microsoft Graph PowerShell module

Creation of Azure AD Conditional Access Named Location for App Service Canada East IP ranges

Then we will move forward with the configuration of the Azure AD Conditional Access policy to block workload identities trying to access Dataverse from a different place than an Azure Functions app in the Canada East Azure region.

Block access to Dataverse for workload identities not coming from Azure Functions Canada East — Included apps

As you can see in the screenshot above, to control the access of workload identities our only choice is to select the “All cloud apps” option currently — but, don’t worry, it includes Dataverse.

Block access to Dataverse for workload identities not coming from Azure Functions Canada East — Excluded locations

Block access to Dataverse for workload identities not coming from Azure Functions Canada East — Block access

Block access to Dataverse for workload identities not coming from Azure Functions Canada East — Test result from my laptop

These are just some scenarios you could cover with Azure AD Conditional Access to protect Power Platform from an access perspective. Signals like device compliance or device configuration should also definitely be part of your plan.

Once you have these policies in place (and well named and organized), you will be more confident regarding the fact that an identity will not be able to gain access to Power Platform services if the expected conditions are not met.

But obviously, connection is only the first step in the consumption of Power Platform services and protecting it is only a part of a larger objective — having a good security posture. In upcoming articles, we will continue to explore other capabilities of the Microsoft cloud that will help improve our level of protection of Power Platform.