Please Read: Significant Update Planned, Migrating Forum Software This Month

See more
See less

group strategy

  • Filter
  • Time
  • Show
Clear All
new posts

  • group strategy

    i didn't understand the entire group strategy methods...
    how & when to use what?
    i have the microsoft book... but can't understand this issue at all.
    can someone explain

  • #2
    Can you please explain your post a bit more. Do you want to know about Group policy?
    Server 2000 MCP
    Development: ASP, ASP.Net, PHP, VB, VB.Net, MySQL, MSSQL - Check out my blog

    ** Remember to give credit where credit is due and leave reputation points sigpic where appropriate **


    • #3
      Group Strategy ? What do you mean ?

      I've never heard of this so I might be in the same boat as you !!

      * Shamelessly mentioning "Don't forget to add reputation!"


      • #4
        Are you talking about security groups ? domain local, domain global, universal ?
        Guy Teverovsky
        "Smith & Wesson - the original point and click interface"


        • #5
          Originally posted by guyt
          Are you talking about security groups ? domain local, domain global, universal ?
          yes guy.
          how to use what & where...


          • #6
            Lets see...

            The security groups can be differentiated by scope and type. Currently two group types exist:

            - security
            - distribution

            The difference is that security groups can be used to protect file/system/AD objects by applying ACL to those groups, while distribution groups are used for communications (i.e.: send email to a list of users)

            Now to the scopes:
            - computer local groups (not AD objects)
            - domain local
            - domain global
            - universal

            All those are described fairly well at the following link:

            Now the question that is confusing: how do I use those ?
            First of all you need to understand that there is no single answer to that question. Microsoft for quite a while were advocating the rule of thumb:
            A => G => U => DL <= P
            Accounts go into Global groups, Global groups go into Universal, Universal are placed in Domain Local and Domain Local are used for Permissioning (ACL).
            Now, though this is appropriate as a general guideline, there are some issues with this approach, so let's try to figure out what is best by examining the specifics of each group:

            Assuming we have a forest with 3 domains:
            RootDom - forest root domain
            ChildA - child domain #1
            ChildB - child domain #2

            Domain Local Group (DLG): the group can contain security principals only from the domain the group exists in. So if you have Domain Local group "ChildA\dlgGroup1" it can host only accounts from ChildA domain.

            The group though CAN be used to protect objects in other domains in the forest (or in a domain outside the forest, assuming that the trust exists). This means i.e. that I can put it in the ACL of a folder on ChildB\Server1

            Domain Global Group (DGG): the group can contain security principals from anywhere in the forest (and trusted domains outside the forest). This means that ChildA\dggGroup2 can have accounts from ChildB and RootDom.

            The group though CAN NOT be used outside the domain it exists in.

            Universal Group (UG): Was introduced in W2K. You have to be in at least W2K native mode to use it. At first glance it resolves all the limitations of the previous two groups:
            - it can contain objects from anywhere in the forest (ChildA\ugGroup3 can contain account from ChildA, ChildB and RootDom)
            - it can be used anywhere in the forest (you can protect a folder in ChildB using ChildA\ugGroup3)
            There are though some drawbacks when using Universal groups - UGs are stored in the Global Catalog and contain all the DNs of it's members (sometimes making the object, representing the UG, quite big) , which means that any change to UG is replicated to ALL GCs in the forest. When you are dealing with single domain forest this is not an issue, but in multi-domain forests this causes a relatively huge replication overhead (reduced by W2K3 LVR feature). Consider the following situation:
            You have UG ChildA\ugGroup4 which contains accounts only from ChildA. This means that the group object will be replicated to ALL GCs in the forest, while this is useless (you could use DLG ChildA\dlgGroup5, which would do the same thing but will not be replicated outside the ChildA domain).

            First lets try to understand how the groups are discovered and expanded during the logon process:
            User ChildA\Bob logs on to computer ChildB\cmpGuest01. As you might already know, the group membership is expanded by the means of Kerberos ticket the user obtains during the logon, while the group expansion starts on a DC the account resides in:
            - Bob sits down on ChildB\cmpGuest01 and logs on using ChildA\Bob account
            - Bob's credentials are passed to ChildA\DC01 and verified.
            - ChildA\DC01 looks at memberOf attribute of ChildA\Bob account and expands all the Domain Global groups and adds the list of those global groups to Bob's ticket
            - ChildA\DC01 expands the list of all Universal groups and adds the list of resulting groups to the ticket (note that Universal groups can contain Global groups, hence at this stage not only the Universal groups can be added tho the ticket)
            - The ticket is forwarded to ChildB\DC02 which performs the same steps and can contribute more Global and Universal groups to the ticket.
            - Finally ChildB\DC02 expands the list of Domain Local groups from ChildB domain (those groups are known only by DCs in ChildB domain) and adds those to the token.

            So some conclusions:
            - DGGs and UGs folllow you when you travel throughout the forest.
            - DLGs only from the computer's domain are added to the token (!).
            - The nesting of groups is a direct result of the way the groups are expanded: a group can have as a member any other type of group that has already been expanded
            - A DLG may contain DLGs from the domain where the group is defined, UGs and DGGs from any domain, and principals from any domain.
            - UG may contain UGs and DGGs and domain principals, all from any domain
            - DGG may contain DGGs and principals from the domain where the group is defined.

            So what we have meanwhile ?

            In case of single domain forest in W2K Native mode (and up):
            - you can either use only Universal groups (but if you are thinking ahead and know that some day your environment can change (new domain in the forest, new trust, etc..), you will try to avoid this approach.
            - you can use the rule of thumb (A => G => U => DL <= P), but you can safely skip the use of Universal groups for the time being. You can actually skip even the use of DLG or DGG and choose one of the following:
            A => G <= P
            A => DL <= P

            Multiple domains in a forest:
            Here things get a bit more complicated.
            Several approaches can be applied:

            1) Use the rule of thumb: A => G => U => DL <= P
            Cons: hard to manage and the nesting level is quite confusing. When protecting objects, sometimes you need to delegate the administration of the security group to someone and in this case you will need to delegate more than one group (which in turn would cause confusion, hence the process is error prone)

            2) Get away without Universal groups:
            A => G => DL <= P
            This is very similar to NT4 security model. You can look at it the following way:
            DGGs define roles
            DLGs protect resources

            Assistants need read only access to faxes.
            Managers need read/write to faxes.
            Faxes have a read only group.
            Faxes have a read/write group.

            Managers belong to dggManagers DGG.
            Assistants belong to dggAssistants DGG.
            FaxManagers DLG gets read/modify privileges.
            FaxUsers DLG gets Read privilege.

            The pros are obvious: the logic is simple and it's quite easy to manage.
            Cons: when you need to grant access to \\\Share to users from outside ChildA. In this scenario you can not use DGG from ChildB or RootDom, hence you might end up with either adding DLG from another domain or create Universal group.

            Despite the limitations this is probably the most common approach.

            3) Use only Universal groups.
            Well... This will probably work for small ADs that are not geographically dispersed. Otherwise the replication would kill your WAN and will greatly increase the GCs partition size.
            Guy Teverovsky
            "Smith & Wesson - the original point and click interface"


            • #7
              ooh... thanks man


              • #8
                3) Use only Universal groups.
                Well... This will probably work for small ADs that are not geographically dispersed. Otherwise the replication would kill your WAN and will greatly increase the GCs partition size.
                Let me take an unconventional point of view for the sake of the argument.

                Assume your forest runs in W2003 native mode, so we have attribute-level replication for group membership. So replication is not the issue it was before, not by a long shot. Also consider that modern hardware can easily accomodate a large forest with 10,000's of users. Additionally, GC size is only a factor with multiple large domains. So why not use just Universals then? No more worries about group scope and nesting properties!


                • #9
                  There are some interesting issues with Universal groups in multi-domain environments...

                  Lets look at Universal distribution group.
                  Suppose we have ChildA\ugDistList1 and it contains members from all the domains in the forest.
                  We also have ChildA\Bob who has permissions to edit the membership of the group above.
                  One day Bob flies from US (ChildA domain) to Europe (ChildB domain) and logs on to the network from ChildB\cmpGuest.
                  Bob opens Outlook and sees a request to add ChildA\Alice to ChildA\ugDistList1. What does Bob do ?
                  Bob clicks the "To" button and locates the ugDistList1 group. He double-clicks it and adds Alice to the member list. Bob closes the dialog and sends his meetings summaries to the DL. Alice does not recieve the mail...

                  So what happened here ? Outlook uses GCs when dealing with DLs and uses NSPI for DL administration. GCs being also DCs have a *read only* copy of all the objects in the forest and a writable copy only of the domain they reside in. So when Bob added Alice to the DL, the request was passed to the GC in ChildB domain. The GC tried to update a group from ChildA domain and silently failed as ChildA partition it has is read only.
                  I admit the Universal groups can save a lot of administrative work, but not all AD aware applications are capable of dealing with UGs correctly.
                  Guy Teverovsky
                  "Smith & Wesson - the original point and click interface"


                  • #10
                    SpyD, since you can read Hebrew, why not read this:


                    Daniel Petri
                    Microsoft Most Valuable Professional - Active Directory Directory Services
                    MCSA/E, MCTS, MCITP, MCT


                    • #11
                      that was great daniel!
                      much clearer...

                      hmm, ok, i'm doing the project,
                      but get stuck every 2 steps i make.
                      (creating user account post... gpo stuff)


                      • #12
                        Hi Guy,

                        I agree, that's a bad design flaw in exchange and outlook. This is one case where you can really tell that the AD and Exchange guys are on different teams.

                        Seriously, I have some more arguments pro and con in addition to the points you made. Note that Universals only make sense in a multidomain environment. In one domain you could get away with DG's only.

                        - using universal groups keeps the nesting level down. An important advantage for administration.
                        - can be nested any which way you like.
                        - can resolve membership in the local GC, even if the source domain is far away.

                        - increases the size of the access token. I have actually had one case where this was a problem. The affected user could not log on anymore.
                        - always goes to a GC to resolve membership, even if the local DC is from the same domain. Not nice when the local DC is not a GC.


                        • #13
                          Good points, wkasdo...

                          btw, any idea if Universal Group Caching can work across forest boundaries (forest trust) ? I'd bet that it can't, but I am not able to find any documentation on the topic.

                          So are you saying that UGs take more place in the token than GGs ? The only explanation I can think of would be that when populating the token only the group's RID of GG is used, while in the UG's case the whole SID is placed in the PAC.
                          Guy Teverovsky
                          "Smith & Wesson - the original point and click interface"


                          • #14
                            Hi Guy,

                            The token argument holds only for the DL groups from other domains. Those are not added to your token. In the usual nesting procedure of A -> DG -> DL -> resource, that saves you all DL's in other domains.

                            btw, any idea if Universal Group Caching can work across forest boundaries (forest trust) ? I'd bet that it can't, but I am not able to find any documentation on the topic.
                            No bet! I cannot imagine that a GC would cache groups of other forests.