locked
What are the downsides of using nested security groups? RRS feed

  • Question

  • I understand that using nexted security groups is not recommended.

     Note:

    For ease of security management, the following items are not recommended in managing Active Directory groups.

    • Assign permission levels directly to Active Directory groups.
    • Adding security groups that contain nested security groups, contacts, or distribution lists.

    However, Kelly Chen and others say that they are supported.

    Nested AD groups are supported in SharePoint.

    From your narration, I have a test on my local server through grant permissions to add the three AD groups to SharePoint, and then I add the top level AD groupC to one SharePoint group, then the user will have all the permissions from the groupA,  groupB, groupC and the SharePoint group. You could have a check again.

    So, I have two questions -

    1. What is the downside of using them and how can they break something?
    2. And to Kelly Chen specifically, if you have to add the three AD groups to SharePoint anyway, what's the point of then adding the the top level group again to the specific SharePoint group. In this particular example, all of the groups have the same permissions, so why not just add them separately to the SharePoint group? When you say you added the three AD groups to SharePoint, are you doing something differently than adding them to the site in question?

    Any help will be greatly appreciated. I'd love to use them as it and not break them down into their components.

    Thanks,

    Andrea

    Tuesday, March 12, 2013 9:10 PM

Answers

  • Downsides to using security groups:

    However, using security groups in SharePoint sites does not provide full visibility of what is happening. For example, when a security group is added to a SharePoint group for a specific site, the site will not appear in the users’ My Sites. The User Information List will not show individual users until they have contributed to the site. In addition, security groups with deep nested structure might break SharePoint sites.

    For groups that contain multiple levels of nesting and contain many users it can be difficult at a glance to see if a user has access to a particular resource. With Windows/Active Directory you could use the Resultant Set of Policy (RSoP) to determine if a user would have access to a securable object but such functionality is not present out of the box with SharePoint.

    From my understanding of what was written in the other thread, this is the setup of the groups:

    User A is a member of Group A is a member of Group B is a member of Group C (User A -> Group A -> Group B -> Group C)

    What the original poster is seeing is when granting access to Group C, SharePoint doesn't show User A as having access. But they do have access because they can access the content. This is what I was referring to above about the RSoP -- SharePoint won't drill down the groups to report whether a user has access.

    As to your second question, you would add Group C if it contains other users and groups besides Group B. To put it another way, just because Group B is a member of Group C doesn't mean Group C doesn't have more members.


    Jason Warren
    Infrastructure Architect

    • Marked as answer by Andrea Foote Wednesday, March 13, 2013 5:53 PM
    Wednesday, March 13, 2013 12:47 AM

All replies

  • It looks like you are referencing this Forum thread: Are Nested AD groups supported in Sharepoint 2010?

    The page Trevor Seward linked to in that thread explains the pros/cons and provides guidance on deciding whether to use security groups or not. See Choose security groups (SharePoint Server 2010).


    Jason Warren
    Infrastructure Architect

    Tuesday, March 12, 2013 10:18 PM
  • I've read it and plan on using security groups. The question is specifically about nested security groups which isn't addressed in the article or the white paper also referenced.

    Thanks,

    Andrea

    Wednesday, March 13, 2013 12:20 AM
  • Downsides to using security groups:

    However, using security groups in SharePoint sites does not provide full visibility of what is happening. For example, when a security group is added to a SharePoint group for a specific site, the site will not appear in the users’ My Sites. The User Information List will not show individual users until they have contributed to the site. In addition, security groups with deep nested structure might break SharePoint sites.

    For groups that contain multiple levels of nesting and contain many users it can be difficult at a glance to see if a user has access to a particular resource. With Windows/Active Directory you could use the Resultant Set of Policy (RSoP) to determine if a user would have access to a securable object but such functionality is not present out of the box with SharePoint.

    From my understanding of what was written in the other thread, this is the setup of the groups:

    User A is a member of Group A is a member of Group B is a member of Group C (User A -> Group A -> Group B -> Group C)

    What the original poster is seeing is when granting access to Group C, SharePoint doesn't show User A as having access. But they do have access because they can access the content. This is what I was referring to above about the RSoP -- SharePoint won't drill down the groups to report whether a user has access.

    As to your second question, you would add Group C if it contains other users and groups besides Group B. To put it another way, just because Group B is a member of Group C doesn't mean Group C doesn't have more members.


    Jason Warren
    Infrastructure Architect

    • Marked as answer by Andrea Foote Wednesday, March 13, 2013 5:53 PM
    Wednesday, March 13, 2013 12:47 AM
  • Thanks, Jason. That was helpful.

    Andrea

    Wednesday, March 13, 2013 5:54 PM