MCSE Training Kit (Exam 70-219): Designing a Microsoft Windows 2000 Directory Services Infrastructure

MCSE Training Kit (Exam 70-219): Designing a Microsoft Windows 2000 Directory Services Infrastructure

by Microsoft Corporation, Press Microsoft
     
 

Make the right design decisions for your directory services architecture—and prepare for the Microsoft® Certified Professional (MCP) exam—with this official Microsoft Training Kit. Work at your own pace through a system of case-study scenarios and tutorials to gain practical experience planning an Active Directory™ infrastructure for a

Overview

Make the right design decisions for your directory services architecture—and prepare for the Microsoft® Certified Professional (MCP) exam—with this official Microsoft Training Kit. Work at your own pace through a system of case-study scenarios and tutorials to gain practical experience planning an Active Directory™ infrastructure for a Windows® 2000 Server network. By building these real-world design skills, you’re also preparing for MCP Exam 70-219—a core credit on the Windows 2000 MCSE track.

HERE’S WHAT YOU’LL LEARN.

  • Analyzing your company’s business requirements, including structure, work processes, and growth strategy
  • Identifying your current and future networking needs, from connectivity and access to security, performance, and end user support
  • Assessing the impact of Active Directory on existing systems and processes, as well as on potential upgrades
  • Creating a forest model and schema modification plan
  • Defining and naming domains
  • Designing site topology, including placement of domain controllers and DNS servers
  • Developing the structure of organizational units and planning for Group Policy

HERE’S WHAT’S INSIDE.

  • Comprehensive self-paced training manual that maps to MCP exam goals and objectives
  • Case study–based exercises and decision-making worksheets for learning you can apply to the job
  • Summaries and end-of-chapter review questions to help gauge your progress
  • 120-day evaluation version of Windows 2000 Advanced Server
  • All the book’s content—plus multimedia presentations, interviews with experienced Active Directory designers, and technical white papers—on CD-ROM
  • NEW! Sample MCSE Readiness Review practice-test questions on line. See “Getting Started” for details.

A Note Regarding the CD or DVD

The print version of this book ships with a CD or DVD. For those customers purchasing one of the digital formats in which this book is available, we are pleased to offer the CD/DVD content as a free download via O'Reilly Media's Digital Distribution services. To download this content, please visit O'Reilly's web site, search for the title of this book to find its catalog page, and click on the link below the cover image (Examples, Companion Content, or Practice Files). Note that while we provide as much of the media content as we are able via free download, we are sometimes limited by licensing restrictions. Please direct any questions or concerns to booktech@oreilly.com.

Product Details

ISBN-13:
9780735611320
Publisher:
Microsoft Press
Publication date:
02/04/2001
Series:
Microsoft Press Training Kit Series
Edition description:
EXAM 70-219
Pages:
512
Product dimensions:
7.65(w) x 9.31(h) x 1.64(d)

Read an Excerpt

Chapter 5.
Creating an Organizational Unit Plan


    • About This Chapter
    • Before You Begin
  • Lesson 1: Defining OU Structures
    • Understanding OUs
    • Design Step: Defining OU Structures
    • Design Step Examples: Defining OU Structures
    • Lesson Summary
  • Activity 5.1: Defining OU Structures
    • Scenario: Arbor Shoes
  • Lesson 2: Planning User Accounts and Groups
    • Understanding Users and Groups
    • Design Step: Planning User Accounts and Groups
    • Design Process Examples: Planning User Accounts and Groups
    • Lesson Summary
  • Activity 5.2: Planning User Accounts
    • Scenario: Dearing School of Fine Art
  • Activity 5.3: Planning Groups
    • Scenario: The Ski Haus
  • Lab 5.1: Defining an OU Structure and Security Groups
    • Lab Objectives
    • About This Lab
    • Before You Begin
    • Exercise 5.1: Defining an OU Structure
    • Exercise 5.2: Defining Groups
  • Review

About This Chapter

After you and your design team finish creating a domain plan, the next stage in designing an Active Directory directory services infrastructure is to create an organizational unit (OU) plan. To create an OU plan, you define an OU structure and then plan user accounts and groups. The end result of an OU plan is a diagram of OU structures for each domain, a list of users in each OU, and a list of groups in each domain. This chapter discusses the process of creating an OU plan.


REAL WORLD
Read the "Designing in the Real World: Creating an Organization Unit Plan" interview with Xavier Minet, Microsoft Consulting Services, Belgium, for a real-world perspective of creating an organizational unit plan. You can find the interview on the Supplemental Course Materials CD-ROM (\chapt05\OUPlanInterview).

Before You Begin

To complete this chapter, you must have

  • Knowledge of Active Directory components and concepts covered in Chapter 1, "Introduction to Active Directory"
  • Knowledge of business and technical environment analyses components covered in Chapter 2, "Introduction to Designing a Directory Services Infrastructure"
  • Knowledge and skills covered in Chapter 3, "Creating a Forest Plan"
  • Knowledge and skills covered in Chapter 4, "Creating a Domain Plan"

Lesson 1: Defining OU Structures

The first step in creating an OU plan is to define OU structures. When you define OU structures, you define the OUs needed for each domain in your organization. This lesson discusses how to define OU structures, which includes defining OU structures to delegate administration, defining OU structures to hide objects, and defining OU structures to administer group policy.


After this lesson, you will be able to

  • Identify the three reasons for defining an OU
  • Explain the guidelines for defining OU structures
  • Identify the factors in an organization's environment that impact its need for OUs
  • Identify the tasks in the process of defining OU structures
  • Analyze an organization's environment to define its OUs

Estimated lesson time: 30 minutes


Understanding OUs

Recall that an organizational unit (OU) is a container used to organize objects within one domain into logical administrative groups. An OU can contain objects such as user accounts, groups, computers, printers, applications, file shares, and other OUs from the same domain. There are three reasons for defining an OU:

  • To delegate administration
  • To hide objects
  • To administer group policy

OUs can be added to other OUs to form a hierarchical structure; this process is known as nesting OUs. Each domain defines its own OU structure—the OU structure within a domain is independent of the OU structures of other domains.

Defining OUs to Delegate Administration

The primary reason for defining an OU is to delegate administration. Delegating administration is the assignment of IT management responsibility for a portion of the namespace, such as an OU, to an administrator, a user, or a group of administrators or users. In Windows 2000, you can delegate administration for the contents of an OU container (all users, computers, or resource objects in the OU) by granting administrators specific permissions for an OU on the OU's access control list. An access control list (ACL) is the mechanism for limiting access to certain items of information or certain controls based on users' identity and their membership in various groups. Access control entries (ACEs) in each ACL determine which users or groups can access the OU and what type of access they have.

