How can we improve Azure Active Directory?

← Azure Active Directory

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.

2,011 votes
Sign in
(thinking…)
Sign in with: Microsoft
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close

We’ll send you updates on this idea

Michael shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
started  ·  AdminAzure AD Team (Admin, Microsoft Azure) responded  · 

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

Show previous admin responses (4)

416 comments

Sign in
(thinking…)
Sign in with: Microsoft
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Peter Leahy commented  ·   ·  Flag as inappropriate

    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.

  • Robert Williams commented  ·   ·  Flag as inappropriate

    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.

  • Jake commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Chris commented  ·   ·  Flag as inappropriate

    My priority is use case A - to apply nested groups to enterprise apps.

    Rank is: A, C, B

  • Anonymous commented  ·   ·  Flag as inappropriate

    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...

  • Anonymous commented  ·   ·  Flag as inappropriate

    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.

  • Jack Siergiej commented  ·   ·  Flag as inappropriate

    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!!

← Previous 1 3 4 5 … 20 21

Azure Active Directory: SaaS Applications

Categories

Feedback and Knowledge Base

(thinking…)
Hosted by UserVoice