Add support for nested groups in Azure AD (app access and provisioning, group-based licensing)
A lot of organizations use nested groups in on-premise AD. Syncronizing these groups to Azure AD have no value today. But the group itself have value on-premise
Creating new group in AD with only users and then synchronize it to Azure AD creates extra administration for administrators and confusion for end-users.
Dynamic Groups in Azure AD as of today don’t have support for “Member Of” or similar hence don’t solve the problem.
Adding nested groups to Azure AD would add a lot of value to Azure AD.
We’re currently evaluating an option that will provide the functionality offered by nested groups, but removes the complexity nested groups adds. We appreciate your patience on this ask and want to ensure we deliver a solution that benefits all of our customers. Below are use cases that we’d like for you to stack rank, with #1 being priority for you. We thank you for the continued comments and feedback.
Use case A: nested group in a cloud security group inherits apps assignment
Use case B: nested group in a cloud security group inherits license assignment
Use case C: nesting groups under Office 365 groups
Sweet, Jay commented
Nested groups to inherit rights/permissions assigned to parent groups.
Sean Decker commented
A is a our current requirement. B & C are nice to haves at this point
Peter Leahy commented
Our AD role base permission model is build on nested AD security groups and we're targeting Azure AD as our SSO and internal app identity provider.
I find it interesting that the graph API has a get TransitiveMembers call to return all members of an AD group traversing the nested groups, so there are mechanisms available to solve the issue.
This is a show stopper for us extending our rollout.
Kevin Hill commented
B, C, A. Please give us an update on this.
B, A, C. Any Update?
Søren Dalhoff commented
Azure AD Team (Admin, Microsoft Azure)
Any update regarding the evaluating?
A, C, B
C without a doubt C, though after that then probably B, then A
Use Case D: Cloud security group added to an on-premise group?
Robert Williams commented
B. We are still pretty new to using Azure, so we have one way of doing it and are sticking with it until we understand it better.
Would like to create a group that will do one thing: grant AAD licensing (specifically to recursive users), and nothing else. We would then add our ALL groups (which consists of smaller delineations of our user base) to this group. There could be two to four groups in-between the license group and the user.
Use case A. I'm not an Azure admin and so I am only allowed a small number of groups to be given application access. I want to use other existing AD groups representing a department or team that are nested under the AD group.
Sven Griep-Raming commented
I think it's use case A .. but this is our problem:
We want to give permission to PowerApps Environment through AAD Groups. We have one AD Group (Group1) synched from our on-premises AD for the users who should get access to the PowerApps Environment. Since we have some AAD only technical Accounts that also needs access to the PowerApps Environment and we can't put them in the synched Group (it's locked in AAD due the syncing) we created an AAD only Group (Group2).
Now we want to put Group1 as a nested Group in Group2 in AAD and give Group2 access to the PowerApps Environment.
But, as you might guess, the user in the nested Group don't get access to the PowerApps Environement.
My priority is use case A - to apply nested groups to enterprise apps.
Rank is: A, C, B
The problem with nested groups is that you can easily lose scope in terms of resource access. For example, if I create an AD security group (SG1), add users to the security group and ACL a share - no problem. However, if an LOB states, can you add my group (SG2) to your security group? Once that happens SG1 could lose its scope of the intended purpose of SG1 as SG2 could also include thier own set of nested groups. Now if we want to sync this group to AAD, the scope unintentionally broadens and could unintentionally provide access to unintended Enterprise App or an AAD\Resource role. Of course, with proper governance and automation you can manage this, but we know what happens when users move to other roles or organizations...
Nested groups should have been implemented day 1. They do not add complexity but ease management. I would not limit the use to certain functions/features but make them available for use across the board. I would also say that having to manage AD groups and Cloud only groups is a pain. If you have AD sync it should be able to either 1) Sync both directions or 2) intermix cloud and on-prem objects.
A, C and B
Chris Tout commented
My current greatest need is use case A - to apply nested groups to enterprise apps.
Ronald van der Meer commented
A, C and B
Burton Steele commented
Douglas Gamache commented
+1 for A, B, & C
Jack Siergiej commented
Just make this work like regular windows security for God's sakes!! If I add a nested group to my enterprise app permissions, I should get access to the app if I'm a member of sub group. Plain and simple!!!
Not having nested group support makes for a administrative nightmare and now creates two different management models.. One for on-prem and a second for the cloud. C'mon guys!!