Because ACEs are inherited by child OUs in an OU hierarchy by default, you can apply permissions to an entire tree of OUs, as shown in Figure 5.1. Inherited ACEs apply only to one domain and do not flow down to child domains. To prevent permissions from being inherited by child objects, you can clear the Allow Inheritable Permissions From Parent To Propagate To This Object check box on the Security tab of the Properties dialog box for the OU.

Figure 5.1 Inheriting permissions and blocking inheritance (Image Unavailable)

To delegate administration, you can use the Delegation of Control Wizard or manually modify the access control entries on the Security tab of the Properties dialog box for the OU.

OU Hierarchy Models for Delegation of Administration

Once you determine the OUs needed for your organization, you can add OUs to other OUs to form a hierarchy of administrative control. Hierarchies for delegating administration can reflect various organizational models:

  • Location. This structure may be used if administration within a domain is handled by location, as shown in Figure 5.2. The top-level OUs—West, Central, and East—correspond to the regions set up for the microsoft.com organization. The second-level OUs represent the physical locations of the company's eight offices.

    Figure 5.2 An OU structure based on location (Image Unavailable)

  • Business function. This structure may be used if administration within a domain is handled by business function, as shown in Figure 5.3. The top-level OUs—Admin, Devel, and Sales—correspond to microsoft.com's business divisions. The second-level OUs represent the functional divisions within the business divisions.

    Figure 5.3 An OU structure based on business function (Image Unavailable)

  • Object type. This structure may be used if administration within a domain is handled by the types of objects being managed, as shown in Figure 5.4. The top-level OUs—Users, Computers, and Resources—correspond to the types of objects used at microsoft.com. The second-level OUs represent further detailing of the object types.

    Figure 5.4 An OU structure based on types of objects (Image Unavailable)

  • A combination of location, business function, and object type. This structure may be used if administration within a domain is handled by a combination of hierarchy models, as shown in Figure 5.5. The top-level OUs—North America and Europe—correspond to the continents on which microsoft.com has offices. The second-level OUs represent the functional divisions within the company.

    Figure 5.5 An OU structure based on location and business function (Image Unavailable)

Defining OUs to Hide Objects

Your organization may require that certain domain objects be hidden from certain users. Although a user may not have the permission to read an object's attributes, the user can still see that the object exists by viewing the contents of the object's parent container. You can hide objects in a domain by creating an OU for the objects and limiting the set of users who have List Contents permission for that OU.

Defining OUs to Administer Group Policy

Recall that group policies are collections of user and computer configuration settings that can be linked to computers, sites, domains, and OUs to specify the behavior of users' desktops. To create a specific desktop configuration for a particular group of users, you create group policy objects (GPOs), which are collections of group policy settings. By linking GPOs to OUs, GPOs can be applied to either users or computers in the OU.

How Group Policy Is Processed

Group policy settings are processed in the following order:

  1. Local GPO
  2. Site GPOs
  3. Domain GPOs
  4. OU GPOs

GPOs linked to the OU highest in the Active Directory hierarchy are processed first, followed by GPOs linked to its child OU, and so on. Finally, the GPOs linked to the OU that contains the user or computer are processed. At the level of each OU in the Active Directory hierarchy, one, many, or no GPOs can be linked. If several group policies are linked to an OU, they are processed synchronously in an order specified by the administrator.

Figure 5.6 provides an example of how group policy is processed.

Figure 5.6 Group policy processing (Image Unavailable)

Group Policy Inheritance

In general, group policy is passed down from parent to child containers. Group policy is inherited in the following ways:

  • If a policy is configured for a parent OU, and the same policy is not already configured for its child OUs, the child OUs, which contain the user and computer objects, inherit the parent's policy setting.
  • If a policy is configured for a parent OU, and the same policy is configured for a child OU, the child OU's group policy setting overrides the setting inherited from the parent OU.
  • Policies are inherited as long as they are compatible. If a policy configured for a parent OU and a policy configured for a child OU are compatible, the child OU inherits the parent's policy, and the child's policy setting is also applied. For example, if the parent OU's policy causes a certain folder to be placed on the desktop and the child OU's policy calls for an additional folder, the users in the child OU see both folders.
  • If a policy configured for a parent OU is incompatible with the same policy configured for a child OU, the child OU does not inherit the policy setting from the parent OU. Only the setting configured for the child OU is applied.
  • If any of the policy settings of a parent OU are disabled, the child OU inherits them as disabled.
  • If any of the policy settings of a parent OU are not configured, the child OU does not inherit them.

Exceptions to Processing Order

The following are exceptions to the default processing order of group policy settings and may affect how GPOs are processed for OUs:

  • Member Computer of a Workgroup. These computers process only the local GPO.
  • No Override. Any GPO linked to a site, domain, or OU (not the local GPO) can be set to No Override with respect to that site, domain, or OU, so that none of its policy settings can be overwritten. When more than one GPO has been set to No Override, the one highest in the Active Directory hierarchy (or higher in the hierarchy specified by the administrator at each fixed level in Active Directory) takes precedence. No Override is applied to the GPO link.

    In Figure 5.7, No Override has been applied to the GPO 4 link to the Users OU. As a result, the policy settings in GPO 4 cannot be overwritten by other GPOs. Processing remains the same.

  • Block Policy Inheritance. At any site, domain, or OU, group policy inheritance can be blocked by selecting the Block Policy Inheritance check box on the Group Policy tab of the Properties dialog box for the site, domain, or OU. However, GPO links set to No Override are always applied and cannot be blocked by using Block Policy Inheritance.

    Block Policy Inheritance is applied directly to the site, domain, or OU. It is not applied to GPOs, nor is it applied to GPO links. Thus, Block Policy Inheritance deflects all group policy settings that reach the site, domain, or OU from above (by way of linkage to parents in the Active Directory hierarchy) no matter what GPOs those settings originate from.

    In Figure 5.7, Block Policy Inheritance has been applied to the Computers OU. As a result, GPOs 1 and 2, which are applied to the site and the domain, are deflected and do not apply to the Computers OU. Therefore, only GPOs 6 and 7 are processed for the Servers OU.

  • Loopback. Loopback is an advanced group policy setting that is useful on computers in certain closely managed environments such as kiosks, laboratories, classrooms, and reception areas. Loopback provides alternatives to the default method of obtaining the ordered list of GPOs whose user configuration settings affect a user.

Figure 5.7 Applying No Override and Block Policy Inheritance (Image Unavailable)

Guidelines for Defining OU Structures

Guidelines for defining OU structures include the following:

  • Design OUs for simplicity. Previous chapters emphasized the use of minimal numbers of forests and domains in your Active Directory design. However, it is likely that your domains will require a number of OUs to meet administrative requirements. The best practice is to begin with one OU and then add only those OUs that you can justify. You should note the specific reason for creating each OU that you add to your OU plan.
  • Assign control to groups rather than users to simplify management tasks. You should also delegate to local groups, rather than global or universal groups. Local groups are ideally suited for resource permissions because, unlike global groups, they can have members from any trusted domain and, unlike universal groups, local group membership is not replicated to the global catalog.

