The
AD DS group structure, although not new in AD DS, provides an efficient
mechanism for managing security on large numbers of users. Without
groups to logically organize users, permissions on each object in a
network would have to be set up manually on a per-user basis. This means
that if an entire department needed access to a printer, each user
would need to be manually entered into the permissions list of that
printer. These tasks would make administration of security daunting.
The concept of groups was
therefore devised to ease administration. If a large department needed
access to that same printer, the department’s group need only be
supplied the necessary permissions. This greatly eases security-based
administration and has the added advantage of providing for ease of
transition if specific users leave the company or are transferred to a
different department. For example, imagine an administrator in charge of
printing and her user account is a member of a group named Printer
Admins, which has full administrative privilege to the printers. Now, if
this user transfers to become an email administrator, for example,
reassigning permissions to a new print administrator is as simple as
adding that new user to the Printer Admins group. This capability
greatly simplifies these types of situations.
Groups in AD DS work in the way
that previous group structures, particularly in Windows NT, have
worked, but with a few modifications to their design. Groups are divided
into two categories: group type and group scope. There are two group
types in AD DS: security and distribution. Essentially, a security group
can be used to apply permissions to objects for the members of the
group. A distribution group, on the other hand, cannot be used for
permissions but is used instead to send mail to members of the group.
Group scope in AD DS is likewise divided into several components,
defined as follows:
Machine local groups—
Machine local groups, also known as simply “local groups,” can
theoretically contain members from any trusted location. Users and groups
in the local domain, as well as in other trusted domains and forests,
can be included in this type of group. However, it is important to note
that local groups allow resources to be accessed only on the machine
where they are located, which greatly reduces their usability. Domain local groups—
Domain local groups are essentially the same thing as local groups in
Windows NT, and are used to administer resources located only on their
own domain. They can contain users and groups from any other trusted
domain. Most typically, these types of groups are used to grant access
to resources for groups in different domains. Global groups—
Global groups are on the opposite side from domain local groups. They
can contain users only in the domain in which they exist but are used to
grant access to resources in other trusted domains. These types of
groups are best used to supply security membership to user accounts that
share a similar function, such as the sales global group. Universal groups—
Universal groups can contain users and groups from any domain in the
forest and can grant access to any resource in the forest. Along with
this added power come a few caveats. First, universal groups are
available only in domains with a functional level of Windows 2000 Native
or later. Second, all members of each universal group are stored in the
global catalog, increasing the replication load. It is important to
note, however, that universal group membership replication has been
noticeably streamlined and optimized in Windows Server 2008 R2 because
the membership is incrementally replicated.
|
The type of group used (domain local, global, or universal) has
significant impact on replication of group objects for large,
multidomain organizations as well as organizations with sites connected
through slow links.
For a single-domain organization
with high-speed connections to all sites, domain local, global, and
universal groups are effectively the same because the organization has
only one domain, and replication occurs at high speeds to all domain
controllers.
However, in a multidomain
environment, by default, only the group name of a global group
replicates between domains, not the membership names. Therefore, if a
user in one domain wants to view the member list of a global group in
another domain, the user’s request will have to query across a WAN to
the other domain to view the membership of the global group.
Universal groups, on the
other hand, do replicate group membership information between domains,
so a user query of a universal group membership list will be immediately
available in the user’s local domain. However, because universal group
membership replicates between domains, if a list of group members is not
needed to replicate between domains, traffic can be minimized by simply
making the group a global group.
|
Choosing Between OUs and Groups
Whereas
OUs are primarily used to segregate administrative function, groups are
useful for logical organization of security functions. Translated, OUs
are created if there is a need for a department or physical location to
have some certain type of administrative control over its own
environment. For example, an organization with offices in Japan could
organize its Japanese users into a separate OU and give a local
administrator password-change and account-creation privileges for that
OU. Groups, however, can be used to organize users to more easily apply
security permissions. For example, you can create a group named Japanese
Office Users that contains all the users from the office in Japan.
Security permissions can then be established on objects in AD DS using
that group. They could, for example, be given privileges to folders in
the main corporate location, something that could not be done at the OU
level.
To summarize, the basic
differences between OUs and groups is that groups can be used when
applying security to objects, whereas OUs exist when certain
administrative functionality needs to be delegated.
|
