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.)
Prev. page
[1]
2
next page 
