An Active Directory group is made up of a collection of objects (groups
containing users and computers that are often used to simplify resource
access permissions and sending emails). Groups can be used for granting
administrative rights, granting access to network resources, or
distributing email. There are many flavors of groups, and depending on
which mode the domain is running in, certain group functionality might
not be available.
1. Group Types
Windows Server 2012 Active Directory supports
two distinct types of groups: distribution and security. Both have
their own particular uses and advantages if they are used properly and
their characteristics are understood.
Distribution Groups
Distribution groups allow for the grouping of
contacts, users, or groups primarily for emailing purposes. These types
of groups cannot be used for granting or denying access to domain-based
resources. Discretionary access control lists (DACLs), which are used
to grant or deny access to resources or define user rights, are made up
of access control entries (ACEs). Distribution groups are not security
enabled and cannot be used within a DACL. When used with Microsoft
Exchange Server 2010, distribution groups, unlike security groups,
support the creation and usage of a dynamic distribution group whose
membership is defined by a query and reevaluated dynamically as the
group is used.
Security Groups
Security groups are security enabled and can
be used for assigning user rights and resource permissions or for
applying computer and Active Directory-based group policies. Using a
security group instead of individual users simplifies administration.
Groups can be created for particular resources or tasks, and when
changes are made to the list of users who require access, only the
group membership must be modified to reflect the changes throughout
each resource that uses this group.
To delegate administrative tasks, security
groups can be defined for different levels of responsibility. For
example, a level 1 server administrator might have the right to reset
user passwords and manage workstations, whereas a level 2 administrator
might have those permissions plus the right to add or remove objects
from a particular organizational unit or domain. The level of
granularity possible is immense, so designing and implementing
a functional security group structure can be one way to simplify
administration and improve security across the enterprise. This is
sometimes referred to as role-based access control (RBAC).
Security groups can also be used for emailing purposes, so they can serve a dual purpose.
2. Group Scopes in Active Directory
To complicate the group design a bit more,
after the type of group is determined, the scope of the group must also
be chosen. The scope, simply put, defines the boundaries of who can be
a member of the group and where the group can be used. While scoping
does apply to both group types, because only security groups can be
used to delegate control or grant resource access, scoping issues
typically impact security groups and therefore they are the focus on
the remainder of this section.
Domain Local Groups
Domain local groups can be used to assign
permissions to perform domain-based administrative tasks and to access
resources hosted on domain members. These groups can contain members
from any domain in the forest and can also contain other groups as
members. Domain local groups can be assigned permissions only in the
domain in which they are hosted.
Global Groups
Global groups are somewhat more functional
than domain local groups. These groups can contain members only from
the domain in which they are hosted, but they can be assigned
permissions to resources or delegated control to perform administrative
tasks or manage services across multiple domains when the proper domain
trusts are in place.
Universal Groups
Universal groups can contain users,
groups, contacts, or computers from any domain in the forest. This
simplifies the need to have single-domain groups that have members in
multiple forests. Universal group memberships in large, multidomain
environments should be used carefully and avoided for groups whose
membership changes frequently because group membership is stored in the
global catalog and replicated throughout the forest. As a best practice
in these environments, create a universal group to span domains but
limit its membership to a global group from each domain which can then
in turn contain any domain specific members. This practice reduces
cross-domain replication.
