As
with organizational unit design, it is best to simplify your group
structure to avoid unnecessary administrative overhead. Establishing a
set policy on how to deal with groups and which groups can be created
will help to manage large groups of users more effectively and help
troubleshoot security more effectively.
Detailing Best Practice for Groups
In the days before
Windows Server 2003 and Exchange Server 2007, it was common to use
domain local groups to control access to resources and use global groups
to organize similar groups of users. When this is done, the global
groups created are then applied to the domain local groups as members,
allowing those users permissions to those resources and limiting the
effect that replication has on an environment.
To illustrate this type of use, consider the example shown in Figure 1.
Users in the Marketing and Finance departments need access to the same
shared printer on the network. Two global groups named Marketing and
Finance, respectively, were created and all user accounts from each
respective group were added. A single domain local group called Printer1
was created and granted sole access to the shared printer. The
Marketing and Finance groups were then added as members of the Printer1
group. Although this is still feasible, current best practice holds that
universal groups can be used instead of domain local and global groups
in an AD DS environment.
The concept of the
universal group is also coming of age in Windows Server 2008 R2. Now
that the replication issue has been solved through incremental
membership replication in Windows 2003, it is more likely that this form
of group will be possible in an environment. When necessary, a
universal group can take the place of global groups or can potentially
include global groups as members. Universal groups are most useful in
consolidating group membership across domain boundaries, and this should
be their primary function if utilized in Windows Server 2008 R2.
Establishing Group Naming Standards
As with all objects in AD DS,
a group should be easily identifiable so that there is less ambiguity
for both end users and administrators. Consequently, it is important to
establish some form of naming convention for all groups to have and to
communicate those naming conventions to the administrators who will
create those groups. Using such conventions will help to alleviate
headaches involved with determining what a certain group is used for,
who owns it, and similar issues.
Group Nesting
Groups
can be nested, or included as members in other groups, to easily add
multiple members of known groups as members of other groups. This added
flexibility reduces the total number of groups necessary and helps to
reduce administrative overhead.
Designing Distribution Groups
If required by your
organization, distribution groups can be set up to allow for SMTP mail
to be sent to multiple recipients. Bear in mind that these groups do not
have SIDs associated with them and consequently cannot be used for
security permission assignments. In reality, it is rare that
distribution groups will be designed in an organization that is not
running a version of Microsoft Exchange Server. However, understanding
their role and potential is important in determining proper group
design.