When defining OU structures for your organization, it's also important to keep the following in mind:

  • OUs are not security principals. That is, you cannot assign access permissions based on a user's membership in an OU. Access control is the responsibility of global, domain local, or universal groups.
  • Users will not use the OU structure for navigation. Although users can see the OU structure of a domain, the most efficient way for users to find resources in Active Directory is to query the global catalog. Therefore, you should define OUs with administration, not users, in mind.

Design Step: Defining OU Structures

To define OU structures, you must complete the following tasks:

  1. Define OU structures to delegate administration.
  2. Define OU structures to hide objects.
  3. Define OU structures to administer group policy.


IMPORTANT
Because there is only one way to delegate administration and there are multiple ways to administer group policy, you must define OU structures to delegate administration first. After an OU structure is defined to handle delegation of administration, you can define additional OUs to hide objects and to administer group policy.

Defining OU Structures to Delegate Administration

To define OU structures to delegate administration, you must complete the following tasks:

  1. Assess the organization's IT administration requirements to determine the type of administrative responsibility to delegate.
  2. Define OUs to delegate full control.
  3. Define OUs to delegate control for object classes.

Assessing IT Administration Requirements

To determine the type of administrative responsibility to delegate, you must first consult the IT Management Organization Worksheet compiled earlier by your design team and analyze how administrative tasks are accomplished. In addition to assessing the information compiled in this worksheet, it is imperative that you assess changes currently planned for IT management to address growth, flexibility, and the ideal design specifications of the organization. You will use these findings to determine the type of administrative responsibility to delegate.


NOTE
A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."

There are two types of administrative responsibility you can delegate for an OU:

  • Full control
  • Control for object classes

By default, only domain administrators have full control over all objects in a domain. Domain administrators are responsible for creating the initial OU structure, repairing mistakes, and creating additional domain controllers. It is usually sufficient to allow only domain administrators full control over objects in a domain. However, if there are units in the organization that need to determine their own OU structure and administrative models, you can provide them with this permission by delegating full control.

When determining whether to delegate full control for an OU, you must determine which areas in the organization need to be allowed to change OU properties and to create, delete, or modify any objects in the OU.

If additional OUs are necessary to delegate more restrictive control, you can accomplish this by delegating control of specific object classes for an OU. Although there are many object classes in the schema, you need to consider only the object classes in which administrators will create objects. Such object classes typically include user account objects, computer account objects, group objects, and organizational unit objects. When determining whether to delegate control of object classes, for each object class that your administrators will create in Active Directory you must determine the following:

  • Which areas in the organization should be granted full control over objects of this class in the OU
  • Which areas in the organization should be allowed to create objects of this class and thus have full control over these objects
  • Which areas in the organization should be allowed to modify only specific attributes for or perform specific tasks pertaining to existing objects of this class

Defining OUs to Delegate Full Control or Control of Object Classes

After you determine the type of administrative responsibility to delegate, you can create OUs to delegate full control or control of object classes.

To define OUs to delegate full control or control of object classes

  1. Diagram the desired OU.
  2. Diagram a security group and list administrators who require full control or control of a specific object class in the group.
  3. If the OU is allowed to set its own membership, place the administrator group inside the OU. If the OU is not allowed to set its own membership, place the administrator group outside the OU.

Defining OU Structures to Hide Objects

To define OU structures to hide objects, you must complete the following tasks:

  1. Assess the organization's IT administration requirements to determine the need to hide objects from users.
  2. Define OUs to hide objects.

Assessing the Need to Hide Objects

To define OU structures to hide objects, you must first consult the Technical Standards Worksheet compiled earlier by your design team to determine the objects that must be hidden from users and the users from which the objects must be hidden. In addition to assessing the information in this worksheet, it is imperative that you assess changes currently planned for IT management to address growth, flexibility, and the ideal design specifications of the organization. You will use these findings to determine whether to define OUs to hide objects.


NOTE
A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."

When determining whether to define OUs to hide objects, you must assess the following:

  • Which objects need to be hidden
  • Which groups need to access the OU where the hidden objects reside to perform specific administrative tasks
  • Which groups need read access to the OU where the hidden objects reside
  • Which groups need full control of the OU where the hidden objects reside

Defining OUs to Hide Objects

After you determine whether it's necessary to define OUs to hide objects, you can define the necessary OUs.

To define an OU to hide objects

  1. Diagram the OU in which you will place the objects to be hidden.
  2. List the groups that you want to have full control of the OU.
  3. List the groups that you want to have generic read access to the OU and its contents.
  4. List any groups that you want to have specific permissions, such as creating a specific object class, for the OU.
  5. Specify the objects that you want to hide in the OU.

Defining OU Structures to Administer Group Policy

To define OU structures to administer group policy, you must complete the following tasks:

  1. Assess the organization's group policy requirements and the existing OU structure you created to delegate administration to determine which group policies require the creation of additional OUs for administration.
  2. Define OU structures to administer group policy.

Assessing the Need to Define OU Structures to Administer Group Policy

To define OU structures to administer group policy, you must first consult the Technical Standards Worksheet compiled earlier by your design team and the existing OU structure you created to delegate administration and hide objects to determine which group policies require the creation of additional OUs for administration. In addition to assessing the information in this worksheet, it is imperative that you assess changes currently planned for IT management to address growth, flexibility, and the ideal design specifications of the organization. You will use these findings to determine whether to define additional OUs to administer group policy.


NOTE
A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."

When determining whether to define OUs to administer group policy, you must determine the following:

  • What group policy settings are necessary for the domain
  • To which users or computers do the group policy settings apply
  • Which of the group policy settings are not handled by GPOs linked to the site, domain, or existing OUs created to delegate administration or hide objects

Defining OUs to Administer Group Policy

After you determine whether to create OUs to administer group policy, you can define the necessary OUs.

To define OUs to administer group policy

  1. Diagram the OU that will administer the desired group policy settings.
  2. List the users or computers to which the group policy setting(s) for the OU apply.
  3. Diagram a security group and place administrators who require control of the OU in the group.
  4. Diagram the GPO and indicate its group policy settings.
  5. Indicate the groups that have administrative control for the GPO.
  6. Indicate any processing exceptions (such as No Override or Block Policy Inheritance) for the GPO.
  7. Link the GPO to the OU.

Design Step Examples: Defining OU Structures

The following scenarios are examples of defining OU structures to delegate administration, defining OU structures to hide objects, and defining OU structures to administer group policy.

Defining OU Structures to Delegate Administration

