2008-09-01

Groups and Group Nesting part 2

This is an attempt to enumerate the different Group Nesting Strategies and if applicable and notes on use. Based on what I have see so far, just because these strategies exist they do not necessarily represent a recommendation or best practice.


  1. UGLR/AGDLP

    Users > domain Groups > Local groups > Resources a.k.a. AGDLP user Accounts > Global groups > Domain Local groups > Permissions. From the Windows NT 4 days. See also http://en.wikipedia.org/wiki/AGDLP


  2. UGULR

    Users > domain Global group > Universal group > (Domain) Local group > Resource. Because of use of Universal group this requires Windows 2000 native or Windows Server 2003 domain function level.


  3. AGGUDLP

    user Account > Global group > Global group > Universal Group > Domain Local group > Permissions. As above because of use of Universal group this requires Windows 2000 native or Windows Server 2003 domain function level. See http://groups.google.ca/group/microsoft.public.win2000.active_directory/browse_thread/thread/aaa50100100b2a22/1d1da2dc528e14cb?hl=en&lnk=st&q=AGGUDLP+AGDLP+windows+site%3Amicrosoft.com#1d1da2dc528e14cb



Microsoft has broken down the topic like this [MS DaDDaSS ch15]:


  1. User/ACL

    * User accounts are added directly to ACL of Resource.
    * Does not scale well.
    * Usefull for sensitive Resources.


  2. AG/ACL

    * Account Group added directly to ACL of Resource.
    * More scalable.
    * Groups can be nested iif Windows 2000 native or Windows Serve 2003 domain function level.
    * More work for Resource owner/administrator if different groups require different access. Therefore more AGs added to ACL.
    * Even more work for Resource owner/administrator iif Windows 2000 mixed or Windows Server 2003 interm due to restrictions on group nesting.


  3. AG/RG

    * Account Group added directly to Resource Group. This implies obviously that Users are added to AGs and that RGs are added directly to Resources.
    * Scales better than AG/ACL.
    * Works well for groups of Resources such as printer pools.
    * Easier to revoke access. Domain administration rather than machine (computer) administration tools used.
    * Work could increase geometrically if many groups require different access. A new RG would be required fore every combination of Permissions per Resource.
    * Can be used independant of domain function level, especially if Windows 2000 mixed domain function level or ACLs are on Windows NT 4 machines (computers) --> see UGLR/AGLP above.


Throughout all of my studying and research into Active Directory one of the biggest questions I have had is why did Microsoft introduce Domain Local groups? Why not use local (machine) groups? I finally found the answer in the sub-section titled "Selecting Local Groups or Domain Local Groups as Resource Groups" [MS DaDDaSS ch15]:



  • For both AG/ACL & AG/RG you can select either Local (machine) Groups or Domain Local Groups for use as Resource Groups.

  • Domain Local groups can be managed anywhere in domain, but Local (machine) groups require access to the machine (computer) hosting the Resource.

  • Obviously, Domain Local groups are visible in domain whereas Local (machine) groups are not.

  • Group retirement is easier with Local (machine) groups because they disappear when the machine (computer) is decommisioned. Domain Local groups persist after machine (computer) is decommissioned therefore more work is required to ensure only the currently used groups are kept.

  • Security Access Token will be larger. Security Acess Token includes the groups to which the user account is a member, but also the groups to which those groups below to until all group membership is resolved. (I need to figure out if/how Local (machine) groups apply.)

  • Default maximum token size is 12000 bytes which can be changed. See Q327825.


The introduction of Security/Session/Access Tokens has got me researching this topic as well as PACs (Privilege Access Certificate). More later.

No comments: