The
idea of groups has been around in the Microsoft world for much longer
than OUs have been. As with the OU concept, groups serve to logically
organize users into an easily identifiable structure. However, there are
some major differences in the way that groups function as opposed to
OUs. Among these differences are the following:
Group membership is viewable by users—
Whereas OU visibility is restricted to administrators using special
administrative tools, groups can be viewed by all users engaged in
domain activities. For example, users who are setting security on a
local share can apply permissions to security groups that have been set
up on the domain level.
Membership in multiple groups—
OUs are similar to a file system’s folder structure. In other words, a
file can reside in only one folder or OU at a time. Group membership,
however, is not exclusive. A user can become a member of any one of a
number of groups, and her membership in that group can be changed at any
time.
Groups as security principles—
Each security group in AD DS has a unique security identifier (SID)
associated with it upon creation. OUs do not have associated access
control entries (ACEs) and consequently cannot be applied to
object-level security. This is one of the most significant differences
because security groups allow users to grant or deny security access to
resources based on group membership. Note, however, that the exception
to this is distribution groups, which are not used for security.
Mail-enabled group functionality—
Through distribution groups and (with the latest version of Microsoft
Exchange) mail-enabled security groups, users can send a single email to
a group and have that email distributed to all the members of that
group. The groups themselves become distribution lists, while at the
same time being available for security-based applications.
Outlining Group Types: Security or Distribution
Groups in Windows Server
2008 R2 come in two flavors: security and distribution. In addition,
groups can be organized into different scopes: machine local, domain
local, global, and universal.
Security Groups
The type of group that
administrators are most familiar with is the security group. This type
of group is used to apply permissions to resources en masse so that
large groups of users can be administered more easily. Security groups
can be established for each department in
an organization. For example, users in the Marketing department can be
given membership in a Marketing security group, as shown in Figure 1. This group is then allowed to have permissions on specific directories in the environment.
As previously mentioned,
security groups have a unique security identifier (SID) associated with
them, much in the same way that individual users in AD DS have an SID.
The uniqueness of the SID is utilized to apply security to objects and
resources in the domain. This concept also explains why you cannot
simply delete and rename a group to have the same permissions that the
old group previously maintained.
Distribution Groups
The concept of
distribution groups in Windows Server 2008 R2 was introduced in Windows
2000 Server along with its implementation of Active Directory.
Essentially, a distribution group is a group whose members are able to
receive Simple Mail Transfer Protocol (SMTP) mail messages that are sent
to the group. Any application that can use AD DS for address book
lookups (essentially LDAP lookups) can utilize this functionality in
Windows Server 2008 R2.
Distribution groups are
often confused with mail-enabled groups, a concept in environments with
Exchange 2000/2003/2007/2010. In addition, in most cases distribution
groups are not utilized in environments without Exchange Server because
their functionality is limited to infrastructures that can support them.
Note
In
environments with Exchange Server, distribution groups can be used to
create email distribution lists that cannot be used to apply security.
However, if separation of security and email functionality is not
required, you can make security groups mail-enabled.
Mail-Enabled Groups
AD DS includes a
concept called mail-enabled groups. These groups are essentially
security groups that are referenced by an email address, and can be used
to send SMTP messages to the members of the group. This type of group
is primarily used with Exchange Server, but can also be used with
foreign mail systems integrated with AD DS.
Most organizations will
find that mail-enabled security groups satisfy most of their needs, both
security-wise and email-wise. For example, a single group called
Marketing that contains all users in that department could also be
mail-enabled to allow Exchange users to send emails to everyone in the
department.
Understanding Group Scope
There are four primary
scopes of groups in AD DS. Each scope is used for different purposes,
but they simply serve to ease administration and provide a way to view
or perform functions on large groups of users at a time. The group
scopes are as follows:
Group scope can become one of
the most confusing aspects of AD DS. However, if certain design criteria
are applied to group membership and creation, the concept becomes more
palatable.
Machine Local Groups
Machine local groups are
essentially groups that are built in to the operating system and can be
applied only to objects local to the machine in which they exist. In
other words, they are the default local groups such as Power Users,
Administrators, and the like created on a stand-alone system. Before
networking simplified administration, local groups were used to control
access to the resources on a server. The downside to this approach was
that users needed to have a separate user account on each machine that
they wanted to access. In a domain environment, using these groups for
permissions is not recommended because the administrative overhead would
be overwhelming.
Domain Local Groups
Domain local groups, a
term that might seem contradictory at first, are domain-level groups
that can be used to establish permissions on resources in the domain in
which they reside. Essentially, domain local groups are the evolution of
the old Windows NT local groups.
Domain
local groups can contain members from anywhere in an AD DS forest or
any trusted domain outside the forest. A domain local group can contain
members from any of the following:
Domain local groups are
primarily used for access to resources because different domain local
groups are created for each resource and then other accounts and/or
groups are added to them. This helps to readily determine which users
and groups have access to a resource.
Global Groups
Global groups are the
reincarnation of the legacy Windows NT global group, but with slightly
different characteristics. These groups can contain the following types
of objects:
Global groups are primarily
useful in sorting users into easily identifiable groupings and using
them to apply permissions to resources. What separates global groups
from universal groups, however, is that global groups stop their
membership replication at the domain boundary, limiting replication
outside the domain.
Universal Groups
The concept of universal
groups was new with the release of Windows 2000 and is still useful in
Windows Server 2008 R2. Universal groups are just that—universal. They
can contain objects from any trusted domain and can be used to apply
permissions to any resource in the domain.
Although simply making all
groups within a domain into universal groups might seem practical, the
limiting factor has always been that membership in universal groups is
replicated across the entire forest. To make matters worse, Windows 2000
AD DS universal group objects contained a single multi-entry attribute
that defined membership. This meant that any time membership was changed
in a universal group, the entire group membership was re-replicated
across the forest. Consequently, universal groups were limited in
functionality.
Windows Server 2003
introduced the concept of incremental universal group membership
replication, which accomplishes replication of membership in universal
groups on a member-by-member basis. This drastically reduced the
replication effects that universal groups had on an environment and made
the concept of universal groups more feasible for distributed
environments. This functionality is available in any domain functional
level at or beyond Windows Server 2003 functional level.