Figure 5.8 shows an example of defining an OU structure to delegate full administrative control of the OU. The Silk unit of Miller Textiles was a recent acquisition, with locations in Tokyo and Osaka. The Silk unit is maintaining its own IT Management department. Therefore, Silk has become its own OU in the asia.m-100times.com root domain. The Silk Admins group is allowed to set its own membership and is set inside the Silk OU. The Tokyo Admins and Osaka Admins groups are not allowed to set their own memberships and are set in the Silk OU, outside of their respective OUs.

Figure 5.8 Defining OUs to delegate full administrative control (Image Unavailable)

Figure 5.9 shows an example of defining an OU structure to delegate control of object classes. The Tokyo location for the Silk unit of Miller Textiles currently contains two Windows NT 4 resource domains, Natural and Synthetic. When the organization migrates to Windows 2000, the resource domains will be consolidated and replaced by OUs. The Natural and Synthetic administrators currently use their domains to share files controlled by group membership and to reset passwords for team members. Groups were created to administer group objects and user objects and then granted the appropriate level of control for the Natural and Synthetic OUs.

Figure 5.9 Defining OUs to delegate control of object classes (Image Unavailable)

Defining OU Structures to Hide Objects

Figure 5.10 shows an example of defining an OU to hide objects. The na.m-100times.com domain has locations in San Francisco, Kansas City, and Raleigh. The OUs in the top half of the diagram were already defined to delegate administration. Because Miller Textiles requires administrative accounts in each location to be hidden from users, it was necessary to create three new OUs to hide the accounts.

Figure 5.10 Defining OUs to hide objects (Image Unavailable)

Defining OU Structures to Administer Group Policy

Figure 5.11 shows an example of defining OUs to administer group policy. The na.m-100times.com domain has locations in San Francisco, Kansas City, and Raleigh. The OUs in the top half of the diagram were already created to delegate administration. Because Miller Textiles requires one group policy to provide folder redirection for users in the Managers group and another group policy to publish software on management workstations, six new OUs were necessary to administer the group policies. Group Policy 1 redirects the My Documents folder for the Managers group only. Group Policy 2 publishes software for installation on managers' workstations only.

Figure 5.11 Defining OUs to administer group policy (Image Unavailable)

Lesson Summary

In this lesson you learned that defining OU structures is a three-step process: (1) define OU structures to delegate administration, (2) define OU structures to hide objects, and (3) define OU structures to administer group policy. Because there is only one way to delegate administration and there are multiple ways to administer group policy, you must define the OU structures to delegate administration first. After an OU structure is defined to handle delegation of administration, you can define additional OUs to hide objects and to administer group policy.

You learned how OU structures to delegate administration can be arranged in a hierarchy to reflect various organizational models: location, business function, object type, or a combination of any of the models. You also learned how you can hide objects in a domain by defining an OU for the objects and limiting the set of users who have List Contents permission for that OU. Finally, you learned how you can link GPOs to OUs to apply group policy settings to either users or computers in the OU.

Activity 5.1: Defining OU Structures

In this activity you will read about an organization that is planning its Active Directory infrastructure. Your task is to analyze the organization's environment to define the OU structures needed in an Active Directory infrastructure. You will define the OU structures by creating a diagram.

Scenario: Arbor Shoes

You are an infrastructure planner on the Active Directory infrastructure design team for Arbor Shoes, a distributor of upscale non-leather shoes operating from three locations in San Francisco, Houston, and Boston. The business and technical environment analysis documents, the forest plan, and the domain plan have already been compiled, and copies have been distributed to everyone on the team. You are now in the process of defining the OU structures for the organization.

Arbor Shoes is a centralized organization, with major IT administration issues handled from its headquarters in Boston. Each of the three locations also has a small autonomous IT staff to handle support tasks. Your design team has created the domain hierarchy diagram shown in Figure 5.12.

Figure 5.12 Domain hierarchy diagram for Arbor Shoes (Image Unavailable)

While reading through the business and technical environment analysis documents, you note the following:

  • One administrative group at each location handles the administration of users.
  • A second administrative group at each location handles the administration of computers.
  • A third administrative group at each location handles the administration of resources.
  • Arbor Shoes requires a specific logon and logoff script for all users at each location, except for users in the Finance department. The Finance department at each location requires a separate logon script but no logoff script.

  1. Diagram the OU structures needed to delegate administration for the corp.a-100times.com domain. Explain your reasoning for defining each OU.
  2. Diagram the OU structures needed to hide objects. Explain your reasoning for defining each OU.
  3. Diagram the OU structures needed to administer group policy. Explain your reasoning for defining each OU.

Answers

Lesson 2: Planning User Accounts and Groups

After you define OU structures, the next step in creating an OU plan is to plan user accounts and groups. When you plan user accounts and groups, you define the user accounts and groups needed for each domain in your organization. This lesson discusses how to plan user accounts and groups, which includes naming and placing user accounts and naming and defining groups.


After this lesson, you will be able to

  • Identify the factors in an organization's environment that impact its naming conventions
  • Analyze an organization's environment to establish naming conventions for users and groups
  • Identify factors in an organization's environment that impact the placement of user accounts
  • Analyze an organization's environment to place user accounts
  • Identify factors in an organization's environment that impact its need for groups
  • Analyze an organization's environment to define groups

Estimated lesson time: 25 minutes


Understanding Users and Groups

Before launching into a discussion of users and groups, it's important to understand the difference between OUs and groups. In the previous lesson, you learned that OUs contain objects such as user accounts, groups, computers, printers, applications, file shares, and other OUs from the same domain. OUs are defined mainly to delegate the administration of their contents. Groups also contain objects such as user accounts, contacts, computers, and other groups. However, groups are defined mainly to assign permissions to users or to restrict user access to various objects in the domain. Planning user accounts and groups is the second part of creating an organizational unit plan.

User Accounts

A domain user account provides a user with the ability to log onto the domain to gain access to network resources. Each person who regularly uses the network should have a unique user account.

You create a domain user account in a container or in an OU on a domain controller. The domain controller replicates the new user account information to all domain controllers in the domain. After Windows 2000 replicates the new user account information, all of the domain controllers in the domain tree can authenticate the user during the logon process. During the logon process, each user provides his or her user name and password. By using this information, Windows 2000 authenticates the users and then builds an access token that contains information about the user and security settings. The access token identifies the user to computers running Windows 2000 and pre–Windows 2000 computers on which the user tries to gain access to resources. Windows 2000 provides the access token for the duration of the logon session.

Groups

A group is a collection of user accounts. Groups simplify administration by allowing you to assign permissions to a group of users rather than having to assign permissions to each individual user account. Permissions control what users can do with a resource, such as a folder, file, or printer. When you assign permissions, you give users the capability to gain access to a resource and define the type of access that they have. For example, if several users need to read the same file, you would add their user accounts to a group. Then, you would give the group permission to read the file.

