Planning Security Groups

In Windows NT 4.0, the recommended strategy for assigning permissions to resources is to assign permissions to groups and add specific users to the appropriate groups. Windows 2000 maintains a similar strategy but allows for more flexibility in that different types of security groups can be created. Windows 2000 uses these different security groups to logically organize users and computers for assigning rights and permissions. By placing users into security groups, permissions to access resources can be easily assigned to a large number of users. When planning security groups, consider the following topics, which are covered in this section:

• Types of security groups

• Nesting security groups

Types of Security Groups

When you are planning security groups, you must determine which type of security group to use. You can choose from three security group types:

• Global group

• Domain local group

• Universal group

A fourth type of group, called a local group , is found on computers running Windows 2000 Professional and those running Windows 2000 Server configured as member servers. Local groups can contain only user accounts on the local computer and are used to assign a group of users permissions to resources on the computer on which the group is created. The difference between a local group and a domain local group is that domain local groups can be used to grant users permissions to resources throughout a domain, whereas local groups provide access only to resources on a local computer.

You select the type of group, as shown in Figure 7.2, when creating a new group using the Active Directory Users and Computers MMC snap-in. You can also change the group type for existing groups using the same interface.

Figure 7.2. The various security groups available in Windows 2000.

Global Group

The first type of security group is the global group . Global groups are used to logically organize users in a domain who have common needs to assign them permissions to network resources. When deciding whether to use global groups, keep the following characteristics in mind:

• A global group can contain only other global groups or user accounts from the domain in which the group was created. Referring to Figure 7.1, if a global group were created in the training.xyz.corp domain, it could contain only user accounts from this domain. User accounts from the Consulting domain could not be added to the group.

• After the group is created, it can be assigned permissions to resources throughout the forest. The group name appears in the Global Catalog so that trusted domains can assign the group permissions to their resources (refer to Chapter 2 for a review of the Global Catalog Server).

  Therefore, the global group created in the Training domain could be assigned permissions to resources in the Consulting domain.

• If network traffic is a concern, consider using global groups. Because only the name of the groupnot the actual membership listis replicated to the Global Catalog Server, network traffic is less than for universal groups.

Group membership is still replicated in the domain, but not to other domains.

Domain Local Group

Domain local groups are also used to assign permissions to resources on the network, but they do not have the same characteristics as global groups. This type of group is used to organize users throughout the forest and assign them permissions to resources in the local domain. Here are some points to keep in mind concerning domain local groups:

• Domain local groups can contain global groups and user accounts from any domain in the forest. Referring to Figure 7.1, if a domain local group were created in the Training domain, any user accounts in the forest could be added to the group (this is opposite of global groups).

• The domain local group can be used to assign permissions only to resources in the domain in which the group is created.

The domain local group created in the Training domain can be used to grant users throughout the forest access to resources only in the Training domain. To grant users throughout the forest permissions to a resource located in the Consulting domain, a domain local group would have to be specifically created in that domain.

Unlike a global group, a domain local group is not replicated to Global Catalog Servers in the forest because other domains cannot use it. The group name and membership are still replicated between domain controllers in the domain in which the group is created.

Universal Groups

The third type of security group that can be used is the universal group. This type of group is used to assign a group of users from different domains permission to network resources throughout the forest. Here are some points to keep in mind concerning universal groups:

• Universal groups can contain other universal groups (called nesting), global groups, and user accounts from any domain.

• A universal group can be assigned permissions to resources throughout the forest.

When determining whether to use universal groups, keep in mind that they are available only in native mode, so they can be used only when all the domain controllers have been upgraded to Windows 2000.

Any universal groups created are replicated to all Global Catalog Servers in the forest, as are their membership lists. Therefore, you should be sure to keep membership static and to a minimum to help reduce replication traffic. You also should restrict universal group membership to only global groups to minimize the number and frequency of changes, thus reducing Global Catalog replication traffic.

Now that you've become familiar with the types of security groups available in Windows 2000, let's take a look at group nesting.

Nesting Security Groups

Nesting is the process of adding groups to groups or creating a hierarchy of groups. Recall the discussion of OUs and how they can be nested in each other; the same thing can be done with security groups. Nesting security groups can greatly simplify the process of assigning permissions and reduce network traffic.

Group nesting is available only in native mode. If a domain is still in mixed mode, groups cannot be nested.

For example, in the XYZ Corporation, specific groups could be created for each group of executives in the different geographical locations. These groups could then be nested into one group that would represent all executives from each location (see Figure 7.3). In cases in which all the executives require access to network resources, permissions need only be assigned once to the XYZ Executives group.

Figure 7.3. By nesting the four groups created for the executives into another group (XYZ Executives), permissions need to be set only once to give all executives access to network resources.

Here are a couple of guidelines to follow when you are nesting security groups:

• Less is usually best Try to minimize the level of nesting implemented. The deeper the hierarchy of nested security groups, the harder it is to track permissions and troubleshoot permission problems.

• A good design team maintains good documentation Be sure to document group membership, nested groups, and permissions that have been assigned. This reduces the chance of errors when establishing group membership and permissions, and troubleshooting problems are easier when you have documentation to which to refer.

If you recall from Windows NT 4.0, the acronym for creating groups and assigning permissions is AGLP (assign user accounts to global groups, assign global groups to local groups, and assign permissions to the local group). Windows 2000 maintains a similar version of this strategy. When creating security groups, use the recommended AGDLP (assign user accounts to global groups, assign global groups to domain local groups, and assign permissions to the local group) model to ensure some form of consistency in a business when creating security groups:

1. Place the user accounts into global groups.

2. Add global groups to domain local groups.

3. Assign permissions to the domain local groups.