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 continuing to investigate options for adding this support. There are technical challenges to overcome in order to make this happen. We thank you for all your valuable comments so far, and welcome any additional feedback you have on what are the most important use cases involved with these scenarios.
We need nested groups to organize our devices. Nesting dynamic groups are even more necessary since we cannot provision device groups in Azure. Automated and self-service processes are limited and greatly increases administration overhead and user down time. Explicitly assigning applications to device groups is very tedious especially with limited iOS attributes leveraged by dynamic group memberships. We have 30 various departments across 48 sites with organizational, site, department and program budgets. We have over 30 thousand devices with hundreds of apps. We have months invested attempting to replace AD provisioning (leveraged in other MDMs) using dynamic groups . Please work on nesting dynamic device groups and all dynamic groups.
Public Company Azure User commented
Is there any way that this can be addressed? Amazon and Google don't seem to have issues with nested groups.
We could really use this as we are considering to move from on premise to azure. However our RBAC for company is based on nested groups. The sooner the better. And all other features which AAD can't do versus AD.
Tom Giberius commented
I also want to add licenses to nested groups.
I certainly do not want to use hard coded powershell scripts to solve this issue of not supporting nested groups.
Tom Giberius commented
I certainly want nested group. We build up an AAD Group BusinessFunction-X from many other AAD Groups for application roles, file shares, shared mail boxes, etc. So we use nesting heavily. If we cannot use this nesting then I would need to go back to solutions like Okta. This is not want you want. You want a full grown AAD product and a full grown AAD User Provision Service for user provision.
this explains why a lot of my conditional access policies were not working since I was basing it off nested groups. This is baffling that it's not supported especially when on premise AD does this.
Brett Hinton commented
Agreed with the many other comments, support for nested groups is essential. Why dynamic groups is a nice feature and addresses some use cases that nested groups solve, the limited attributes means it can't always provide the same capabilities that nested groups does.
Based on the limited attributes that are available in Azure AD, it's often difficult to filter these groups in the cloud. The ability to aggregate our existing, meaningful on-premise groups is a priceless feature.
The simple use-case in our enviremont would be to use our on-premise nested groups representing our own role based access control. We got role-groups describing users roles, nested into configuration groups.
It would be a great benefit if all the settings belonging to a nested role-group would work ootb, for example Intune settings, assigning licenses etc.
Right now, we're accomplishing this through powershell-scripts recursivly reading group-memberships and adding the members to new pseudo-groups.
Julian Pawlowski commented
Thanks, this is highly appreciated!
I can imagine that while it looks like a simple change, it is more difficult to implement that on a larger scale thinking about performance impacts when determining group memberships. It surely is not a simple one-liner of Powershell code because we're not in an on-premises environment with limited numbers of users only. Having the right performance here is what customers expect to it is totally valid to say that you need to think about the right way to do it :-)
David Pattie commented
What a joke response. I first commented on this over 2 years ago, it's got over 500 votes.
To blame technical challenges is farcical, we're talking about the enumeration of group nesting which is one line of powershell. TRY HARDER
How can this not be considered a major feature gap for App role RBAC?
What's the point of App configured RBAC if your service has to perform its own group lookup to work around this?
All of AWS's directory services honor and support nested groups. You claim to be the cloud leader?
Taklemakam Baf-ikybaf commented
Guys, its almost end of 2018 and still no full support for group nesting! We still have to use scripts to put "unnest" groups but this is SO LAME!
Claudio Rifo commented
+100 for licensing based on nested groups.
+50 for App role assignment
+1 vote nested group for access
Rob Traynere commented
Came here to up-vote for licensing based on nested groups.
Same issue here, We are a big company where we want to give access to license based on migration steps. In stead off add users to 4-5 groups we want to add them to one migration group witch gives the user Right GPO, Right Licens, Right Application in SCCM. But this is NoGo with MS that dosn't support their own AD features.
Same issue here, We are a big company where we want to give access to license based on migration steps. In stead off add users to 4-5 groups we want to add them to one migration group witch gives the user Right GPO, Right Licens, Right Application in SCCM. But this is NoGo with F"#¤"¤ MS that dosn't support their own AD features.
don't fall for all these requests for nesting. Look at how much of a mess everybodies on prem AD ended up, don't let them do the same to themselves in Azure.