In addition to user accounts, you can add other groups, contacts, and computers to groups. You add groups to other groups to create a consolidated group and reduce the number of times that you need to assign permissions. However, you should use caution to add only those groups that are absolutely necessary. You add computers to groups to simplify the process of giving a user logged on to one computer access to a resource on another computer.

Group Types

You can create groups for security-related purposes, such as assigning permissions, or for nonsecurity purposes, such as sending e-mail messages. To facilitate this, Windows 2000 includes two group types: security and distribution. The group type determines how you use the group. Both types of groups are stored in the database component of Active Directory, which allows you to use them anywhere in your network.

Windows 2000 uses only security groups, which you use to assign permissions to gain access to resources. Programs that are designed to search Active Directory can also use security groups for nonsecurity-related purposes, such as retrieving user information for use in a Web application. A security group also has all the capabilities of a distribution group. Because Windows 2000 uses only security groups, this lesson focuses on security groups.

Group Scopes

When you create a group you must select a group type and a group scope. Group scopes allow you to use groups in different ways to assign permissions. The scope of a group determines where in the network you are able to use the group to assign permissions to the group. The three group scopes are global, domain local, and universal.

Global security groups are most often used to organize users who share similar network access requirements. A global group has the following characteristics:

  • Limited membership. You can add members only from the domain in which you create the global group.
  • Access to resources in any domain. You can use a global group to assign permissions to gain access to resources that are located in any domain in the domain tree or forest.

Domain local security groups are most often used to assign permissions to resources. A domain local group has the following characteristics:

  • Open membership. You can add members from any domain.
  • Access to resources in one domain. You can use a domain local group to assign permissions to gain access only to resources located in the same domain where you create the domain local group.

Universal security groups are most often used to assign permissions to related resources in multiple domains. A universal security group has the following characteristics:

  • Open membership. You can add members from any domain.
  • Access to resources in any domain. You can use a universal group to assign permissions to gain access to resources that are located in any domain.
  • Available only in native mode. Universal security groups are not available in mixed mode.

Group Nesting

Adding groups to other groups, or nesting, creates a consolidated group and can reduce network traffic between domains and simplify administration in a domain tree. For example, you could create separate regional manager groups for the managers in each region. Then, you could add all of the regional manager groups to a worldwide managers group. When all managers need access to resources, you assign permissions only to the worldwide managers group.

Guidelines for group nesting include the following:

  • Minimize levels of nesting. Tracking permissions and troubleshooting becomes more complex with multiple levels of nesting. One level of nesting is the most effective to use.
  • Document group membership to keep track of permissions assignments. Providing documentation of group membership can eliminate the redundant assignment of user accounts to groups and reduce the likelihood of accidental group assignments.

To efficiently use nesting it is important to understand the membership rules of groups.

Rules for Group Membership

The group scope determines the membership of a group. Membership rules determine the members that a group can contain. Table 5.1 describes group membership rules, including what each group scope can contain in native and mixed mode.

Table 5.1 Group Scope Membership Rules

Group scope In native mode, group can contain In mixed mode, group can contain
Global User accounts and global groups from the same domain Users from the same domain
Domain local User accounts, universal groups, and global groups from any domain; domain local groups from the same domain User accounts and global groups from any domain
Universal User accounts, other universal groups, and global groups from any domain Not applicable; universal groups cannot be created in mixed mode

Design Step: Planning User Accounts and Groups

Planning user accounts and groups is a two-step process:

  1. Name and place user accounts.
  2. Name and define groups.

Naming and Placing User Accounts

To name and place user accounts, you must complete the following tasks:

  1. Assess the organization's existing user account naming conventions and OU structure to determine current user account naming requirements and the OU structure.
  2. Determine the user account naming convention.
  3. Place user accounts in the appropriate OUs.

Assessing User Account Naming Conventions and the OU Structure

To determine current user account naming conventions, you must first consult the Technical Standards Worksheet compiled earlier by your design team to find out the current user account naming requirements. In addition to assessing the information in this worksheet, it is imperative that you assess changes in user account names currently planned to address growth, flexibility, and the ideal design specifications of the organization.


NOTE
A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."

To place user accounts in the appropriate OUs, use the OU structure diagram to determine

  • The user accounts administered by each administrative group
  • The user accounts affected by each GPO

Determining User Account Naming Conventions

By establishing a naming convention for user accounts, you can standardize how users are identified in the domain. A consistent naming convention will help you and your users remember user logon names and locate them in lists. Table 5.2 summarizes some points you might want to consider in determining a user account naming convention for your organization.

Table 5.2 User Account Naming Convention Considerations

Consideration Explanation
Domain user accounts The user's logon name (distinguished name) must be unique to the directory. The user's full name (relative distinguished name, also referred to as display name or account name) must be unique within the OU where you create the domain user account. 20 characters maximum User logon names can contain up to 20 uppercase or lowercase characters. Although the field accepts more than 20 characters, Windows 2000 recognizes only the first 20. Invalid characters The following characters are invalid: " / \ [ ] : ; | = , + * ? < >
User logon names are not case sensitive You can use a combination of special and alphanumeric characters to help uniquely identify user accounts. User logon names are not case sensitive, but Windows 2000 preserves the case.
Accommodate duplicate employee names If two users were named John Doe, you could use the first name and the last initial and then add letters from the last name to differentiate the duplicate names. In this example, one user account logon name could be Johnd and the other Johndo. Another possibility would be to number each user logon name—for example, Johnd1 and Johnd2. Identify the type of employee In some organizations, it is useful to identify temporary employees by their user account. To identify temporary employees, you can use a T and a hyphen in front of the user's logon name—for example, T-Johnd. Alternatively, use parentheses in the name—for example, John Doe (Temp). E-mail compatibility Some e-mail systems may not accept characters, such as spaces and parentheses—"()".

Placing User Accounts in the Appropriate OUs

After you determine the user account naming convention, you can place user accounts in the appropriate OUs. To determine the OU for a user account, you must identify the administrative groups that administer the account and any GPOs that must apply to the account. The OU for the user account is the OU that is administered by the administrative group and the GPO.

To name and place user accounts

  1. Select a naming scheme that ensures that unique user account names are generated for all users in the forest.
  2. Ensure that all administrators adhere to the naming scheme.
  3. List the administrative groups that must administer the account.
  4. List the GPOs that must apply to the account.
  5. Place the account in the OU administered by the designated administrative group and the designated GPO. List the accounts contained in each OU.

Naming and Defining Groups

To name and define groups, you must complete the following tasks:

  1. Assess the organization's existing group naming conventions and OU structure to determine group naming requirements and the definition of appropriate groups.
  2. Determine the group naming convention.
  3. Define the appropriate global and domain local groups.
  4. Define the appropriate universal groups.

Assessing Group Naming Conventions and the OU Structure

