Windows Server 2008 R2 Unleashed (44 page)

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

cated 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.

182

CHAPTER 6

Designing Organizational Unit and Group Structure

Examining OU and Group Design

Understanding the concepts used with Windows Server 2008 R2 design is only part of the

battle. The application of those concepts into a best-practice design is the tricky part. You

can take heart in the fact that of all the design elements in AD DS, OU and group struc-

ture is the most flexible and forgiving. Although care should be taken when moving

objects between OUs that have group policies enabled, the operation is not visible to end

users and has no effect. That said, care should be taken to ensure that group policies that

might be in place on OUs are moved in before user or computer accounts move. Not

taking this into account can lead to the application of unwanted group policies to various

computer or user objects, often with adverse effects. Group membership is also readily

changeable, although thought should be given to the deletion of security groups that are

already in use.

NOTE

Because each group SID is unique, you must take care not to simply delete and re-cre-

ate groups as you go. As with user accounts, even if you give a new group the same

name as a deleted group and add the same users into it, permissions set on the old

group will not be applied to the new group. If a group is deleted, it can be recovered,

ptg

but only if the Active Directory Recycle Bin is enabled, as outlined in Chapter 4, “Active

Directory Domain Services Primer.”

While keeping these factors in mind and after successfully completing your forest and

domain design (see Chapters 4, “Active Directory Domain Services Primer,” and 5,

“Designing a Windows Server 2008 R2 Active Directory”), it’s now time to start designing

an OU and group structure.

Starting an OU Design

As with AD DS domain design, OU design should be kept simple and expanded only if a

specific need makes the creation of an OU necessary. As you will see, compelling reasons

for creation of OUs are generally limited to delegation of administration, in most cases.

As with domain design, it is important to establish a frame of reference and common

design criteria when beginning design of the OU structure. Organizational units are often

graphically represented by a folder that looks like the icon in Figure 6.4.

OU

FIGURE 6.4

Folder icon in AD DS.

Starting an OU Design

183

Another common method of displaying OU structure is represented by simple text hierar-

chy, as shown in Figure 6.5.

Locations

Saint Louis

Dayton

San Jose

FIGURE 6.5

Simple text hierarchy for an OU structure.

Whichever method is chosen, it is important to establish a standard method of illustrating

the OU design chosen for an organization.

The first step in the design process is to determine the best method of organizing users,

computers, and other domain objects within an OU structure. It is, in a way, too easy to

create OUs, and often domain designers create a complex structure of nested OUs, with

three or more for every department. Although this approach will work, the fact is that it

gives no technical advantages, and instead complicates LDAP directory queries and

requires a large amount of administrative overhead. Consequently, it is better to start an

OU design with a single OU and expand the number of OUs only if absolutely necessary.

ptg

Examining Overuse of OUs in Domain Design

6

Administrators have heard conflicting reports for years about the use of organizational

units in AD DS. Books and resource guides and pure conjecture have fueled the confusion

and befuddled many administrators over best practices for their OU structure.

The basic truth about OUs, however, is that you likely do not need as many as you

think you need. Add an OU to a domain if a completely separate group needs special

administrative access to a segment of users. If this condition does not exist, and a single

group of people administers the entire environment, there is often no need to create

more than one OU.

This is not to say that there might not be other reasons to create OUs. Application of

Group Policy, for example, is a potential candidate for OU creation. However, even this

type of functionality is better accomplished through other means. It is a little-known fact

that Group Policy can be applied to groups of users, thus limiting the need to create an

OU for this express purpose. For more information on how to accomplish this, see the

section “Group Policies and OU Design” later in this chapter.

OU Flexibility

Domain designers are in no way locked in to an OU structure. Users can be moved back

and forth between OUs during normal business hours without affecting domain function-

ality. This fact also helps designers easily correct any design flaws that might have been

made to the OU structure.

OUs were introduced as part of Active Directory with the release of Windows 2000 and

continued with later releases of Active Directory. There are essentially no real technical

184

