Windows Server 2008 R2 Unleashed (115 page)

delegate control. The permissions granted will trickle down to each of the containers

below the initial Sites container. If you don’t want this outcome, return to step 6

and select the appropriate site or subnet container.

11. Click Next to continue.

12. On the Permissions page, check the desired permissions type check boxes and

choose each permission the administrator or, in this case, the networking group

ptg

should have.

13. Click Next and then click Finish to complete the Delegate Control Wizard.

Examining Windows Server 2008 R2 Active

Directory Groups

An Active Directory group is made up of a collection of objects (users and computers and

other groups used to simplify resource access and for emailing purposes). Groups can be

used for granting administrative rights, granting access to network resources, or distribut-

ing email. There are many flavors of groups, and depending on which mode the domain is

running in, certain group functionality might not be available.

Group Types

Windows Server 2008 R2 Active Directory supports two distinct types of groups: distribu-

tion 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. In

Examining Windows Server 2008 R2 Active Directory Groups

563

some cases, this might simplify security management when outside vendors need to be

located in address books but will never need access to resources in the domain or forest.

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 perform 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 granted is immense, so creating a functional secu-

rity group structure can be one way to simplify administration across the enterprise. This

is sometimes referred to as role-based access control or RBAC.

Security groups can also be used for emailing purposes, so they can serve a dual purpose.

ptg

Group Scopes in Active Directory

To complicate the group issue somewhat 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. Because only secu-

rity groups can be used to delegate control or grant resource access, security group types

are implied for the rest of this chapter.

Domain Local Groups

Domain local groups can be used to assign permissions to perform domain-based adminis-

trative tasks and to access resources hosted on domain controllers. These groups can

18

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 kept low or should not be changed frequently because group membership is

replicated across domains and populated in the global catalog. As a best practice in these

564

CHAPTER 18

Windows Server 2008 R2 Administration

environments, create a universal group to span domains but have only a global group

from each domain as a member. This practice reduces cross-domain replication.

NOTE

Universal security groups can be created only in domains running in Windows 2000

Native, Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2

domain functional level. If this level cannot be reached, use global groups from each

domain when setting permissions on resources that need to be accessed from users

in many domains.

Creating Groups

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.

A group is commonly used for three separate functions, including delegating administra-

tive rights, distributing email, and securing network resources such as file shares and

ptg

printer devices. To help clarify group usage, the following examples show how the differ-

ent groups can be used in different administrative scenarios.

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 should have local groups applied only to their access control lists or

settings, but these local groups should 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. However, if you need to add

the same group of users to an access control list on a member server resource or you need

to create a completely new domain, the domain local group cannot be used. This is the

main reason it is recommended to place users only into global groups and assign permis-

sions to resources using local groups that have global groups as members. After you use

this strategy and use global groups over and over, saving administration time, the reason-

ing will be validated.

NOTE

With current group management mechanisms including most domains moving out of

“Mixed mode” into at least Windows 2003 Native mode, the use of universal groups is

more common. Also with Exchange 2007 and Exchange 2010 effectively requiring uni-

versal groups as distribution lists, the default group in an enterprise tends to be the de

facto group in place of global groups in the past.

Creating Groups

565

User Administration Across a Forest of Domains

When multiple domains need to be supported by the same IT staff, even if the domain

levels are set to Windows 2000 Mixed mode, 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.

If all the domains in the forest run in Windows 2000 Native, Windows Server 2003, or

Windows Server 2008 R2 functional level, you could 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.

Domain Functional Level and Groups

ptg

There are many different domain functional levels, with each level adding more function-

ality. 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 only Windows 2000, Windows

Server 2003, Windows Server 2008, and Windows Server 2008 R2 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

18

types on the fly.

.
Windows Server 2003—
This level allows only Windows Server 2003, Windows

Server 2008, and Windows Server 2008 R2 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 time stamp updates, and selec-

tive authentication.

.
Windows Server 2008—
The Windows Server 2008 functional level allows only

Windows Server 2008 and Windows Server 2008 R2 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 interac-

tive 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 adds

Authentication Mechanism Assurance. This essentially inserts the type of logon

566

CHAPTER 18

Windows Server 2008 R2 Administration

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 actu-

ally at a workstation.

The most important note is that all of the domain functional levels supported by

Windows Server 2008 R2 allow universal security groups.

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 domain controller.

2. Expand the Roles folder.

3. Expand the Active Directory Domain Services folder.

4. Expand the Active Directory Users and Computers snap-in.

5. Expand the domain folder (in this example, the companyabc.com folder).

ptg

6. Select a container—for example, the Users container. Right-click it and select New,

Group.

7. Enter the group name and select the appropriate group type and scope, as shown in

Figure 18.4.

FIGURE 18.4

Creating a group.

8. Click OK to finish creating the group.

Creating Groups

567

Populating Groups

After you create a group, you can add members to it. The domain level that the domain is

running in determines whether this group can have other groups as members.

To add members to an existing group, follow these steps:

1. Launch Server Manager on a domain controller.