To determine group naming requirements, you must first consult the Technical Standards Worksheet compiled earlier by your design team to find out the current group naming requirements. In addition to assessing the information in this worksheet, it is imperative that you assess changes to group names currently planned to address growth, flexibility, and the ideal design specifications of the organization.


NOTE
A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."

Use the list of accounts contained in each OU to define the appropriate global, domain local, and universal groups.

Determining the Group Naming Convention

By establishing a naming convention for groups, you can standardize how groups are identified in the domain. A consistent naming convention will help you and your users remember group names and locate them in lists. Table 5.3 summarizes some points you might want to consider in determining a group naming convention for your organization.

Table 5.3 Group Naming Convention Considerations

Consideration Explanation
Groups The group name must be unique to the directory.
64 characters maximum Group names can contain up to 64 uppercase or lowercase characters.
Invalid characters The following characters are invalid: " / \ [ ] : ; | = , + * ? < >
Group names are not case sensitive You can use a combination of special and alphanumeric characters to help uniquely identify groups. Group names are not case sensitive, but Windows 2000 preserves the case.

Defining the Appropriate Global and Domain Local Groups

Depending on the administration required for the group, you can define global and domain local groups in either domains or organizational units. The group scope determines the domain from which members can be added and the domain in which the rights and permissions assigned to the group are valid.

To define appropriate global and domain local groups:

  • Identify users with common job responsibilities and add the user accounts to a global group. For example, in a finance department, user accounts for all accountants are added to a global group called Finance.
  • Identify the resources to be shared, such as files or printers, and add the resources to a domain local group for that resource. For example, color printers in a company are added to a domain local group called Color Printers.
  • Identify all global groups that share the same access needs for resources and make them members of the appropriate domain local group. For example, add the global groups Finance, Sales, and Management to the domain local group Color Printers.
  • Assign the required permissions for the resource to the domain local group. For example, assign the necessary permissions to use color printers to the Color Printers group. Users in the Finance, Sales, and Management global groups receive the required permissions because their global group is a member of the domain local group Color Printers.

This strategy gives you the most flexibility for growth and reduces permissions assignments. Although there are other methods for defining groups, these methods have the following limitations:

  • Placing user accounts in domain local groups and assigning permissions to the domain local groups does not allow you to assign permissions for resources outside of the domain, reducing the flexibility when your network grows.
  • Placing user accounts in global groups and assigning permissions to the global groups can complicate administration if you are using multiple domains. If global groups from multiple domains require the same permissions, you have to assign permissions for each global group.

Defining the Appropriate Universal Groups

Use universal groups to grant or deny access to resources that are located in more than one domain. Because universal groups and their members are listed in the global catalog, when membership of any universal group changes, the changes must be replicated to every global catalog in the forest. This action can cause excessive network traffic. Therefore, you should define universal groups with caution.

Follow these guidelines to ensure minimal impact on replication traffic:

  • Add global groups, not users, to universal groups. The global groups are the members of the universal group. Keep the number of group members in universal groups as low as possible and minimize the number of individual users.
  • Change the membership of universal groups as infrequently as possible. By requiring all members of universal groups to be global groups and making individual membership changes in the global groups, the membership changes you make to the global groups will not affect the universal groups or replication traffic.

To name and define groups

  1. Select a naming scheme that ensures that unique group names are generated for all groups in the forest.
  2. Ensure that all administrators adhere to the naming scheme.
  3. List the user accounts that must be added to a global group.
  4. List the resources that must be added to a domain local group.
  5. List all global groups that share the same access needs for resources and note the domain local group to which they must be added.
  6. List the global groups that must be added to a universal group or groups.

Design Process Examples: Planning User Accounts and Groups

The following scenarios are examples of naming and placing user accounts and naming and defining groups.

Naming and Placing User Accounts

Consolidated Messenger, a worldwide fictitious delivery service, has 21 new users that need accounts at their location in Dallas. Consolidated Messenger has selected a user account naming scheme that ensures that unique user account names are generated for all users in the forest. Three years ago, the company instituted a naming scheme that creates the account name by taking the user's first initial followed by the first six letters of his or her last name. In case of the same last name, the first two letters of the first name will be used. For temporary employees, "T-" will precede the user account name. Consolidated Messenger will continue to use the naming scheme. All administrators have been trained and recognize the importance of adhering to the naming scheme. All administrators are aware of the procedures to follow in the event of exceptions to the naming scheme.

Table 5.4 provides fictitious names and hiring information for the new employees. The table also lists the administrative groups that must administer each account and the GPOs that apply to some of the accounts.

Table 5.4 New Hire List

User name User logon name Title Department Status Administrative group GPOs
Alboucq, Steve t-salboucRepresentativeDelivery Temp DelAdmin 1
Egert, AmyaegertManagerHuman ResourcesPermAdAdmin
Guo, Bei-JingbguoDeveloperITPerm ITAdmin
Hjellen, RobinrhjelleRepresentativeDispatchPermDspAdmin
Koduri, SunilskoduriRepresentative DeliveryPermDelAdmin
Lyon, Robert rlyon RepresentativeHuman ResourcesPermHRAdmin
Lysaker, JennyjlysakeRepresentativeDeliveryPermDelAdmin
Miksovsky, Jan t-jmiksov RepresentativeDelivery Temp DelAdmin1
Ota, LanilotaRepresentativeDispatchPermDspAdmin
Ramirez, Franciscot-framireRepresentativeDeliveryTemp DelAdmin1
Richardson, MilesmricharSystem AdministratorITPerm DomainAdmins
Samarawickrama, PrasannapsamaraRepresentativeDeliveryPerm Perm
Smith, James t-jasmith Representative DeliveryTemp DelAdmin1
Smith, Jeffjesmith RepresentativeDeliveryPermDelAdmin
Smith, Jeffjsmith Representative PayrollPerm FinAdmin4
Spencer, PhilpspenceRepresentativeDelivery PermDelAdmin
Steiner, AlanasteineManagerDispatchPermDspAdmin
Thomas, Stephen t-sthomas Representative Delivery Temp DelAdmin1
Van Dam, Tanya tvandam Representative DeliveryPerm DelAdmin
Wood, JohnjwoodRepresentativeDispatchPerm DspAdmin
Yim, KevinkyimManagerDelivery Perm OpsAdmin

Figure 5.13 shows the OU structure diagram for the corp.dallas.c-100times.com domain.

Figure 5.13 OU structure diagram for corp.dallas.c-100times.com domain (Image Unavailable)

Table 5.5 is a list of administrative groups that can administer users in each OU.

Table 5.5 Administrative Groups in Consolidated Messenger OUs

