What Type of Group to Use

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.

Type

Groups use following types:

• Security. Use security groups to control access to resources. Security groups can also be used as e-mail distribution lists.
• Distribution. Use distribution groups if the group is only used for e-mail distribution lists or for grouping purposes. The primary purpose of this type of group is to group related objects together. Distribution groups cannot be used for access control. You can explicitly disable security on these groups to avoid unnecessary evaluation of these groups during a user's logon process. This avoids the expense of examining them when the logon process creates the user's security token (this makes logon more efficient) and reduces the size of the security token (this makes evaluation of access rights more efficient).

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.

Scope

Groups use the following scopes:

• Universal. Use universal groups to define functional groups that span domains. To do this, nest global groups within universal groups and make membership changes in the global groups. The universal group should change infrequently (add/remove global groups) while its membership might change much more frequently (add/remove members from the global groups). For example, define the group system administrators from Fabrikam.com as a universal group that contains the global groups sys-admins from northamerica.Fabrikam.com, sys-admins from Europe.Fabrikam.com, and so on. Each of these account groups would contain the individual system administrators from a single domain.

  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.

• Global. Use global groups for membership maintenance (adding and removing users) should occur within the global groups.

  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.

• Domain Local. Use domain local groups to define access policies on resources within a domain. Depending upon the situation, domain local groups contain global groups, universal groups, individual accounts, other domain local groups, or a mixture of these.
• If the Windows 2000 domain is in mixed mode, the scope of a domain local group is within the set of domain controllers only. The domain controllers include Windows 2000 Domain Controller's as well as Windows NT 4.0 Backup Domain Controller's. Windows 2000 domain local groups behave similar to Windows NT local groups in mixed mode.
• If the Windows 2000 domain is in native mode, the scope of a domain local group is within all the members of the domain. A Windows 2000 domain operating in mixed mode can have Windows NT 4.0 Backup Domain Controller's. Whereas, a Windows 2000 domain operating in native mode cannot have Windows NT 4.0 Backup Domain Controller's.

Usage

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.