Windows Server 2008 R2 Unleashed (45 page)

click Remove, and then click OK to acknowledge removal.

ptg

4. In the Details pane, under Security Filtering, click the Add button to select a group

to which you want to apply the policy.

5. Type the name of the group into the text box, and click OK.

6. The Security Filtering settings should display the group, as shown in Figure 6.8.

Repeat steps 4-5 to apply the policy to additional groups.

This concept of applying a specific group policy at the domain level but enacting it for a

specific group can reduce the number of unnecessary OUs in an environment and help

simplify administration. In addition, Group Policy enforcement becomes easier to trou-

bleshoot as complex OU structures need not be scrutinized.

Understanding Group Design

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

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

Understanding Group Design

187

FIGURE 6.8

Adding Read and Apply Group Policy security properties.

ptg

To illustrate this type of use, consider the example shown in Figure 6.9. Users in the

6

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

ment. When necessary, a universal group can take the place of global groups or can poten-

tially 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 estab-

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

188

CHAPTER 6

Designing Organizational Unit and Group Structure

Finance Global

Printer1 DL

Permissions

Printer1

Domain

Local

Marketing Global

Group

Global

Groups

FIGURE 6.9

Best-practice group design example.

Group Nesting

ptg

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

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

Exploring Sample Design Models

Although the possibilities for OU and group design are virtually unlimited, often the same

designs unfold because business needs are similar for many organizations. Over time, two

distinctive models that influence OU and group design have emerged. The first model is

based on a business function design, where varying departments dictate the existence of

OUs and groups. The second model is geographically based, where remote sites are

granted separate OUs and groups.

Examining a Business Function–Based Design

CompanyA is a clothing manufacturer based in St. Louis, Missouri. Facilities for the

company are limited to a small group of locations in Dayton that are connected by T1

lines. A central IT department directly manages approximately 50% of the computer

Exploring Sample Design Models

189

infrastructure within the company. The rest of the company is remotely managed by the

following independent groups within the company:

. Sales

. Manufacturing

. Design

. Management

Detailing OU Design for a Business Function–Based Design

Although the culture of the company revolves around a decentralized business approach,

the IT department wanted to consolidate into a single AD domain, while at the same time

preserving the administrative autonomy that the various departments had with the old

environment. The result was a single AD DS domain named companya.com that used five

separate OUs, one for each department, similar to the structure shown in Figure 6.10.

ptg

6

companya.net

IT

Sales

Manufacturing

Design

Management

FIGURE 6.10

Organizational unit design.

To create this structure, resources were created in the single AD domain. Administrative

rights were assigned to each OU by creating special global groups whose members

included the local administrators for each department. These groups were then delegated

password change, user creation/deletion, and other typical administrative capabilities on

their respective department’s OUs through use of the Delegation of Control Wizard (see

the “Using OUs to Delegate Administration” section earlier in this chapter).

Detailing Group Design for a Business Function–Based Design

A group structure was created with five separate global groups that contained users from

each department. The global groups were named as follows:

190

CHAPTER 6

Designing Organizational Unit and Group Structure

. IT Global

. Sales Global

. Manufacturing Global

. Design Global

. Management Global

Resources were assigned domain local groups that followed a standard naming scheme,

such as that represented in the following examples:

. Printer1 DL

. FileServer3 DL

. VidConfServer1 DL

. Printer3 DL

Security rights for all resources were then given to the appropriate domain local groups

that were set up. The global groups were added as members to those groups as appropri-

ate. For example, the printer named Printer3 was physically located in an area between

both the Design and the Sales departments. It was determined that this printer should be

ptg

accessible from both groups. Consequently, printing access was given to the Printer3 DL

group, and both the Design Global and Sales Global groups were added as members to the

Printer3 DL group, as shown in Figure 6.11.

User

User

Design Global

User

User

User

User

Printer3 DL

User

User

User

User

Sales Global

User

User

User

User

User

User

User

FIGURE 6.11

Nesting groups to assign permissions.

Exploring Sample Design Models

191

This type of resource security allowed for the greatest amount of flexibility and reduced

the replication of group membership needed in the domain. If, at a later time, the deci-

sion is made to allow the IT department to print off Printer3 as well, simply adding the IT

Global group into the Printer3 DL group will do the trick. This flexibility is the main goal

of this type of design.

Understanding Geographically Based Design

As was the case with the business function–based design model, domain structures can

easily be tailored to the needs of organizations with geographically dispersed locations,

each with its own set of administrators. It is important to understand that simply having

sites in remote locations does not immediately warrant creation of an OU for each site.

Some type of special local administration is required in those remote sites before OU

creation should be considered.

Keeping this point in mind, consider the example of CompanyB. It is an international

semiconductor producer that is centralized in Sacramento, California, but has worldwide

remote branches in Malaysia, Costa Rica, Tokyo, Australia, Berlin, and Kiev, as shown in

Figure 6.12.

ptg

6

Malaysia

Tokyo

Berlin

Kiev

Asia

Europe

Sacramento

Sacramento

Australia

Costa Rica

Australia

Costa Rica

FIGURE 6.12

Sample administrative structure.

Administration takes place on a continent-by-continent basis. In other words, Berlin and

Kiev are both managed by the same team, and Tokyo and Malaysia use the same adminis-

trators. Australia administers its own users, as does Costa Rica.

192

CHAPTER 6

Designing Organizational Unit and Group Structure

Outlining OU Design for a Geographically Based Design

The AD designers at CompanyB determined that the local administrative requirements of

the branch offices were best served through the creation of OUs for each administrative

region. A Europe OU was created for users in Berlin and Kiev, and an Asia OU was created

for Tokyo and Malaysia. The three other sites were given individual OUs, as shown in

Figure 6.13.

companyb.com

ptg

Australia

Asia

Sacramento

Costa Rica

Europe

FIGURE 6.13

Redesign using organizational units instead of domains.

Examining Group Design for a Geographically Based Design

Domain local groups were created to grant access to each OU on a resource basis. For

example, a domain local group named Europe OU DL was created for application of secu-

rity to the Europe organizational unit. To apply this security, the Delegation of Control

Wizard was run on each OU, and each corresponding domain local group was granted

administrative access to its own respective OUs.

Membership in the domain local groups was only the first step for allowing CompanyB’s

administrators to manage their own environments. Global groups were created for each IT

team, corresponding with their physical location. For example, Berlin IT Admins Global

and Kiev IT Admins Global groups were created, and each IT admin user account for the

remote locations was added as a member of its respective groups. The two global groups

were then added as members of the Europe OU DL domain local group, as shown in

Figure 6.14. The same process was applied to the other OUs in the organization. This solu-

tion allowed for the greatest degree of administrative flexibility when dealing with permis-

sions set on the OUs.

Each administrative team was consequently granted a broad range of administrative

powers over its own environment, allowing each team to create users, change passwords,