OUAdministrative groups
OperationsSysAdmin
OpsAdmin
DistributionSysAdmin
OpsAdmin
DstAdmin
DispatchSysAdmin
OpsAdmin
DspAdmin
DeliverySysAdmin
OpsAdmin
DelAdmin
AdministrationSysAdmin
AdAdmin
FinanceSysAdmin
AdAdmin
FinAdmin
PayrollSysAdmin
AdAdmin
FinAdmin
ITSysAdmin
AdAdmin
ITAdmin
Human ResourcesSysAdmin
AdAdmin
HRAdmin
SalesSysAdmin
AdAdmin
SlsAdmin
TempSysAdmin
TmpAdmin

Table 5.6 shows the new user accounts placed in the OU administered by the designated administrative group and the designated GPO.

Table 5.6 New User Accounts Placed in OUs

OUNew user accounts
Operationsmrichar (or Administration OU)
Dispatch rhjelle, lota, asteine, jwood
Delivery skoduri, jlysake, psamara, jesmith, pspence, tvandam, kyim
Temp t-salbouc, t-jmiksov, t-framire, t-jasmith, t-sthomas
Administration mrichar (or Operations OU)
Payroll jsmith
IT bguo
Human Resources aegert, rlyon

Naming and Defining Groups

Consolidated Messenger has selected a group naming scheme that ensures that unique group names are generated for all groups in the forest. Three years ago, the company instituted a naming scheme for administrative groups that uses a two- or three-letter abbreviation for the group followed by "Admin." User group names consist of one word that describes the group. Consolidated Messenger will continue to use the naming scheme. All administrators have been trained and recognize the importance of adhering to the naming scheme. All administrators are aware of the procedures to follow in the event of exceptions to the naming scheme.

Table 5.7 provides the job function and number of employees in each job function in Consolidated Messenger's Operations division.

Table 5.7 Consolidated Messenger Operations Division Employee Information

Job function Number of employees
Distribution Tracker50
Distribution Handler100
Domestic Dispatcher50
International Dispatcher25
Delivery Representative200
Manager10

Table 5.8 lists the information access requirements for various employee functions.

Table 5.8 Employee Access Requirements

Employee Need access to
Domestic Dispatchers, International Dispatchers, ManagersCustomer database, full access
Delivery RepresentativesCustomer database, read-only access
All employeesCompany policies, read-only access
Distribution Trackers, ManagersTracking database, full access
Distribution HandlersTracking database, read-only access
All employeesCompany announcements through e-mail
All employees, except Delivery Shared installation of Microsoft Office
Representativesapplications
Managers, Managers from other domainsDelivery time reports

To meet the needs listed in the table, Consolidated Messenger has planned the groups listed in Table 5.9.

Table 5.9 Consolidated Messenger Groups

Group name Type and scope Members
TrackersSecurity, globalAll Distribution Trackers
HandlersSecurity, globalAll Distribution Handlers
DomDispatchersSecurity, globalAll Domestic Dispatchers
IntDispatchersSecurity, globalAll International Dispatchers
DeliveryRepsSecurity, globalAll Delivery Representatives
ManagersSecurity, globalAll Managers
AllEmployeesSecurity, globalAll employees
CustDatabaseSecurity, domain localDomestic Dispatchers, International Dispatchers, Managers, Delivery Representatives
CompanyPolSecurity, domain localAll employees
TrackDatabaseSecurity, domain localDistribution Trackers, Managers, Distribution Handlers
MSOfficeSecurity, domain localDistribution Trackers, Distribution Handlers, Domestic Dispatchers, International Dispatchers, Managers
DeliveryTimeReportsSecurity, domain localManagers
E-mailDistribution, domain localAll employees

The Consolidated Messenger network does not require universal groups because the information provided indicates that no groups need access to resources in multiple domains and also need to have members from multiple domains.

Lesson Summary

To begin this lesson, you were reminded that the purpose of defining OUs is to delegate administration, while the purpose of groups is to provide users with access to resources. In this lesson you learned how planning user accounts and groups is a two step-process: (1) naming and placing user accounts and (2) naming and defining groups. You learned how naming conventions help you and your users remember user logon names and locate them in lists. To place user accounts in the appropriate OUs, you must use the OU structure diagram to determine the user accounts administered by each administrative group and the user accounts affected by each GPO. You also learned how a consistent group naming convention will help you and your users remember group names and locate them in lists. To define the appropriate global, domain local, and universal groups, you identify the users to be assigned to various global groups, the resources to be assigned to various domain local groups, and the resources that are located in more than one domain to be assigned to universal groups.

Activity 5.2: Planning User Accounts

In this activity you will read about an organization that is planning its Active Directory infrastructure. Your task is to analyze the organization's environment to plan the user accounts needed in an Active Directory infrastructure.

Scenario: Dearing School of Fine Art

You are an infrastructure planner on the Active Directory infrastructure design team for the Dearing School of Fine Art (DSFA), an art school located in Washington, D.C. The business and technical environment analysis documents, the forest plan, the domain plan, and the OU structure diagram have already been compiled and copies have been distributed to everyone on the team. You are now in the process of planning the naming and placing of user accounts for new students in the fiber arts department.

While looking over the Technical Standards Worksheet, you find that DSFA has selected a user account naming scheme that ensures that unique user account names are generated for all users in the forest. This naming scheme uses the first eight letters of a user's first and last names. In case of the same first and last names, the user's middle initial is used. For part-time students, "PT-" will precede the user account name.

Table 5.10 provides fictitious names and enrollment information for the new students. The table also lists the administrative groups that must administer each account.

Table 5.10 New Student List

Student name Department Status Administrative group
Akhtar, SarahFiber ArtsPart TimePTFiberAdmin
Barnhill, JoshPaintingFull TimeFTPaintAdmin
Berry, JoFiber ArtsFull TimeFTFiberAdmin
Dunn, MatthewDrawingFull TimeCompArtAdmin
Dunn, MichealDrawingPart TimePTDrawAdmin
Hart, SherriPaintingFull TimeFTPaintAdmin
Jacobson, LisaDrawingFull TimeCompArtAdmin
Khanna, KaranPaintingFull TimeFTPaintAdmin
Phua, MengFiber ArtsFull TimeFTFiberAdmin
Schafer, Christina Painting Part Time PTPaintAdmin
Tobey, ChrisDrawingFull TimeFTDrawAdmin
Wolfe-Hellene, MartaFiber ArtsPart TimePTFiberAdmin
Young, RobDrawingFull TimeFTDrawAdmin

Your design team has created the OU structure diagram shown in Figure 5.14.

Figure 5.14 OU structure diagram for the Dearing School of Fine Art (Image Unavailable)

Table 5.11 is a list of administrative groups that can administer users in each OU.

Table 5.11 Administrative Groups in DSFA OUs

