2. Defining Group Naming Conventions
To create a group by using the Active Directory Users And
Computers snap-in, simply right-click the organizational unit (OU) in
which you want to create a group, point to New, and then click Group.
The New Object – Group dialog box, shown in Figure 6, lets you
specify fundamental properties of the new group.
The following name properties can be configured here:
The first properties you must configure are the group’s names. A
group, like a user or computer, has several names. The first, shown in
the Group Name box in Figure 6, is used by
Windows 2000 and later systems to identify the object—it becomes the
cn and name attributes of
the object. The second, the pre–Windows 2000 name, is the
sAMAccountName attribute, used to identify the
group to some applications and devices such as network attached
storage (NAS) devices running non-Microsoft operating systems. The
cn and name attributes must
be unique only within the container—the OU—in which the group exists.
The sAMAccountName must be unique in the entire
domain. Technically, the sAMAccountName could be
a different value than the cn and
name, but this is highly discouraged. Choose a
name that is unique in the domain, and use it in both name boxes in
the New Object – Group dialog box.
Note
BEST PRACTICE GROUP
NAMES
Use the same name (unique in the domain) for both group name
properties.
The following naming conventions are recommended:
-
Role groups
. Simple, unique name, such as Sales or
Consultants -
Management groups
. For example, ACL_Sales Folders_Read
-
Prefix This identifies
the management purpose of group, such as ACL for groups managing access permissions to shared
resources. -
Resource identifier
This is a unique identifier for what is being
managed. -
Suffix For resource
access groups, this is the type of access the group
manages. -
Delimiter This should
be a consistently used marker separating prefix, identifier,
and suffix, such as an underscore (_). Do not use the
delimiter elsewhere in the name—use it only as a
delimiter.
The name you choose should help you manage the group and your
enterprise on a day-to-day basis. It is recommended to follow a
naming convention that identifies the type of group and
the purpose of the group.
The example in the previous section used a group name, ACL_Sales
Folders_Read. Let’s examine how the recommendations listed earlier
apply to the group name.
-
Prefix The prefix identifies
the management purpose of the group. In this case, it is a group
used to manage access permissions to a folder. It is used on
access control lists, so the prefix ACL is used. -
Resource identifier The main
part of the name uniquely identifies the resource that is being
managed with the group—in this example, Sales Folders. -
Suffix The suffix further
defines what is being managed by the group. In the case of
resource access management groups, the suffix defines the level of access
provided to members of the group. In our example, that is
Read. -
Delimiter A delimiter—in this
case, an underscore—is used to separate parts of the name. Note
that the delimiter is not used between the words
Sales and Folder. Spaces
are acceptable in group names—you just need to enclose such group
names in quotes when you refer to them in commands or scripts. You
can create scripts that use the delimiter to deconstruct group
names to facilitate auditing and reporting.
Remember that role groups that define user roles are often used by
non-technical users. For example, you might email-enable the Sales
group so that it can be used as an email distribution list. Therefore,
your naming convention for role groups should be simple and
straightforward. In other words, do not use prefixes, suffixes, or
delimiters when naming role groups—just use a descriptive
user-friendly name.
For more information about managing groups effectively, see
Windows Administration Resource Kit: Productivity Solutions
for IT Professionals.
3. Understanding Group Types
There are two types of groups: security and distribution. When
you create a group, you select the group type in the New Object –
Group dialog box.
Distribution groups are used primarily by email applications.
These groups are not security enabled so they cannot be given
permission to resources. Sending a message to a distribution group
sends the message to all members of the group.
Security groups are security principals with SIDs. These groups
can therefore be used in permission entries in ACLs to control
security for resource access. Security groups can also be used as
distribution groups by email applications. If a group will be used to
manage security, it must be a security group.
Because security groups can be used for both resource access and
email distribution, many organizations use only security groups.
However, if a group will be used only for email distribution, you
should create the group as a distribution group. Otherwise, the group
is assigned a SID and the SID is added to the user’s security access
token, which can lead to unnecessary bloat of the security
token.
4. Understanding Group Scope
Groups have members: users, computers, and other groups;
groups can be members of other groups, and groups can be referred to
by ACLs, Group Policy object (GPO) filters, and other management
components. Group scope affects each of these
characteristics of a group: what it can contain, what it can belong
to, and where it can be used. There are four group scopes: local,
domain local, global, and universal.
The characteristics that define each scope fall into these
categories:
-
Replication Where is the
group defined and to what systems is the group replicated? -
Membership What types of
security principals can the group contain as members? Can the
group include security principals from trusted domains? A trust
allows a domain to refer to another domain for user
authentication, to include security principals from the other
domain as group members, and to assign permissions to security
principals in the other domain. The terminology used can be
confusing. If Domain A trusts Domain B, then Domain A is the
trusting domain and Domain B is the trusted
domain. Domain A accepts the credentials of users in Domain B. It
forwards requests by Domain B users to authenticate to a domain
controller in Domain B because it trusts the
identity store and authentication service of Domain B. Domain A
can add Domain B’s security principals to groups and ACLs in
Domain A. -
Availability Where can the
group be used? Is the group available to add to another group? Is
the group available to add to an ACL?
Keep these broad characteristics in mind as you explore the
details of each group scope.
Tip
EXAM TIP
In the context of group membership, remember that if Domain A
trusts Domain B, Domain B is trusted, and its
users and global groups can be members of domain local groups in Domain A. Additionally, Domain B’s
users and global groups can be assigned permissions to resources in
Domain A.
Local groups are truly local—defined on and available to a
single computer. Local groups are created in the security accounts
manager (SAM) database of a domain member computer—both workstations
and servers have local groups.
Local groups have the following
characteristics:
-
Replication A local
group is defined only in the local SAM database of
a domain member server. The group and its membership are not
replicated to any other system. -
Membership A local group
can include as members:
-
Any security principals from the domain: users,
computers, global groups, or domain local groups -
Users, computers, and global groups from any domain in
the forest -
Users, computers, and global groups from any trusted
domain -
Universal groups defined in any domain in the
forest
-
Availability A local group
has only computer-wide scope. It can be used in ACLs on the
local computer only. A local group cannot be a member of any
other group.
Note
BEST PRACTICE DO
NOT MANAGE WITH LOCAL GROUPS
In a workgroup, you use local groups to manage security of
resources on a system. In a domain, however, managing the local
groups of individual computers becomes unwieldy and is, for the
most part, unnecessary. It is not recommended to create custom
local groups on domain members. In fact, the Users and
Administrators local groups are the only local groups that you
should be concerned with managing in a domain environment.
Domain local groups are used primarily to manage permissions
to resources. For example, the ACL_Sales Folder_Read group discussed
earlier in the lesson would be created as a domain local group.
Domain local groups have the following characteristics:
-
Replication A domain local
group is defined in the domain naming context. The group object
and its membership (the member attribute)
are replicated to every domain controller in the domain. -
Membership A domain local
group can include as members:
-
Any security principals from the domain: users,
computers, global groups, or other domain local
groups -
Users, computers, and global groups from any domain in
the forest -
Users, computers, and global groups from any trusted
domain -
Universal groups defined in any domain in the
forest
-
Availability A domain local
group can be added to ACLs on any resource on any domain member.
Additionally, a domain local group can be a member of other
domain local groups or even computer local groups.
The membership capabilities of a domain local group are identical to those of local groups, but the
replication and availability of the domain local group make it
useful across the entire domain.
Note
BEST PRACTICE
MANAGE ACCESS TO RESOURCES WITH DOMAIN LOCAL
GROUPS
Domain local groups are well suited for defining
business management rules, such as resource access rules, because
the group can be applied anywhere in the domain, and it can
include members of any type within the domain as well as members
from trusted domains. For example, a domain local security group
named ACL_Sales Folders_Read might be used to manage Read access
to a collection of folders that contain sales information on one
or more servers.
Global groups are used primarily to define collections
of domain objects based on business roles. Role groups, such as the Sales and Marketing groups
mentioned earlier, as well as roles of computers such as a Sales
Laptops group, would be created as global groups. Global groups have
the following characteristics:
-
Replication A global group
is defined in the domain naming context. The group object,
including the member attribute, is
replicated to all domain controllers in the domain. -
Membership A global group
can include as members users, computers, and other global groups
in the same domain only. -
Availability A global group
is available for use by all domain members as well as by all
other domains in the forest and all trusting external domains. A
global group can be a member of any domain local or universal
group in the domain or in the forest. It can also be a member of
any domain local group in a trusting domain. Finally, a global
group can be added to ACLs in the domain, in the forest, or in
trusting domains.
As you can see, global groups have the most limited membership
(only users, computers, and global groups from the same domain) but
the broadest availability across the domain, the forest, and
trusting domains.
Note
BEST PRACTICE
DEFINE ROLES WITH GLOBAL GROUPS
Global groups are well suited to defining roles, because
roles are generally collections of objects from the same
directory. For example, global security groups named Consultants
and Sales might be used to define users who are consultants and
salespeople, respectively.
Universal groups have the following characteristics:
-
Replication A universal
group is defined in a single domain in the forest
but is replicated to the global catalog. Objects in
the global catalog are readily accessible across the
forest. -
Membership A universal
group can include as members users, global groups, and other universal groups from any
domain in the forest. -
Availability A universal
group can be a member of a universal group or domain local group
anywhere in the forest. Additionally, a universal group can be
used to manage resources—for example, to assign
permissions—anywhere in the forest and in trusting
forests.
Universal groups are useful in multidomain forests. They let
you define roles, or manage resources, that span more than one
domain.
The best way to understand universal groups is through an
example. Trey Research has a forest with three domains: Americas,
Asia, and Europe. Each domain has user accounts and a global group
called Regional Managers that includes the managers of that domain’s
region. Remember that global groups can contain only users from the same
domain. A universal group called Trey Research Regional Managers is
created, and the three Regional Managers groups are added as
members. The Trey Research Regional Managers group therefore defines
a role for the entire forest. As users are added to any
one of the Regional Managers groups, they will, through group
nesting, be members of the Trey Research Regional Managers
group.
Trey Research is planning to release a new product that
requires collaboration across its regions. Resources related to the
project are stored on file servers in each domain. To define who has
the ability to modify files related to the new product, a universal
group is created called ACL_New Product_Modify.
That group is assigned the Allow Modify permission to the shared
folders on each of the file servers in each of the domains. The Trey
Research Regional Managers group is made a member of the
ACL_New Product_Modify group, as are various
global groups and a handful of users from each of the
regions.
Note
BEST PRACTICE
MANAGE ROLES AND RULES ACROSS DOMAINS IN A FOREST WITH UNIVERSAL
GROUPS
As you can see from the example in this section, universal
groups can help you represent and consolidate roles that span
domains in a forest and define rules that can be applied across
the forest.
Summarizing Group Membership Possibilities
For both the certification examinations and day-to-day
administration, it is important that you are completely familiar
with the membership characteristics of each group scope.
Table 1 summarizes the
objects that can be members of each group scope.
Table 1. Group Scope and Members
|
GROUP SCOPE |
MEMBERS FROM THE SAME DOMAIN |
MEMBERS FROM ANOTHER DOMAIN IN THE SAME
FOREST |
MEMBERS FROM A TRUSTED EXTERNAL
DOMAIN |
|---|
|
Local |
Users |
Users |
Users | | |
Computers |
Computers |
Computers | | |
Global groups |
Global groups |
Global | | |
Universal groups |
Universal groups |
groups | | |
Domain local groups | | | | |
Local users defined on the same computer as the
local group | | | |
Domaian Local |
Users |
Users |
Users | | |
Computers |
Computers |
Computers | | |
Global groups |
Global groups |
Global | | |
Universal groups |
Universal groups |
groups | | |
Domain local groups | | | |
Universal |
Users |
Users |
N/A | | |
Computers |
Computers | | | |
Global groups |
Global groups | | | |
Universal groups |
Universal groups | | |
Global |
Users |
N/A |
N/A | | |
Computers | | | | |
Global groups | | |
|
