GroupsConcepts | Windows Server 2003 in a Nutshell

GroupsConcepts

Groups allow user accounts to be logically grouped together for administrative purposes. For example, instead of granting Read access on a shared folder to three separate user accounts, create a group that contains these accounts and assign Read permission to the group. It may be more initial work to do things this way, but if you later want to change the users' access to Full Control, you can do it in one step by granting this permission to the group instead of granting it for each user individually. Also, if other users need these same permissions in the future, you just make them members of the group since members of a group receive whatever permissions have been assigned to the group (a user can belong to more than one group at a time).

The general strategy that Microsoft recommends for managing resource access by user accounts is called AGP: organize user A ccounts into G roups to which suitable P ermissions are assigned. A good way to begin is to determine which user accounts in your domain require access to the same file, printer, and other network resources. For example, users in the customer support department might need access to the FAQ share, so create a group called Support for this purpose.

However, in WS2003 it's a little more complicated than this: there are different types of groups, and these groups can have different scope. In addition, groups can contain not just user accounts but also computers and other groups. In fact, groups can be nested within groups in various ways, which can make for some rather complex administration scenarios.

We'll first consider groups in an Active Directory environment, followed by groups in a workgroup environment.

Domain Setting

In a domain environment groups are fairly complicated. There are two types of groups, three possible scopes, and complex rules for group membership and how groups may be nested.

Group Types

There are two basic types of groups in an Active Directory environment:

Security groups: Used primarily to control the access that users have to network resources but can also be used to send email messages to users. Security groups in WS2003 correspond to the concept of groups in the earlier NT operating system.
Distribution groups: Used only to send email messages to usersfor example, as distribution lists for Microsoft's Exchange Server.

The rest of the discussion focuses solely on security groups.

Group Scopes

The scope of a group defines restrictions on the membership and use of the group. There are three different scopes that security groups can have:

Global groups: These groups can be used to grant access to resources in any domain in the forest and are typically used to organize users who have similar needs for accessing resources. For example, you could create a Marketing global group and make all employees in the marketing department members of this group, since they all need to access the same file and print resources, web sites, applications, and so on. Global groups in WS2003 are similar to global groups in NT when used in domains whose domain functional level is W2K mixed.
Domain local groups: These groups can be used to access resources in the local domain only. For example, if you want users in the mtit.com domain to be able to access the Pub shared folder in the same domain, you can create a domain local group called PublicUsers, make selected users or global groups members of it, and assign suitable permissions to it for accessing the resource. Domain local groups are similar to local groups in NT when used in domains whose domain functional level is W2K mixed.
Universal groups: These groups can be used to access resources in any domain in the forest. They differ from global groups in that they are available only in WS2003 domains running in native mode, not mixed mode. Also, their membership can be drawn from any domain, whereas global group members can come only from the group's own domain. Universal groups are new to WS2003 and have no corresponding type in NT.

WS2003 also has a fourth type of group scope called local groups. Local groups exist only in a workgroup environment and are discussed later in this section.

Group Membership

The membership that different group scopes are allowed depends on the domain functional level of the domain they are created in.

Windows 2000 Mixed

In the Windows 2000 mixed domain functional level, the rules for group membership are essentially the same as the rules in NT for backward compatibility (allowing for the fact that WS2003 trusts are transitive), specifically :

Domain local groups can contain domain user and computer accounts from any domain in the forest and global groups from any domain in the forest.
Global groups can contain only domain user and computer accounts from their own domains.
Universal groups aren't available in mixed-mode domains.

Windows 2000 Native or Windows Server 2003

In the Windows 2000 native or Windows Server 2003 domain functional levels, the membership rules for different group scopes are much more complicated, as outlined in Table 4-13. As you can see, the membership restrictions for domain local and universal groups are the same. The difference is that domain local groups can be used only to access resources in the local domain while universal groups can access resources in any domain in the forest.

Table 4-13. Membership restrictions for group scopes in domains whose functional level is Windows 2000 native or Windows Server 2003

Scope	Can contain
	From same domain	From other domains in the forest
Global	Domain users Computers Global groups	None
Domain local	Domain users Computers Global groups Universal groups	Domain users Computers Global groups Universal groups
Universal	Domain users Computers Global groups Universal groups	Domain users Computers Global groups Universal groups

