locked
Normal and Maximum depth of nested groups in Active Directory ( LDAP in general ) RRS feed

  • General discussion

  • What would be the normal depth of nested groups in Active Directory?  LDAP in general? 

    What would be the maximum depth of nested groups in Active Directory?  LDAP in general?

    I have found in most examples and even on some of our servers that the normal depth of nested groups is about 5. 

    Server -> Domain Name -> Organization -> Organization Unit -> User

    Do scenarios actually exist in which we could see this:

    Server -> Domain Name -> Organization -> Organization Unit 1 -> Organization Unit 2 -> Some Other Qualifer 1 -> Some Other Qualifier 2 -> ... -> Some Other Qualifier X -> User

    where 'X' could be 10 or 20 nested groups deep?


    toolmania1

    Wednesday, September 19, 2012 3:08 PM

All replies

  • On Wed, 19 Sep 2012 15:08:23 +0000, toolmania1 wrote:
     
    >What would be the normal depth of nested groups in Active Directory? LDAP in general?
     
    The only answer to that is "it depends".
     
    >What would be the maximum depth of nested groups in Active Directory? LDAP in general?
     
    I don't know that there is any limit. LDAP has nothing to do with in
    any case.
     
    >I have found in most examples and even on some of our servers that the normal depth of nested groups is about 5.
    >
    >Server -> Domain Name -> Organization -> Organization Unit -> User
    >
    >Do scenarios actually exist in which we could see this:
    >
    >Server -> Domain Name -> Organization -> Organization Unit 1 -> Organization Unit 2 -> Some Other Qualifer 1 -> Some Other Qualifier 2 -> ... -> Some Other Qualifier X -> User
    >
    >where 'X' could be 10 or 20 nested groups deep?
     
    "Could" it be? Sure. Do you allow it? That's up to your admins, I
    suppose. How groups are structured usually depends a lot on how the
    company is structured.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Wednesday, September 19, 2012 3:41 PM
  • Thanks for the reply. 

    I just wanted to be aware of any anomalies that could occur with bizarre / extreme structures so that we know what to test.  I really doubt this will happen because how many sub departments can you have in a real organization?

    Here would be a blown out of proportion example to illustrate why I ask about the maximum level depth:

    Baseball -> Teams -> Yankess -> Players -> Pitchers -> Right Handed -> Under 40 -> Over 6 feet tall -> With a good curve ball -> etc.

    Even in that example, the categories used for each nested group starts to get ridiculous.  So, maybe this discussion is pointless...lol.


    toolmania1

    Wednesday, September 19, 2012 3:56 PM
  • On Wed, 19 Sep 2012 15:56:09 +0000, toolmania1 wrote:
     
    >I just wanted to be aware of any anomalies that could occur with bizarre / extreme structures so that we know what to test. I really doubt this will happen because how many sub departments can you have in a real organization?
     
    Hmmm . . . Here's seven without really trying:
     
    ..All users
    ...Asia
    ....China
    .....Province
    ......City
    .......Building
    ........Floor
     
    I've seen some pretty, errr, creative group structures over the years.
    :-)
     
    >Here would be a blown out of proportion example to illustrate why I ask about the maximum level depth:
    >
    >Baseball -> Teams -> Yankess -> Players -> Pitchers -> Right Handed -> Under 40 -> Over 6 feet tall -> With a good curve ball -> etc.
    >
    >Even in that example, the categories used for each nested group starts to get ridiculous. So, maybe this discussion is pointless...lol.
    >
    >
    >toolmania1
     
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Wednesday, September 19, 2012 4:23 PM
  • Ya, I see your point.  Good to know also from your first hand experience.  We will prepare for such structures then.  Thanks!

    toolmania1

    Wednesday, September 19, 2012 5:03 PM
  • I know this is an old Q, but...

    Despite the title of the topic, everything spoken of within the discussion has had nothing whatsoever to do with nested groups.

    The examples shown all are x.500-directory-hierarchy-related.  An OU is not a Group, it is an x.500 hierarchy attribute. 

    A group is a security principal.  In Active Directory, a directory hierarchy level is not a security principal - meaning you cannot derive permissions from an OU object, for example.

    The FQDN of an object is not a list of nested groups.  Group nesting in AD is based on the member/membership attributes of the group member objects, and because groups can be members of groups, you thereby get "nested groups."

    The authorization mechanism has to recurse groups the first time around to determine whether the ACL gets updated with specific permissions for the user.  Following best practices, the domain local group that grants permissions to the resource gets its member list recursed, through the hierarchy of group nesting, until it reaches the user objects which are within that set of nested groups, and if the user attempting access isn't member at any point along the nested group recursion, they don't get those permissions granted by the Domain Local group at the resource end of the recursion.

    That process doesn't care if the groups each are all in different OUs and the user is in yet another OU, and it doesn't care if you move any of the objects from one OU to another - those OUs and any other directory containers do not confer any permissions - it's just that members - member of linkage through the group nesting that matters.  You can't make an OU a member of a group, so it cannot be part of a nested-group recursion hierarchy. 

    Stop thinking of directory containers as groups.  Once you're past the builtins of the hierarchy, all those containers you add are simply for sorting the objects for ease of administration.  The only OS that allowed the x.500 structure to act as security principals was NetWare, and I would guess that OES continues with that security paradigm.

    In one specific case, you might actually confuse an OU with a group in AD, and that's when you apply "group policy" to a container.   Just because the name of the service is "group policy" does not mean a directory container is magically a group, however.  It's still a container - a convenient way of categorizing objects.

    Wednesday, March 9, 2016 7:34 PM