CHAPTER 6

Designing Organizational Unit and Group Structure

differences between the functionality of OUs in Windows 2000/2003 and the functionality

of OUs in Windows Server 2008 R2, although there is one important update. By default,

Windows Server 2008 or Windows Server 2008 R2 allows for OUs to be created with Delete

Protection turned on, making it much more difficult for them to be accidentally deleted.

In addition, real-world experience with OU design has changed some of the major design

assumptions that were previously made in Windows 2000.

Using OUs to Delegate Administration

As previously mentioned, one of the most important reasons for creating an OU structure

in AD DS is for the purpose of delegating administration to a separate administrator or

administrative group. AD DS allows for this level of administrative granularity in a single

domain. This concept is further illustrated in this section.

A group of users can be easily granted specific levels of administrative access to a subset of

users. For example, a remote IT group can be granted standard user creation/deletion/pass-

word-change privileges to its own OU. The process of delegating this type of access is

quite simple and involves the following steps:

1. In Active Directory Users and Computers, right-click the OU where you want to

delegate permissions, and choose Delegate Control.

ptg

2. Click Next at the Welcome screen.

3. Click Add to select the group to which you want to give access.

4. Type in the name of the group, and click OK.

5. Click Next to continue.

6. Under Delegate the Following Common Tasks, choose the permissions you want—in

the example shown in Figure 6.6—and click Next to continue.

FIGURE 6.6

Choosing delegation of common tasks.

Using OUs to Delegate Administration

185

7. For example, select Create, Delete, and Manage User Accounts, and then click Next.

8. Click Finish to finalize the changes.

In fact, the Delegation of Control Wizard allows for an extremely specific degree of

administrative granularity. If desired, an administrator can delegate a group of users to be

able to modify only phone numbers or similar functionality for users in a specific OU.

Custom tasks can be created and enabled on OUs to accomplish this and many other

administrative tasks. For the most part, a very large percentage of all the types of adminis-

tration that could possibly be required for delegation can work in this way. To use the

phone administration example, follow these steps to set up custom delegation:

1. In Active Directory Users and Computers, right-click the OU where you want to

delegate permissions, and choose Delegate Control.

2. Click Next at the Welcome screen.

3. Click Add to select the group to which you want to give access.

4. Type in the name of the group, and click OK.

5. Click Next to continue.

6. Select Create a Custom Task to Delegate, and click Next.

7. Under Delegate Control Of, choose Only the Following Objects in the Folder.

ptg

8. Check Users Objects and click Next.

6

9. Under Permissions, check Read and Write Phone and Mail Options, as shown in

Figure 6.7, and click Next.

FIGURE 6.7

Selecting permissions to delegate.

10. Click Finish to finalize the changes.

The possible variations are enormous, but the concept is sound. AD DS’s capability to dele-

gate administrative functionality to this degree of granularity is one of the major advan-

tages inherent in Windows Server 2008 R2.

186

CHAPTER 6

Designing Organizational Unit and Group Structure

Group Policies and OU Design

Administrators create group policies to limit users from performing certain tasks or to

automatically set up specific functionality. For example, a group policy can be established

to display a legal disclosure to all users who attempt to log on to a system, or it can be set

up to limit access to the command prompt. Group policies can be set on AD DS sites,

domains, and OUs but can also be configured to apply specifically to groups. This func-

tionality increases the domain designer’s flexibility to apply group policies.

As previously mentioned in this chapter, creating additional OUs simply to apply multiple

group policies is not an efficient use of OU structure and can lead to overuse of OUs in

general. Rather, you can achieve a more straightforward approach to group policies by

applying them directly to groups of users. The following procedure illustrates how you can

apply a specific group policy at the domain level but enact it only on a specific group:

1. Open the Group Policy Management Console (Start, All Programs, Administrative

Tools, Group Policy Management).

2. Navigate to the OU where the group policy is linked, then select the group policy

that you want to apply to a group.

3. In the Details pane, under Security Filtering, select the Authenticated Users group,