OU Administrative groups
FTUsers (Fiber Arts)SysAdmin
FiberAdmin
FTFiberAdmin
PTUsers (Fiber Arts)SysAdmin
FiberAdmin
PTFiberAdmin
FTUsers (Painting)SysAdmin
PaintAdmin
FTPaintAdmin
PTUsers (Painting)SysAdmin
PaintAdmin
PTPaintAdmin
FTUsers (Drawing)SysAdmin
DrawAdmin
FTDrawAdmin
PTUsers (Drawing)SysAdmin
DrawAdmin
PTDrawAdmin
Computer ArtSysAdmin
DrawAdmin
CompArtAdmin

In the table below, place the new student accounts, by account name, in the appropriate OU.

to be completed

OU New student accounts
FTUsers (Fiber Arts)
PTUsers (Fiber Arts)
FTUsers (Painting)
PTUsers (Painting)
FTUsers (Drawing)
PTUsers (Drawing)
Computer Art

Answers

Activity 5.3: Planning Groups

In this activity you will read about an organization that is planning its Active Directory infrastructure. Your task is to analyze the organization's environment to plan the groups needed in an Active Directory infrastructure.

Scenario: The Ski Haus

You are an infrastructure planner on the Active Directory infrastructure design team for The Ski Haus, an international retailer of ski apparel. The Ski Haus uses two domains, one for resources at their Denver, Colorado, location and another for resources at their Geneva, Switzerland, location.

The Product Design department at each location maintains a separate database of ski hat designs. Product Design users at each location must have full control of the ski hat design database in their own domain. Product Design users at both locations must have read permissions on both ski hat design databases. Product Design users at both locations must have change permissions on the ski sweater design database in the Geneva location.

  1. Explain how your design team will use security groups to allow the Product Design users in each domain full control of the ski hat design databases in their domains.
  2. Explain how your design team will use security groups to allow the Product Design users in each domain read permission to the Denver and Geneva ski hat design databases.
  3. Explain how your design team will use security groups to allow all Product Design users in both domains change permission to the ski sweater design database in Geneva.

Answers

Lab 5.1: Defining an OU Structure and Security Groups

Lab Objectives

After completing this lab, you will be able to

  • Define an OU structure
  • Define security groups

About This Lab

In this lab, you will analyze portions of the existing environment at a medium-sized company to define an OU structure and security groups.

Before You Begin

Before you begin this lab, you must be able to

  • Analyze an organization's environment to define its OUs
  • Analyze an organization's environment to place user accounts
  • Analyze an organization's environment to define groups

Exercise 5.1: Defining an OU Structure

In this exercise, you will analyze the existing environment at a medium-sized company to define an OU structure and security groups. Review the scenario; then follow the instructions to define the OU structure and security groups.

Scenario

Your design team is planning the Active Directory infrastructure for Uncle Bob's Root Beer, a worldwide producer of a root beer soft drink. Uncle Bob's has four regional offices in Melbourne, Chicago, Berlin, and New Delhi. There are 107 bottling plants worldwide. The corporate headquarters is located in Melbourne. Each regional office has a human resources, finance, sales, production, and distribution department. In addition, Melbourne also has a new products department. Uncle Bob's infrastructure plan uses one domain.

While reading through the business and technical environment analysis documents, you note the following:

  • The IT management organization in each regional office administers user accounts and user desktop configurations, manages servers, and enforces network security.
  • At the corporate headquarters, some administrators have administrative authority over the entire network in order to complete performance and security audits.
  • In order to keep new products secure in the competitive soft drink industry, the New Products department has its own IT management organization that administers user accounts, manages users, and enforces network security.
  • Though the IT management organization in each regional office administers user accounts for the Production department, each Production department administers access to its servers.
  • All users in the company use the same e-mail and word processing applications.
  • The Distribution department at each regional office uses its own proprietary distribution tracking software.
  • The company requires that all human resources (HR) servers be hidden from non-HR personnel.
  • Each regional office staffs a help desk whose users are permitted to reset passwords.

Exercise Questions

Based on your notes, follow the instructions below to define an OU structure.

  1. Create an OU structure diagram for Uncle Bob's Root Beer that supports the needs indicated in the scenario.
  2. Complete the table below to document each OU in your design, the reason for creating it, and the users and computers that it contains.

to be completed

OU created Reason created Users and computers contained in the OU

Answers

Exercise 5.2: Defining Groups

In this exercise, you will design security groups to provide users with access to network resources.

Scenario

Your design team is planning the security groups needed in connection with the Production department at the Chicago regional office of Uncle Bob's Root Beer. Recall that the Production department has its own IT management organization to manage resources, including servers. Users from all departments and locations of the company must be able to access information on the servers in the Chicago Production department. The table below identifies the resources managed by the Production department, the users that require access to the resources, and the level of access they require.

Resource Users requiring access Access level
FormulasChicago Production Server AdministratorsFull control
FormulasChicago Production ManagersChange
FormulasChicago Production Specialists Read
FormulasAll Production Managers company-wideRead
Production LogsChicago Production Server AdministratorsFull control
Production LogsChicago Production Managers Change
Production LogsChicago Production Specialists Read
Production LogsChicago Distribution Managers Read
Production LogsAll Production Managers company-wideRead
Bottling LogsChicago Production Server AdministratorsFull control
Bottling LogsChicago Production Managers Change
Bottling LogsChicago Production Specialists Read
Bottling LogsChicago Distribution Managers Read
Bottling LogsAll Production Managers company-wideRead
Customer Service LogsChicago Production Server AdministratorsFull control
Customer Service LogsChicago Production Managers Change
Customer Service LogsChicago Production Specialists Read
Customer Service LogsChicago Distribution Managers Read
Customer Service LogsAll Production Managers company-wideRead
Customer Service LogsAll Distribution Managers company-wideRead

Exercise Questions

Complete the table below to document your security group design. Include the name of each security group, the group scope, and the members of the group. Also note whether the members are individuals or list group names if the members are groups.

to be completed

Group Scope Members

Answers

Review

The following questions are intended to reinforce key information presented in the chapter. If you are unable to answer a question, review the appropriate lesson and then try the question again. Answers to the questions can be found in Appendix A,"Questions and Answers."

  1. Your design team is getting ready to define OU structures for your organization's Active Directory infrastructure design. What are the three reasons for defining an OU? What is the primary reason?
  2. Your design team has defined an OU to delegate control of user objects. You have diagrammed the desired OU, diagrammed a security group, and listed the administrators who require control of the user object class in the group. You want to allow the OU to set its own membership. Where should the administrator group be placed?
  3. Your design team has defined a forest, domains, and OUs. Where should user accounts be placed?
  4. Your design team is assigning users to groups. Which group scope is most often used to assign permissions to resources?
  5. Your organization is running Windows 2000 in native mode. The design team is adding users to groups. Why shouldn't the team add individual users to universal groups?

Answers

Meet the Author

Developed by senior editors and content managers at Microsoft Corporation.

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >