A group is a collection of user and computer accounts, contacts, and other groups that you can manage as a single unit. Users and computers that belong to a particular group are referred to as group members.
Groups in Active Directory Domain Services (AD DS) are directory objects that reside in a domain and in organizational unit (OU) container objects. AD DS provides a set of default groups at installation. It also provides an option to create groups.
You can use groups in AD DS to:
Simplify administration by assigning permissions on a shared resource to a group, rather than to individual users. Assigning permissions to a group assigns the same access to the resource to all members of that group.
Delegate administration by assigning user rights once to a group through Group Policy. You can then add members to the group that you want to have the same rights as the group.
Create e-mail distribution lists.
Groups are characterized by their scope and their type. The scope of a group determines the extent to which the group is applied within a domain or forest. The group type determines whether you can use a group to assign permissions from a shared resource (for security groups) or use a group for e-mail distribution lists only (for distribution groups).
There are also groups for which you cannot modify or view the memberships. These groups are referred to as special identities. They represent different users at different times, depending on the circumstances. For example, the Everyone group is a special identity that represents all current network users, including guests and users from other domains.
The following sections provide additional information about group accounts in AD DS.
Default groups, such as the Domain Admins group, are security groups that are created automatically when you create an Active Directory domain. You can use these predefined groups to help control access to shared resources and to delegate specific, domain-wide, administrative roles.
Many default groups are automatically assigned a set of user rights that authorize members of the group to perform specific actions in a domain, such as logging on to a local system or backing up files and folders. For example, a member of the Backup Operators group has the right to perform backup operations for all domain controllers in the domain.
When you add a user to a group, the user receives the following:
All the user rights that are assigned to the group
All the permissions that are assigned to the group on any shared resources
Default groups are located in the Builtin container and the Users container. The default groups in the Builtin container have a group scope of Builtin Local. Their group scope and group type cannot be changed. The Users container contains groups that are defined with global scope and groups that are defined with domain local scope. You can move groups that are located in these containers to other groups or OUs within the domain, but you cannot move them to other domains.
For more information about default groups, see Default groups (
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.
Domain local groups
Members of domain local groups can include other groups and accounts from Windows NT, Windows 2000, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 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:
Accounts from any domain
Global groups from any domain
Universal groups from any domain
Domain local groups, but only from the same domain as the parent domain local group
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.
Members of global groups can include accounts from the same domain as the parent global group and global groups from the same domain as the parent global group. 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).
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.
Members of universal groups can have the following as their members:
- Accounts from any domain within the forest in which this Universal Group resides
- Global groups from any domain within the forest in which this Universal Group resides
- Universal groups from any domain within the forest in which this Universal Group resides
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 that have 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.
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. You can use 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 AD DS 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. They also 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 a security group sends the message to all the members of the group.
In addition to the groups in the Users container and Builtin container, servers running Windows Server 2008 R2, 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:
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 R2, Windows Server 2008, or Windows Server 2003, the Anonymous Logon group is not a member of the Everyone group by default.
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.
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.
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 of special identities 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.
Where groups can be created
In AD DS, groups are created in domains. You can use Active Directory Administrative Center to create groups. When you have 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.
You can move groups within a domain. However, only groups with universal scope can be moved from one domain to another. The rights and permissions that are assigned to a group with universal scope are lost when the group is moved to another domain, and new assignments must be made.