When it comes to creating groups, understanding the characteristics and
limitations of each different type and scope is only half the battle.
Other points to consider for group creation are how the group will be
used and who will need to be a member of the group. Groups are commonly
used for one or more of the following: delegating administrative
rights, distributing email, and securing network resources such as file
shares and printer devices. To help clarify group usage, the following
examples show how groups can be used in a variety of administrative
scenarios.
1. User Administration in a Single Domain
If a group is needed to simplify the process
of granting rights to reset user passwords in a single domain, either a
domain local or global security group would suffice. The actual domain
user rights can only be granted to domain local groups, but these
domain local groups could have global groups as members. For a
single-domain model, if the specific user rights need to be granted
only at the domain level, a domain local group with users as members
would be fine. In more complex situations, if you need to reuse the
same group of users for different functions or add domains to the
forest, adding the users to global groups that are then added to the
domain local group is a good solution.
For most organizations, however, the
use of universal groups for most or even all groups is the best
solution Thanks to improvements to the speed of networks and the
efficiency of directory replication over the past several years, the
performance impact of the extensive use of universal groups is often
minor. In addition, environments that also use Exchange 2007 or
Exchange 2010 must migrate all distribution groups to universal groups,
making universal groups a common standard.
2. User Administration in a Multidomain Forest
When multiple domains need to be supported by
the same IT staff, each domain’s Domain Admins group should be added to
each domain’s Administrators group. For example, domain A’s
Administrators group would have Domain A Domain Admins, Domain B Domain
Admins, and Domain C Domain Admins groups as members. You would need to
add these domains whenever a resource or administrative task needs to
grant or deny groups from each domain access to a resource in the
forest.
A common best practice for larger
forests is to create a universal security group named Forest Admins
with each of the domain’s Domain Admin groups as members. Then you
would need to configure only a single entry to allow all the
administrators access forestwide for a particular resource or user
right. Universal security groups are preferred because they can have
members from each domain, but if the group strategy necessitates their
use, domain local and domain global groups could still handle most
situations.
3. Domain Functional Level and Groups
There are four different domain functional
levels, with each level adding more functionality. The reason for all
the different levels is to provide backward compatibility to support
domain controllers running on different platforms. This allows a phased
migration of the domain controllers. The four domain functional levels
are as follows:
• Windows 2000 Native—This
domain level allows Windows 2000 or later domain controllers in the
domain. Universal security groups can be leveraged, along with
universal and global security group nesting. This level can be raised
to Windows Server 2003 Native level, which also enables you to change
some existing groups’ scopes and types on-the-fly.
• Windows Server 2003—This
level allows Windows Server 2003 or later domain controllers. It
provides all the features of the Windows 2000 native domain level, plus
additional security and functionality features, such as domain rename,
logon timestamp updates, and selective authentication.
• Windows Server 2008—The
Windows Server 2008 functional level allows Windows Server 2008 or
later domain controllers. This level supports all the features of the
Windows Server 2003 functional level, plus additional features such as
AES 128 and AES 256 encryption support for Kerberos, last interactive
logon information to provide visibility into true logon activity by the
user, fine-grained password policies to allow policies to be set on a
per-group and per-user basis, and uses DFSR for Active Directory
replication.
• Windows Server 2008 R2—The
Windows Server 2008 R2 functional level, which allows only Windows
Server 2008 R2 and Windows Server 8 domain controllers, adds
Authentication Mechanism Assurance. This essentially inserts the type
of logon method into the Kerberos token and allows applications to
determine authorization or access based on the logon method. For
example, an application could only allow logon type 2 (interactive) and
not type 3 (network) to ensure that the user was actually at a
workstation.
• Windows Server 2012—The
Windows Server 2012 functional level, which allows only Windows Server
2012 domain controllers provides no additional features.
The most important note is that all
the domain functional levels supported by Windows Server 2012 allow
universal security groups.
4.Creating AD Groups
Now that you understand what kinds of groups
you can create and what they can be used for, you are ready to create a
group. To do so, follow these steps:
1. Launch Server Manager on a machine that has the Remote Server Administration Tools (RSAT) AD DS Tools installed.
2. Expand the Tools menu and run Active Directory Users and Computers.
3. Expand the domain folder (in this example, the companyabc.com folder).
4. Select a container—for example, the Users container or an organizational unit (OU). Right-click it and select New, Group.
5. Enter the group name and select the appropriate group type and scope, as shown in Figure 1.
Figure 1. Creating a group.
6. Click OK to finish creating the group.
