Skip to content

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:

After this environment provisioning is completed, none of our security group members can do anything in the environment yet. That’s because we haven’t given them any security roles within the environment. We’ll get to that in a later step. The environment security group membership is merely the prerequisite of getting into the environment as a user.

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.

administrationAzure ADDataversegovernancePower Appssecurity

11 responses to "Dynamic, nested Azure AD groups and Power Apps access management"

  1. What happens if I want to have a ,let’s say, “All Company Users” dynamics group not to grant access to the app but rather to assign “Basic Roles” like Basic User and Flow_RP once for all? and then leave the access to the single app to more restricted groups so that I do not have to remember every time to assign such common basic roles?
    It seems it does not work.
    And this is probably because the Dynamic Team has never the chance to sync with AAD as the user is leveraging the more restricted group to access the app and the “All Company Users”.
    Does this make sense? Is there a way to force the refresh of the group in such a scenario?

    1. I used another team which already contains all the users in the environment. it is named after the parent business unit. It seems a much more convenient approach.

  2. Hi Jukka ,

    How does it work if we have multiple AD Groups linked to respective BUs with different Security roles? we create dynamic group and make others members, but while sharing the app, does sharing only with dynamic group will provide users respective roles inherited from respective ad groups?

    1. Rakesh, in your scenario have you first created all the non-dynamic Azure AD groups as group teams in Dataverse? And then you use a single dynamic Azure AD group to share app access? I believe once the user is created in the environment, the user record should become a member of all the group teams to which it belongs to on the AD side. Through this team membership their security roles should therefore also be in effect. It’s not a scenario I have specifically tested but it would seem strange if some groups would get syncronized and others not.

  3. do you notice a significant lag time (> 8 hours) between an update in the dynamic group’s membership and the effect in dataverse?
    If I add or remove a user (i.e. adjust the rule) in a dynamic security group in Azure, and I check the membership to see it’s correct in Azure, changes to the user’s access in Dataverse can take more than 8 hours to sync up. Dataverse permissions do update, correctly, but it will be hours and hours after the membership change.

    1. Yes, many people from the Power Platform community have been complaining about these delays to Microsoft. I’m not sure if this is something MS is in the process of fixing as it’s been an issue for such a long time.

  4. Hi Jukka,

    Thank you for all your rich and detailed articles!! I’m testing on my side to setup the dynamic nested AD group, wondering why you created the parent group using O365 group type?
    “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:”

    1. I’m glad you’ve found the articles useful, Shin! As for the group type, I don’t think it makes a difference in this scenario. I just happened to pick the Microsoft 365 group type since I wanted to test that they’re also covered by this functionality.

  5. Hi Jukka,
    Thanks for your prompt reply, At Azure AD, I also noticed after adding nested groups to parent group (dynamic AD group), I see all individual members from nested groups under direct members and all members tabs, I do not see the nested groups showing anywhere, did you experience the same? is it also due to the delayed from AD?

    1. You will not see the groups themselves there since Microsoft “fakes” this by syncing the members in there. The nested groups aren’t really part of the parent group, they are just a query criteria that Entra ID (formerly Azure AD) uses to retrieve the member users into it.

Leave a Reply

Your email address will not be published. Required fields are marked *