Which type of group should you create? When you create a group, you specify the type and scope. However, how you intend to use the group for access control also affects the type and scope.
Groups use following types:
If the domain containing the group is running in native mode, you can convert the type of a group after it has been created. The type cannot be converted in mixed mode.
Groups use the following scopes:
Note Universal groups require access to a global catalog server. For more information about the impact of universal groups on the global catalog, see Group Scope and the Global Catalog.
Enterprises with a single domain should not use universal groups. Instead, use global groups and domain local groups as appropriate. Avoiding universal groups in the single domain scenario makes the transition easier if the enterprise subsequently expands to multiple domains.
If a domain contains a hierarchy of organizational units and administration is delegated to administrators at each OU, it may be more efficient to nest global groups. For example, if OU 1 contained OU 2 and OU 3, a global group in OU 1 could contain global groups in OU 2 and OU 3. In OU 1, the administrator would add/remove users from OU 1 and the administrators of OU 2 and 3 would add/remove members for users from their own OUs.
If you intend a group to be used to set access rights on directory objects, you must create a group with Global scope. All objects and their security descriptors, which control access to the object, are replicated to every global catalog server. The Configuration container (which contains objects that also have security descriptors) is also replicated to all DCs in the forest. If you use a domain local group to assign rights in a security descriptor, there are circumstances when the group is not in the user's access token and, therefore, the right assigned is not enforced. When the directory object is replicated to the Configuration container or global catalog in another domain and a user requests access to the object in that other domain, the DC handling the access request is not able to add the domain local group to the access token. Effectively, the access that the assigned right containing the domain local group defines is not enforced in these domains. The assigned right is enforced only on the domain containing the domain local group.
Domain Local groups should only be used to manage resources that 1) are not stored in the directory (such as file shares, printer queues, and so on) and 2) are on computers in the domain containing the Domain Local group.