Nesting of Groups

Nesting means making one group a member of another. Nesting lets you reduce the number of times permissions must be assigned in order to grant users access, but it can also make group permissions more hidden and obscure. Nesting groups in a multidomain environment can also help reduce replication traffic between domains. Rules for nesting groups also depend on the domain functional level.

Windows 2000 Mixed

The rules for nesting groups in domains running in Windows 2000 domain functional level are essentially the same as in NTthat is:

You can nest global groups within domain local groups.
You can't nest global groups within each other or domain local groups within each other.

In other words, groups don't really nest at all in mixed mode (or you could say they nest to one level only and, for global groups, within domain local groups only).

Windows 2000 Native or Windows Server 2003

Nesting is a much more powerful feature when domains are running in Windows 2000 native- or Windows Server 2003 domain functional level. Table 4-14 summarizes the various ways in which different group scopes can be nested in native mode domains. Note especially that:

Global groups can now be members of global groups. This is different from how global groups worked in NT.
Domain local groups still can't be members of other groups.

Table 4-14. Allowable nesting of groups in domains whose functional level is Windows 2000 native or Windows Server 2003

Scope	Can be nested within
	Global	Domain local	Universal
Global	Yes (from same domain only)	Yes	Yes
Domain local	No	No	No
Universal	No	Yes	Yes

It's also important to realize that, where nesting is allowed, it can be performed to any level. In other words, you could have an Enterprise Managers global group, which contains Branch Managers global groups, which contain Division Managers global groups, which contain Department Managers global groups, and so on. This flexibility is almost too much of a good thing, and Microsoft recommends that groups be nested no more than one or two levels. Otherwise, permissions assignments may be difficult to track and troubleshoot if problems arise.

Converting Scopes

WS2003 lets you convert one type of group scope into another. This gives you greater flexibility than you had in NT. However, converting groups from one scope to another can be performed only on domains whose domain functional level is Windows 2000 native or Windows Server 2003. Otherwise, it would conflict with what you can do in NT, which is what mixed mode is designed to support. Table 4-15 shows the various kinds of scope conversions that can be performed on different groups in this scenario.

Table 4-15. Allowable scope conversions in domains whose functional level is Windows 2000 native or Windows Server 2003

Scope	Can be converted to
	Global	Domain local	Universal
Global	No	No	Yes
Domain local	No	No	Yes
Universal	Yes	Yes	No

Using Groups

Careful planning is the key to effective use of the different WS2003 group scopes. Again, the key issue is which domain functional level is your domain running.

Windows 2000 Mixed

The mantra here is AGDLP, which means:

Create Accounts for your domain users within each domain.
Create Global groups within each domain to organize your domain users according to similar resource access needs or job description, and add your domain user accounts to your global groups as desired.
Create Domain Local groups in each domain to control access to specific sets of network resources within the domain, and assign appropriate Permissions for these resources to these groups.
Add global groups from various domains to domain local groups in each domain in order to grant access to these network resources to users everywhere in the forest.

This procedure is essentially the same as it was for NT-based networks, except that domain local groups were called local groups in NT (and thus the mantra was AGLP instead of AGDLP). Here is an example to illustrate the principles involved:

Users in the marketing department need access to the color laser printer to produce their flashy spreadsheets. Other users in other departments may also need access to the printer. To accomplish this, create a global group called Marketing, and make users in the marketing department members of this group. Create a domain local group called ColorPrinter, and assign Print permission for the shared printer to the ColorPrinter group. Add the Marketing group to the ColorPrinter group.

A tempting shortcut to this procedure is to eliminate either the global group or the domain local group from the process. Here's an example:

Create a global group called Marketing, and make users in the marketing department members of this group. Assign Print permission for the shared printer directly to the Marketing group. This strategy may be described as AGP.

Alternatively:

Create a domain local group called ColorPrinter, and assign Print permission for the shared printer to the ColorPrinter group. Make users in the marketing department members of this group. This strategy may be described as ADLP.

