Domain Local, Global and Universal group

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.