Dynamic, nested Azure AD groups and Power Apps access management

In June 2022 Microsoft released a long-awaited feature for user access management in Azure Active Directory: using nested groups with Azure AD dynamic groups. That’s not a very sassy feature name in itself, so let’s break it down:

• Azure AD groups are a collection of user accounts in your tenant, with members or guests (users invited from another tenant)
• Groups can be either static (you manually pick the users) or dynamic (you define a rule on who gets to be a member)
• Now with this preview, the dynamic rule for group X can say “include everyone from groups A and B and C”

Why is this a big deal? Because being able to limit the number of different groups into which members need to be manually added is a great way to reduce the admin burden of access management. Instead of requiring business applications to each have their own groups to define who can use them, we can control them via rules. One group membership can open up access to several related apps and services. Groups can also be self-service since Microsoft Teams teams are really Microsoft 365 groups behind the scenes.

Can we use all these nice Azure AD features for managing access to our Power Apps and Dataverse environments, though? From the Dataverse release plan and Microsoft 365 Message Center, we can see that support for “Azure AD dynamic membership type group in Dataverse group teams” has recently become generally available:

What about nested groups? Ultimately, what we’d want to achieve is a single dynamic group that defines the user audience for our Power App. We configure this dynamic group only once for the app on the Dataverse side. The individual users then get managed over time on the Azure AD side via addition to and removal from organizational groups (examples A & B in the illustration below), following the normal day-to-day IT operations. No one needs touch the Power Platform specific tools as part of this process – not even remembering to add them to app user groups.

Could it really work? We can quickly validate this process by building our own demo app scenario that combines Power Apps, Dataverse and Azure AD groups.

Defining the dynamic group

First we launch the Azure portal and go under “Groups” in the Azure Active Directory blade. We’ll create a Microsoft 365 group with dynamic membership type (as opposed to assigned membership). Under the “dynamic membership rules” there’s a place to configure the rule:

Since nested groups are an Azure AD preview feature, the graphical tools for configuring the rules don’t yet support referencing other groups. In the documentation we can however see that the rule syntax is pretty easy to copy and adjust to our demo purposes. Just reference “user.memberof” and then paste in the GUIDs of existing Azure AD groups (non-dynamic).

When this rule runs, meaning the “dynamic rule processing status” field says “update completed”, we can check the members of the dynamic group. In our case they are a collection of internal FF user accounts plus one external guest account.

Unlike with nested assigned groups (non-dynamic), members from the referenced groups appear under “direct members”. If this was a static nested group, you’d see them under “all members”.

We’re all good on the Azure AD side now. Let’s move over to Power Platform next.

Environment security group

Since we are building a business critical app for managing confidential information, it is essential that we have a dedicated Power Platform environment for it. So, we launch Power Platform Admin Center (PPAC) and provision a new environment. As part of the environment creation dialog, we set the environment security group to be the same dynamic group we created a moment ago in Azure AD:

If you’re new to Dataverse based access management concepts, check out the demo scenario from my earlier blog post: How groups & teams work in Power Apps & Dataverse.

Building our app

Let’s go and design a model-driven Power App that leverages Dataverse for its data management. We’ll create a new custom table called “Secrets” to store our sensitive data. For the UI part, we can quickly generate a model-driven app by choosing “create an app” while in the Dataverse table browser:

We need one more thing for our solution to be ready for use: a security role that grants access to the new table. I’ve created a solution to host all the components of our Secrets Management demo. In there, I’ll add a new security role called “Secrets User”, tick all the privileges for our custom table (entity) and save it.

We now have these three required elements in our solution:

After creating the custom security role, let’s go and associate our Azure AD group with a Dataverse team. To do this we need to hop from the Maker portal into PPAC and manage the environment settings.

We open the list of teams, choose “create team” and use the type “AAD Office Group” to map our existing Azure AD dynamic group into this new Dataverse team. As part of the team creation dialog, we need to pick security roles, so let’s choose the standard “Basic User” role plus our custom role “Secrets User”:

The team has now been mapped, but no users exist there yet. This is normal, as the users are synced there on-demand when accessing the application.

We’ll again navigate back to the Power Apps Maker portal, which is where we control access to specific apps. Choosing the “Secrets Admin” model-driven app and “Share” opens up the dialog from where we can add our team. What we actually need to remember to do here is to associate the security role with our app, since model-driven app sharing works differently than canvas app sharing.

Accessing the app as a user

Our work as the app maker/admin is done. It’s time to switch to another non-admin user account, FF App Maker. This user has been included in our Azure AD dynamic group from a nested group. There is no direct assignment of environment access nor Dataverse security roles. Will it “just work”?

Yes, it does! The first time the user opens the app URL, the user account will be added as a member under the Dataverse team. It therefore also inherits any security roles associated with it, which in this case allows viewing data in our Secrets table via the model-driven app:

“Yeah, I’m sure it works great with model-driven apps running inside Dataverse, but we’re mostly using canvas apps…” Not a problem! Let’s generate a canvas app from the same Secrets table and share that to the same dynamic Azure AD group. Access is also granted to our user from a nested group in this scenario (it just took a couple of minutes longer to activate, though):

Both the canvas & model-driven app metadata as well as the business data of the application are managed in Dataverse. Thanks to the native integration between Azure AD groups and Dataverse, everything is now kept in sync.

Closing thoughts

The more apps your organization starts to have running on Power Platform, the bigger the benefits are from streamlining their access management. If you’ve only been using Dataverse based applications in your Dynamics 365 Sales, Customer Service and other classic CRM scenarios, it may not have been a big issue for IT to configure the access rights via specific steps in admin UIs when users are added or removed. How about when you have a hundred such applications instead?

An important area in improving your adoption maturity level of Power Platform is scaling the administrative operations to meet the growing number of apps in production use. You should guide the app makers away from direct sharing of apps & data sources to individuals and promote the use of groups instead. The group management process needs to be flexible enough to support this change in everyday use. Dynamic Azure AD groups with their ability to refence other groups (both security groups and Microsoft 365 groups) can be a great tool for this, especially when combined with self-service group management.

Dynamic groups are a feature that requires by minimum Azure AD Premium P1 license, which may be included already in your Microsoft 365 subscription. How about if you only have access to non-dynamic groups, yet want to use assigned nested groups in your Azure AD? The good news is, these static groups also appear to support the Power Apps and Dataverse access management features in the demo scenario, so the dynamic membership definition doesn’t seem to be a requirement.