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:

• A global group can be a member of another global group, a universal group, or a domain local group.
• A universal group can be a member of another universal group or a domain local group but not a global group.
• A domain local group can only be a member of another domain local group.

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:

• You can convert a domain local group to a universal group only when the domain local group has no other domain local group members. (A domain local group can't be a member of a universal group.)
• You can convert a global group to a universal group only when the global group isn't a member of another global group. (A universal group can't be a member of a global group.)
• In a multidomain environment, you can convert a universal group to a global group only when all the universal group's members are defined in the universal group's domain. (A global group can only contain objects defined in its domain.)

   Previous  [1]  2  Next