none
Nested Groups in Active Directory policy?

    Question

  • Does anyone have a policy on nesting AD groups within Active Directory?
    Deciphering someone's rights could be quite cumbersome!
    Does anyone just have a policy that states that each group represents a certain amount of rights?

    For example, if I had two shares, each with it's own group, wouldn't it be better to just put people into a proper group instead of nesting another group?

    Monday, June 29, 2009 4:45 PM

Answers

  • If you are looking for advice on whether to use group nesting or not, then the answer is the usual - "it depends"...

    In essence there are two common approaches:
    1) create a domain local group in the domain where the resource resides and add all users who need the same level of access to the resource directly to this group
    2) create a domain local group in the domain where the resource resides, then create a global group in each domain where there are users who need the same level of access to the resource, and finally populate each domain global group with accounts from the same domain (this actually is a remnant of the Windows NT approach, in which domain local groups did not exist)

    The problem with these two approaches surfaces once you start dealing with multiple domains. In particular:
    - in the scenario 1) the domain local group you created can not be used to grant permissions to the same group of users for a resource in another domain (since domain local group are not visible outside its own domain). This seems to favor the scenario 2)
    - in the scenario 2), you typically have another set of administrators managing (or at least having authority over) global groups in other domains, which gives them more control over access your resources than you might prefer. In addition - as you noticed - it becomes cumbersome to determine who actually has access to the resource. Finally, excessive group nesting can lead to token size problems.

    Note that another alternative would be the use of universal groups giving you advantage of their forest-wide visibility...

    hth
    Marcin

    Monday, June 29, 2009 5:53 PM

All replies

  • If you are looking for advice on whether to use group nesting or not, then the answer is the usual - "it depends"...

    In essence there are two common approaches:
    1) create a domain local group in the domain where the resource resides and add all users who need the same level of access to the resource directly to this group
    2) create a domain local group in the domain where the resource resides, then create a global group in each domain where there are users who need the same level of access to the resource, and finally populate each domain global group with accounts from the same domain (this actually is a remnant of the Windows NT approach, in which domain local groups did not exist)

    The problem with these two approaches surfaces once you start dealing with multiple domains. In particular:
    - in the scenario 1) the domain local group you created can not be used to grant permissions to the same group of users for a resource in another domain (since domain local group are not visible outside its own domain). This seems to favor the scenario 2)
    - in the scenario 2), you typically have another set of administrators managing (or at least having authority over) global groups in other domains, which gives them more control over access your resources than you might prefer. In addition - as you noticed - it becomes cumbersome to determine who actually has access to the resource. Finally, excessive group nesting can lead to token size problems.

    Note that another alternative would be the use of universal groups giving you advantage of their forest-wide visibility...

    hth
    Marcin

    Monday, June 29, 2009 5:53 PM
  • Thanks.
    Your email seems to suggest something that you don't actually say in writing.
    Nested groups, in your opinion, are utilized to give resources from one domain to another domain, and the alternative is within a Universal group.
    What my IT group is doing is creating a Supervisors group, and then putting groups inside of that, instead of putting each individual in a group.
    The first mentioned way sounds like it is non-advisable.

    Tuesday, July 07, 2009 6:24 PM
  • What type of group is Supervisors and what groups are nested in it? In any case, I don't believe that there is the "best" answer here - the design would need to be based on your envrionment and priorities...
    Keep in mind that Universal groups have their own share of "issues" - such as forest-wide replication scope (although that's considerably improved with LVR) and visibility (i.e. inability to contain objects other than those from their own forest)

    hth
    Marcin

    Tuesday, July 07, 2009 6:54 PM
  • Thanks for taking the time to think about this with me.

    Let's say my supervisors are supervisors - and the nested group is an application.  My concern that veiwing the supervisor group and comparing it to a list of supervisors is easy - but if someone that isn't a supervisor gets into the application, or worse yet another group gets put in the the application group, my monitoring by SIM of the supervisors group is not worthwhile.

    Thursday, July 09, 2009 12:50 PM