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
Patton, Charlie commented
To add (or reiterate) an important use case for this: we are trying to move away from third-party tools for internal communication, but the lack of support for nested groups is a problem. We would like our top-level distribution group to be composed only of groups. Each user should be a member of only one "primary" group, which itself should be a member of the top-level group. Having to manage individual group memberships is error-prone and creates additional management overhead that is not required when using on-premises AD.
This is not a special feature, it is necessary functionality for access control management.
Wade Chandler commented
Interestingly I do see that it did create the sub-group in the SCIM application it just didn't assign the users to it which were not in the parent group.
Wade Chandler commented
Yes; this is really a big deal. One can add groups to a group as a member, but then when provisioning users SCIM does not then apply the users from the sub-groups to the provisioning and instead says it skipped them in the trouble shooting log because they are not assigned. It clearly sees they are members or are assigned, but decides not to assign them to a SCIM application because they are not assigned; very confusing. I only know this from reading the trouble shooting logs and then being totally confused and then found this issue which seems to suggest that what I'm seeing is a known issue. It makes it a real management/admin struggle.
Adrian Olives commented
I understand that AGDLP is just a guideline, but it'd make sense for products built by Microsoft to fit into that guideline.
Luis Chavez commented
This is your most voted request and there are several other request that are pretty much the same and already have hundreds of votes. If you merge all of them it will probably be ~3k+ votes, this is a must for AAD. It's been over 3 years since the idea was first posted, we all need this ASAP. People can't take full advantage of so many feature in Azure due to the lack of response on this request. Please make this a priority!
Nested groups would be an extremely valuable functionality when implementing role-based:
- access & provisioning to enterprise apps
- license assignments
- intune application distribution (this apparently does work?)
- collaboration and access control (this apparently does work)
Being able to use nested groups for these (and other) purposes would enable organizations to take advantage of the role-based approach. It would make administration much simpler and easier to understand.
Christoph Tost commented
Anytime a product group tries to release something that doesn't support nested groups, it needs to be denied immediately. Draw a line in the sand and don't allow this to happen anymore. This is a core requirement for role based access controls. These one-off functions that don't support using nested groups makes administration very challenging and increases risk.
We have pci requirements and compliance requirements for role based access. We absolutely need nested group support. Why is this not an extremely high priority.
My question is, why would this not be included? For large organizations with 84,000 + users and all the departments that access software how could this not be supported? If I add groups with tens or thousands of staff it causes issues because large groups take forever to add or remove. I constantly have to enable\disable the warning in AD Connect to allow large numbers of changes.
Bart Hoofd commented
This is a critical feature for design and control of Azure / Office365 features.
Uwe Grohne commented
Actually nested groups are working when assigning an aad app (like Azure App Proxy App), if all nested groups are security groups. Members of nested distribution groups will not have access.
Without this we cannot use our existing nested groups, so will consider OKTA.
I hope for more support
Andreas Hoferiter commented
Any news when the feature will come up?
This is much needed: 'App role assignment (assigning groups to an app is supported, but groups nested within the directly assigned group will not have access), both for access and for provisioning'
When will this be implemented?
Sujit Koduru commented
This is a must feature and is causing lot of applications to go through a churn. When you have added group based management for SaaS applications, allowing for nested group based management for SaaS application is very doable. lack of this feature is becoming an investigation hassle and management nightmare for org-wide applications.
You can use this feature only after you start an Azure AD Premium trial or purchase Azure AD Premium license plan. Group-based assignment is supported only for security groups. Nested group memberships are not supported for group-based assignment to applications at this time.