Hi Edward, 
 
 
 
I think your description of the difference between types of AD groups is accurate; but it is incomplete in that it does not explain why there would be different types of groups anyway, or what you should use them for. 
 
 
 
Let's try a short indication: 
 
 
 
To give users access to resources/objects, you could in principle put user accounts directly into the ACL's of the objects (files, printers,...) they need to use. 
 
Because of the number of users and objects in any non-trivial organization this would lead to an administrative nightmare. 
 
That is why security groups were introduced, as a kind of "in-between" between accounts and resources, to be able to organize things a little. 
 
 
 
Global Groups might also be called "Account Groups". 
 
They exist in the same domain as the (mostly user) accounts they contain, and can be grouped / nested among themselves (within their domain). 
 
Without forming cycles of course. 
 
 
 
(Domain) Local Groups might also be called "Permission Groups". 
 
They are used in the ACL's of all kind of objects (files, shares, printers, ans so on) to offer read, use, fullcontrol, ... access to the object. 
 
They can also be grouped and nested within the same domain. 
 
 
 
In order to authorize users to use resources, links (memberships) between Global (User) Groups and Local (Resource) Groups must be established. 
 
1) If there is only one domain involved, this can happen directly: make some global groups member of some local groups, and you're ready. 
 
2) If the users live in another domain than the resources they need, there are 2 possibilities: 
 
 
 
* There is sufficient trust between the domains:  
 
Then the global groups from one domain can be member of the local groups of the other domain. Ready. 
 
 
 
* There is not sufficient trust (or the trust relations would be to difficult to maintain): 
 
Then you use Universal Groups as the linking pin between globals and locals. 
 
These Universal Groups do not really belong to a specific domain, they live in the forest. 
 
 
 
I know Windows does not really enforce the approach described, you can deviate from it in different ways, but as far as I know this is the way it was meant to be used. 
 
 
 
Hope this helps.  
 
 
 

Jacque, that is excellent, thank you.

Good.. i got sme ideas

Well.. i found that global group cannot be a member of global group of the same domain

Perhaps it's more clear to explain the name. The name is where you can apply them (e.g. use to permission something) 
 
 
 
Domain Local Groups 
 
Can be used to permission only objects in the same domain (and so named local)!! however can contain e.g. users from give or take a bit anywhere 
 
 
 
Global Groups 
 
Can be used to permission things anywhere (and so named global), even outside that domain, the drawback is that you can only add members\objects into it from the domain it is based in 
 
 
 
Universal Groups 
 
With some limitations can be used to permission anywhere and contain members from anywhere (called universal), but there are serious complications regarding the global catalog, logons not possible if G.C. unavailable etc, so not the great solution for everything, use with care

If we are saying that Global Groups and Universal groups can be used to assign permissions to resources, why do we need to add them to the Domain Local Groups then or precisley why is it the recommended way? Why can't we just add the global group or the Universal group directly to the ACL of an object?