The problem with the second and third strategies is that they don't scale well if you later decide to add other domains to your enterprise. In the first case, if you want to allow users in a new domain access to the color printer in the local domain, you will have to explicitly assign permissions to the appropriate global group in the new domain instead of simply adding the global group to the ColorPrinter group in the local domain. This makes for somewhat more complicated administration. In the second place, if you want to grant permissions for a printer in the new domain to members of your local ColorPrinter group, you will again have to assign these permissions explicitly since domain local groups can't be members of any other groups.

Windows 2000 Native or Windows Server 2003

In native mode you can modify the AGDLP strategy somewhat since you can also use universal groups whose scope of membership and resource access span all domains in the forest. I call the mantra here AGUNP, which means:

Create Accounts for your domain users within each domain.
Create Global groups within each domain to organize your domain users according to similar resource access needs or job description, and add your domain user accounts to your global groups as desired.
Create Universal groups to organize enterprise-wide users according to similar enterprise-wide resource access needs, and add your global groups from each domain to your universal groups as desired.
If you have large numbers of global groups, consider Nesting universal groups within other universal groups to reduce the number of members in any individual universal group.
Assign appropriate Permissions for accessing network resources across the enterprise directly to your highest level of universal groups (or assign permissions to domain local groups and place universal groups within domain local groups if you want to keep it complicated).

Alternatively, you can take advantage of the fact that the performance issues relating to universal groups have been considerably improved in WS2003 as compared to W2K Server. As a result, you can often elect to use universal groups only when grouping users together for administration. The resulting mantra would then be AUNP, which means:

Create Accounts for your domain users within each domain.
Create Universal groups to organize users according to similar resource access needs, whether domain- or enterprise-wide in scope.
If you have large numbers of groups, consider Nesting groups within other groups to reduce the number of members in any individual group.
Assign appropriate Permissions for accessing network resources across the enterprise directly to your highest level of universal groups (or assign permissions to domain local groups and place universal groups within domain local groups if you want to keep it complicated).

Workgroup Setting

In a workgroup environment, groups are simple: there is only one type of group with simple membership rules and no nesting.

Local Groups

Local groups allow local user accounts in a workgroup environment to be grouped together for administrative purposes. Local groups are created in the same local security database where local user accounts are created on a machine. Local groups are created within the Groups folder of the Local Users and Groups node under System Tools in Computer Management.

Since use of local user accounts is usually confined to standalone servers running WS2003 or client computers running XP, local groups are used only in small networks. One possible use of local groups is for several users to share a single standalone server or client computer, and you can then secure files and folders located on that machine. In this case you can create local groups to group local user accounts together in order to manage permissions more easily. Another use is to implement a WS2003 network using a workgroup model in which each machine manages its own security settings.

Group Membership

Here are the membership rules concerning local groups:

Local groups can contain local user accounts from the computer on which the group resides and global or universal groups from any domain.
Local groups can't be members of other groups.

One confusing difference between WS2003 and NT is in the use of the term local groups . On NT, local groups:

Are used to assign permissions to resources in the domain
Can contain user accounts and global groups from the local domain and trusted domains
Can be created on domain controllers, member servers, and workstations

However, on WS2003, local groups:

Are not recommended for use in domain-based networks
Can contain local user accounts from the local machine and global or universal groups from any domain
can't be created on domain controllers

The long and the short of it is, where you used to use local groups in NT, use domain local groups in WS2003 instead.

Built-in Groups

A number of special groups are created during the installation of WS2003. These built-in groups have predefined sets of rights that simplify the job of administering user accounts. For example, by adding a user account to the Administrators built-in group, that user gains all the rights and privileges that the special Administrator account has.

Different built-in groups are available, depending on whether you are working with member servers or domain controllers and whether you implemented your WS2003 environment as a workgroup or a domain.

Workgroup Setting

In a workgroup setting, each standalone server running WS2003 or client computer running XP has only one type of built-in group availablenamely, built-in local groups. These built-in local groups can be used to simplify the job of administering the computer on which they exist. They control access to resources on the local computer on which they exist as well as granting users the rights to perform system tasks on this computer. Built-in local groups exist within the Local Security Database on standalone servers or client computers running WS2003. They are found within the Users folder of the Local Users and Groups node under System Tools in Computer Management. The six basic built-in local groups and their functions are as follows :

