Nested Entra ID security groups

[NnjTrtl]

As the Environment security group can only be a single group, I think it is relevant to use a nested Entra ID security group as the Environment security group, in order to include multiple Entra ID security groups.

(By nested group I mean a group where the group members themselves are groups, and these child groups can themselves have child groups as members. So it is like a multi-level hierarchy of groups, and the idea is to use only the top group as the Environment security group. The actual users - people - are only direct members of the groups in the lowest level of the hierarchy.)

This way, any user which is not member of any group in this hierarchy ("pyramid") of groups, will not have access to this Dataverse environment. (Or is it Power Platform environment?)

So it's like a first barrier, and more fine-grained control can be added by using security roles.

When I apply this top group as environment security group, I get a warning message saying I am not member of the group and will not have access to the environment. But I am member of a child group in the hierarchy, so I don't know why I get this warning message. Anyway, after I applied the group, I still have access. So the warning message seems like a bug? Or am I missing something?

Can I share apps and security roles directly with users, and with other security groups (groups which are not member of the nested hierarchy)? As long as the users are member of both a group in the nested hierarchy (environment security group) and they are also member of another independent group which I grant access to a security role and an app, will it work?

This seems to be working based on some small testing I did, but I got confused from the warning message and the Microsoft docs describing the use of nested groups.

[AlbertoCastro]

Hi,

this is a correct practice of use security groups of environments and child groups to share apps or assign security roles but there is a limitation:

only it works with one level of child groups.

If you have an user in group A that is child of other group B that is child of the security group of the environment, the user is not able on the environment.

Maybe is this your case?

[NnjTrtl]

Thank you @AlbertoCastro,

I think actually it's working with more levels. I can check how many levels we have in the coming week.

Is there any documentation which tells about how many levels of nested groups are supported?

To me it seems like it's working fine, I'm just confused by the warning message I got when I selected the environment security group. The warning message said I won't have access to the environment because I am not member of the group. But I am member of a child or grandchild group. And I still have access to the environment after applying the environment security group, even if the warning said I won't have access if I select this environment security group.

[NnjTrtl]

I tested with an environment security group containing 5 levels of nested groups, and it seems to be working, but I get the warning message telling me I won't have access to the environment. But I do get access so it seems to be working fine. I am in the bottom group (great-great-grandchild group).

It seems to me the warning message is a "false positive" error.