Golden Rules to Group By

Managing permissions in Distributed Computing Environments (e.g., Windows Server 2003 domains) that consist of many users and resources can be tedious and time-consuming. To ease administrators' lives, Windows provides groups. You can use groups to combine users or computers with similar capabilities, which can significantly alleviate the burden of setting permissions for Windows resources, such as files and printers.

Before I tell you about the golden rules for using groups to set up permissions for resources, you need to know about the possible group types and groups scopes. Note that I cover only those groups you can define in and manage from Active Directory (AD) in a Windows 2003 or Windows 2000 domain environment. (For information about how groups have evolved, see the sidebar "The Evolution of Groups in Windows.") I won't discuss local groups that are defined in the security databases of standalone machines and domain-member workstations and servers. These local groups are only meaningful on the local computer for setting permissions on local resources. The groups I discuss can be used to set permissions on resources domain-wide and in some cases even forestwide.

Group Types
Windows 2003 and Win2K support two group types: distribution groups and security groups. Figure 1 shows how you can choose the group type when you define a new group from the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in.

You can use distribution groups as email distribution lists (DLs) in AD-based mail servers, such as Microsoft Exchange Server 2003 and Exchange 2000 Server. Distribution groups demonstrate the tight integration between the Exchange 2000 and later mail servers and the Win2K and later OSs.

You can also use security groups as email DLs. More important, you can use security groups for security-related administration tasks such as setting resource permissions because a security group's SID is added to a Windows user's access token during the authentication process. A distribution group's SID isn't added to a Windows user's access token, so you can't use distribution groups for security-related administration tasks. Because you can use only security groups for setting resource permissions, I'll focus on this type of group from this point on.

Provided that your domains are at the correct domain functional level, you can change a distribution group to a security group and vice versa from the group's properties page in the Active Directory Users and Computers snap-in. (Domain functional levels will be explained shortly.) Windows warns you about the possible authorization consequences of doing so, as Figure 2 shows. For example, suppose you have a security group that can set permissions for resources. If you convert that security group to a distribution group, the group members will lose access to those resources. To change the type of several groups at once, you can use Windows 2003's Dsmod command-line utility with the -secgrp [yes/no] option. If you're unfamiliar with how to use Dsmod, see the Windows IT Pro article "Windows Server 2003 Directory Service Tools," October 2004, Instant-Doc ID 43753.

The availability of some AD group features depends on the domain functional level. Domain functional levels constitute a version-management system that Microsoft introduced in Windows 2003. The domain functional level depends on the OS versions installed on the domain controllers (DCs) in a domain. Table 1 shows the various Windows 2003 domain functional levels and the OS versions they support on DCs. Table 2 gives an overview of what AD group features are available for the domain functional levels.

Group Scopes
Similar to how you select a group type, you select a group scope when creating a new group. Windows 2003 and Win2K support three group scopes: universal, global, and domain local. Windows 2003 and Win2K also support two flavors of the local group scope: domain local and system local. Groups with a domain local scope can be leveraged on any machine in a domain. Groups with a system local scope can be leveraged only on machines in which the group is defined and stored.

A group's scope defines how you can use the group in multidomain environments. For example, the group scope determines whether a group can contain users and groups from another domain. The scope also determines whether you can use a group to set permissions on a resource in another domain.

Table 3, shows what security principals (i.e., users, computers, or groups) can be a member of a universal group, global group, and domain local group. The table also shows whether the security principals must be located in the same domain as the one in which the group is defined (noted as SD in Table 3) or if they can be in another domain that is part of the same forest (OD-INT) or in another external domain (OD-EXT).

Now that you know what security principals can be a member of what kind of group, it's time to look at where you can use these groups to set permissions for resources. Table 4, shows whether a group can set permissions only for resources in the same domain in which the group is defined or whether it can also set permissions for resources in other domains. As Table 4 shows, domain local groups are the only groups that can't set permissions for resources in another domain.

The group scope also determines which group can be a member of another group, which is called group nesting. Group-nesting rules are dictated by the mechanism Windows uses to find out about a user's group membership when a user logs on to a domain. In Windows 2003 and Win2K, the following group-nesting rules apply:

If your domain is at the Windows 2003 or Win2K-native domain functional level, you can change a group's scope from that group's property page in the Active Directory Users and Computers snap-in. To change the scope of several groups at once, you can use Windows 2003's Dsmod command-line utility with the -scope [l/g/u] option. When you're changing a group's scope, you're bound to the following limitations:

The Golden Rules
One of the main challenges Windows administrators face is managing access to resources as efficiently as possible. A golden rule is to use groups instead of individual accounts to assign permissions to resources. Groups can create an abstraction layer in your authorization model that makes the assignment of permissions independent of account-level changes. This rule applies to Windows domains and standalone environments.

For example, in many organizations, users regularly switch between organizational roles. Each role typically requires specific permissions to Windows resources. In AD, you can create groups for organizational roles (e.g., help desk operators, developers) and assign resource permissions to these groups. If a user switches roles, you simply need to make that person's account a member of the associated group. This practice is much more efficient than resetting the account's permissions so that the user can access the resources needed for the new role.

Here are some more golden rules you should follow when managing groups' access to resources:

Although this is a Windows NT 4.0 rule that provides a workaround for missing NT 4.0 delegation capabilities and NT 4.0 domain database-size limitations, it still applies to multidomain Windows 2003 and Win2K forest environments. Group nesting and the choice of group scopes is less important in single-domain Windows 2003 and Win2K forest setups. In those cases, you must simply ensure that you don't assign permissions to users directly but rather use a group intermediary.

Your group nesting choices might also be influenced by two factors, the first of which is the ownership and sensitivity of the data being protected. When the data is very sensitive, the administrator responsible for the data must have complete control over who is being granted access to the data. Thus, it's best not to nest any groups. Instead, you need to use a single group to control membership and use the same group to grant permissions to the resource. However, that's not the best solution when many users need access to a specific resource and the resource owner doesn't want to or can't control every user's membership to the respective group. In this case, it makes sense to have several groups so that other administrators can self-manage their users in their specific groups, then nest these groups in another group that grants permissions for the resource.

The second factor that can affect your decision on whether to nest groups is the recoverability of AD group memberships after the accidental deletion of AD objects. Memberships to domain local groups are the most difficult to recover when their members reside in a different domain.

One notable exception to this rule is when you have large AD environments that require numerous local groups. Unlike AD groups, users' system local group memberships aren't expanded at logon and don't affect the user Kerberos ticket size. So, in this situation, you might want to use system local groups instead of domain local groups.

Note that this rule applies only to Windows 2003 ADs and Win2K ADs that aren't at the native Windows 2003 forest functional level. In a native Windows 2003 forest, AD supports a new feature called linked-value replication (LVR), which ensures that only group membership changes (and not the entire group membership list) are replicated between DCs when a group's membership is modified. This rule also doesn't apply to multidomain environments that include Exchange servers, which need to use universal distribution groups. In that case, you shouldn't use global group intermediaries because Exchange servers can't expand the membership of global groups defined in foreign domains.

Besides following these golden rules, I recommend that, in general, you try to create as few groups as possible and try to limit the number of group-nesting levels. Fewer groups and group nesting levels help keep permissions simple and hence easier to troubleshoot if problems arise.

Indispensable Knowledge
Now you know the basics of AD groups and how to use them for efficiently managing resource permissions. This knowledge is indispensable for any AD administrator.