Administrators: Members can perform any administrative task on the local computer.
Backup Operators: Members can back up and restore the local computer.
Guests: Members have no rights or permissions on the local computer unless they are specifically assigned.
Power Users: Members can administer local user accounts, share folders and printers, and perform other limited administrative tasks on the local computer.
Replicator: This special group supports file replication in a domain using DFS, and it needs no members added to it.
Users: Members have the rights and permissions that are normally assigned to ordinary users of the local computer or other rights and permissions as they are specifically assigned.

Table 4-16 shows the initial membership of these built-in local groups on a standalone server or client computer that is part of a workgroup.

Table 4-16. Initial membership of built-in local groups

Built-in local group	Initial membership
Administrators	Administrator
Backup Operators	None
Guests	Guest
Power Users	None
Replicator	None
Users	None

Domain Setting

In a domain setting, four types of built-in groups are available:

Built-in local groups

Built-in domain local groups

Built-in global groups

Built-in system groups

The first type exists in the Local Security Database of member servers or client computers running WS2003 and is found within the Groups folder of the Local Users and Groups node under System Tools in Computer Management. The remaining three exist within Active Directory on domain controllers and are found in the Builtin and Users OUs of the Active Directory Users and Computers console. Let's look at each of these types separately.

Built-in Local Groups

Built-in local groups are found only on member servers or client computers in the domain; they are used to control access to resources on the local computer on which they exist and to grant users the rights to perform system tasks on this computer. Essentially, they function the same way in a domain-based network as they do in the workgroup setting described earlier. The only difference is that when a standalone server or client computer is moved from a workgroup to a domain, the membership of its built-in local groups changes from what is shown in Table 4-16 to that shown in Table 4-17. These changes give administrators, users, and guests in the domain appropriate rights and permissions to the resources on the computer.

Table 4-17. Initial membership of built-in local groups on a member server or client computer that belongs to a domain

Built-in local group	Initial membership
Administrators	Administrator, Domain Admins
Backup Operators	None
Guests	Guest, Domain Guests
Power Users	None
Replicator	None
Users	Domain Users

An example might help. When a standalone server running WS2003 and belonging to a workgroup joins a domain (and hence becomes a member server in that domain), the built-in global group Domain Admins (which is defined in Active Directory on domain controllers in the domain) becomes a member of the Administrators built-in local group on the member server. In this fashion, any users that belong to the Domain Admins global group also belong to the Administrators local group on all member servers in the domain, giving them full administrative rights and permissions on all member servers in the domain. Built-in global groups are discussed later.

An additional built-in local group called Pre-Windows 2000 Compatible Access is created when you promote a member server to a domain controller. This group lets you choose between stronger WS2003 security and weaker security that might be needed to continue running legacy applications, particularly for compatibility with NT 4.0 RAS servers. If you have problems running legacy applications after promoting a server to a domain controller, add the special group Everyone to this group and reboot your domain controllers.

Built-in Domain Local Groups

When a member server is promoted to a domain controller, the existing built-in local groups on the machine are changed to built-in domain local groups, and additional ones are created. Built-in domain local groups have predefined rights and permissions on domain controllers to simplify the task of administering domain controllers and the domain in which they reside. They are used to control access to resources on domain controllers and to grant users rights to perform system tasks on these computers. The standard built-in domain local groups on a WS2003 domain controller include:

Account Operators: Members can create, modify, and delete user accounts and groups on domain controllers in the domain.
Administrators: Members can perform any administrative task on domain controllers in the domain.
Backup Operators: Members can bypass file security to back up and restore any files on any domain controllers in the domain.
Guests: Members have no rights or permissions on domain controllers in the domain, unless they are specifically assigned.
Print Operators: Members can administer network printers on domain controllers in the domain.
Replicator: This special built-in domain local group is used to implement file replication in a domain and doesn't need any members added to it.
Server Operators: Members can share folders and backup domain controllers in the domain.
Users: Members have the rights and permissions that are normally assigned to ordinary users for domain controllers in the domain or other rights and permissions as they are specifically assigned.

