Understanding group scope

Groups are characterized by a scope that identifies the extent to which the group is applied in the
domain tree or forest. There are three group scopes: domain local, global, and universal.
Understanding domain local groups
Members of domain local groups can include other groups and accounts from Windows Server
2003, Windows 2000, Windows NT, and Windows Server 2008 domains. Members of these
groups can be assigned permissions only within a domain.
Groups with domain local scope help you define and manage access to resources within a single
domain. These groups can have the following as their members:
Groups with global scope

Groups with universal scope

Accounts

Other groups with domain local scope

A mixture of any of the above

For example, to give five users access to a particular printer, you can add all five user accounts in
the printer permissions list. If, however, you later want to give the five users access to a new
printer, you again have to specify all five accounts in the permissions list for the new printer.
With a little planning, you can simplify this routine administrative task by creating a group with
domain local scope and assigning it permission to access the printer. Put the five user accounts in
a group with global scope and add this group to the group that has domain local scope. When
you want to give the five users access to a new printer, assign the group with domain local scope
permission to access the new printer. All members of the group with global scope automatically
receive access to the new printer.
Understanding global groups
Members of global groups can include other groups and accounts only from the domain in which
the group is defined. Members of these groups can be assigned permissions in any domain in the
forest.
Use groups with global scope to manage directory objects that require daily maintenance, such as
user and computer accounts. Because groups with global scope are not replicated outside their
own domain, you can change accounts in a group having global scope frequently without
generating replication traffic to the global catalog.
Although rights and permissions assignments are valid only within the domain in which they are
assigned, by applying groups with global scope uniformly across the appropriate domains, you
can consolidate references to accounts with similar purposes. This simplifies and rationalizes
group management across domains. For example, in a network with two domains, Europe and
UnitedStates, if there is a group with global scope called GLAccounting in the UnitedStates
domain, there should also be a group called GLAccounting in the Europe domain (unless the
accounting function does not exist in the Europe domain).
Important
We strongly recommend that you use global groups or universal groups instead of domain local
groups when you specify permissions on domain directory objects that are replicated to the
global catalog.

Understanding universal groups

Members of universal groups can include other groups and accounts from any domain in the
domain tree or forest. Members of these groups can be assigned permissions in any domain in
the domain tree or forest.
Use groups with universal scope to consolidate groups that span domains. To do this, add the
accounts to groups with global scope and nest these groups within groups having universal
scope. When you use this strategy, any membership changes in the groups that have global scope
do not affect the groups with universal scope.
For example, in a network with two domains, Europe and UnitedStates, and a group that has
global scope called GLAccounting in each domain, create a group with universal scope called
UAccounting that has as its members the two GLAccounting groups,
UnitedStates\GLAccounting and Europe\GLAccounting. You can then use the UAccounting
group anywhere in the enterprise. Any changes in the membership of the individual
GLAccounting groups will not cause replication of the UAccounting group.
Do not change the membership of a group with universal scope frequently. Any changes to the
membership of this type of group cause the entire membership of the group to be replicated to
every global catalog in the forest.

Understanding group types

There are two types of groups in AD DS: distribution groups and security groups. You can use
distribution groups to create e-mail distribution lists and security groups to assign permissions to
shared resources.
You can use distribution groups only with e-mail applications (such as Microsoft Exchange
Server 2007) to send e-mail to collections of users. Distribution groups are not security enabled,
which means that they cannot be listed in discretionary access control lists (DACLs). If you need
a group for controlling access to shared resources, create a security group.
When they are used with care, security groups provide an efficient way to assign access to
resources on your network. By using security groups, you can:
Assign user rights to security groups in AD DS.

User rights are assigned to a security group to determine what members of that group can
do within the scope of a domain (or forest). User rights are automatically assigned to
some security groups at the time that AD DS is installed to help administrators define a
 person's administrative role in the domain. For example, a user who is added to the
Backup Operators group in Active Directory has the ability to back up and restore files
and directories on each domain controller in the domain.

Assign permissions to security groups on resources.

Permissions are different from user rights. Permissions determine who can access a
shared resource, and they determine the level of access, such as Full Control. You can use
security groups to manage access and permissions to a shared resource. Some
permissions that are set on domain objects are automatically assigned to allow various
levels of access to default security groups, such as the Account Operators group or the
Domain Admins group.

Like distribution groups, security groups can also be used as e-mail entities. Sending an e-mail
message to the group sends the message to all the members of the group.

Special identities
In addition to the groups in the Users container and Builtin container, servers running Windows
Server 2008 or Windows Server 2003 include several special identities. For convenience, these
identities are generally referred to as groups. These special groups do not have specific
memberships that can be modified. However, they can represent different users at different
times, depending on the circumstances. The following groups represent special identities:
Anonymous Logon

This group represents users and services that access a computer and its resources through
the network without using an account name, password, or domain name. On computers
running Windows NT and earlier, the Anonymous Logon group is a default member of
the Everyone group. On computers running Windows Server 2008 or Windows Server
2003, the Anonymous Logon group is not a member of the Everyone group by default.

Everyone

This group represents all current network users, including guests and users from other
domains. Whenever a user logs on to the network, the user is added automatically to the
Everyone group.

Network

This group represents users who are currently accessing a given resource over the
network, as opposed to users who access a resource by logging on locally at the computer
where the resource is located. Whenever a user accesses a given resource over the
network, the user is added automatically to the Network group.
 Interactive

This group represents all users who are currently logged on to a particular computer and
who are accessing a given resource that is located on that computer, as opposed to users
who access the resource over the network. Whenever a user accesses a given resource on
the computer to which they are currently logged on, the user is added automatically to the
Interactive group.

Although the special identities can be assigned rights and permissions to resources, the
memberships cannot be modified or viewed. Group scopes do not apply to special identities.
Users are assigned automatically to these special identities whenever they log on or access a
particular resource.

Understanding where groups can be created

In AD DS, groups are created in domains. You use Active Directory Users and Computers to
create groups. With the necessary permissions, you can create groups in the root domain of the
forest, in any other domain in the forest, or in an OU.
Besides the domain in which it is created, a group is also characterized by its scope. The scope of
a group determines the following:
The domain from which members can be added

The domain in which the rights and permissions that are assigned to the group are valid

Choose the particular domain or OU where you create a group based on the administration that is
required for the group. For example, if your directory has multiple OUs, each of which has a
different administrator, you may want to create groups with global scope within those OUs so
that the administrators can manage group membership for users in their respective OUs. If
groups are required for access control outside the OU, you can nest the groups in the OU into
groups with universal scope (or other groups with global scope) that you can use elsewhere in the
forest.
If the domain functional level is set to Windows 2000 native or higher, the domain contains a
hierarchy of OUs, and administration is delegated to administrators at each OU, it may be more
efficient to nest groups with global scope. For example, if OU1 contains OU2 and OU3, a group
with global scope in OU1 can have as its members groups with global scope in OU2 and OU3. In
OU1, the administrator can add or remove group members from OU1, and the administrators of
OU2 and OU3 can add or remove group members for accounts from their own OUs without
having administrative rights for the group with global scope in OU1.