If the domain functional level of a domain is changed from Windows 2000 mixed to Windows 2000 native or Windows Server 2003, the built-in domain local groups are sometimes just called security groups. Additional built-in domain local groups may also be present, depending on which optional WS2003 components are installed. The following are optional built-in domain local groups.

DHCP Users: Members have read-only access to settings on a DHCP server.
DnsAdmins: Members can administer DNS servers.
RAS and IAS Servers: Members are servers that can access remote access properties of users.
WINS Users: Members have read-only access to WINS servers.

Table 4-18 shows the initial membership of the standard built-in domain local groups on a member server that has just been promoted to the role of domain controller.

Table 4-18. Initial membership of standard built-in domain local groups on a domain controller

Built-in domain local group	Initial membership
Account Operators	None
Administrators	Administrator, Domain Admins
Backup Operators	None
Guests	Guest, Domain Guests
Print Operators	None
Replicator	None
Server Operators	None
Users	Domain Users

Here's another example to make things clear. A domain controller is configured as the print server for a network printer. Sally needs to be granted the necessary rights and permissions to manage the network printer. To do this, simply add Sally's user account to the Print Operators group on any domain controller in the domain.

Built-in Global Groups

Built-in global groups on domain controllers are used to group together domain users who have similar resource access needs, making it easier to assign permissions to them for shared network resources. Built-in global groups have no predefined rights or permissions; you typically grant them rights and permissions by making them members of domain local groups on domain controllers or local groups on member servers.

The standard built-in global groups on a domain controller are:

Domain Admins: Members are users who need full administrative rights in the domain.
Domain Computers: Members are member servers and workstations in the domain.
Domain Controllers: Members are domain controllers in the domain.
Domain Guests: Members are users who require only temporary access to resources in the domain.
Domain Users: Members are ordinary users in the domain.
Enterprise Admins: Members can administer any domain in the forest.

Additional built-in global groups may also be present, depending on which optional WS2003 components are installed. These optional built-in global groups include:

Cert Publishers: Members are enterprise certification and renewal agents .
DnsUpdateProxy: Members are DNS clients that are allowed to perform dynamic updates on behalf of other clients (typically DHCP servers).
Group Policy Creator Owners: Members can modify Group Policy for the domain.
Schema Admins: Members can administer the Active Directory schema.

When the forest functional level is changed from Windows 2000 to Windows Server 2003, the scope of the Enterprise Admins and Schema Admins groups becomes universal instead of global. You could call these groups built-in universal groups if you like.

Table 4-19 shows the initial membership of the standard built-in global groups.

Table 4-19. Initial membership of built-in global groups

Built-in global group	Initial membership
Domain Admins	Administrator
Domain Computers	Varies
Domain Controllers	Varies
Domain Guests	Guest
Domain Users	None
Enterprise Admins	Administrator in the forest root domain

Built-in System Groups

Built-in system groups (also called special identities) exist on all computers running WS2003whether they belong to a workgroup or a domain. You can't modify the membership of a built-in system group. Instead, users temporarily become members of different system groups, depending on the kind of system or network activity in which they are involved. In other words, it's not who you are but what you are doing that determines whether you belong to one or more of the built-in system groups on a computer.

For example, if you log on to the local computer using its keyboard and try to access a folder on that computer, you are considered a member of the Interactive system group as far as accessing that resource is considered . If the Interactive group is explicitly denied access to the folder, no one who logs on locally to the computer will be able to access the folder (a rather extreme example).

System groups aren't displayed as groups in the Local Users and Groups console or in the Active Directory Users and Computers console, but they are displayed and can be selected when you are configuring permissions on files and folders on NTFS volumes , on printers, or on objects in Active Directory.

The following are some of the more important built-in system groups on a WS2003 computer:

Authenticated Users: All users who have valid user accounts on the computer or domain (the same as the Everyone group, except it doesn't include anonymous users or guests)
Creator Owner: The user who owns the particular local or network resource under consideration
Everyone: All network users, including users with valid user accounts on the computer or domain, users from other domains (trusted or untrusted), and guest users
Interactive: The user who is currently logged on locally at the keyboard of the local computer and is accessing a resource on this computer
Network: All users who are currently logged on to computers on the network and are accessing a resource on the local computer