You are on page 1of 44

Module 4: Designing the Administrative Structure

Contents Overview Lesson: Gathering Data for Designing an Administrative Structure Lesson: Designing a Network Administration Model esson: Designing an Organizational Unit Structure Lesson: Designing an Account Strategy Lab A: Designing the Administrative Structure 1 2 7 12 21 33

Information in this document, including URLs and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. 2003 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows NT, Windows Server, Active Directory, BackOffice, Microsoft Press, MSDN, PowerPoint, Visio, and Windows Media are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Module 4: Designing the Administrative Structure

iii

Instructor Notes
Presentation: 130 minutes Lab: 60 minutes This module provides students with the knowledge and skills necessary to design an effective administrative structure for network administration, and for Active Directory, as well. The module describes the kinds of data to gather for designing an administrative structure, and offers guidelines and strategies for designing a network administration model, an organizational unit structure, and an account strategy. After completing this module, students will be able to:
! ! ! !

Determine the information needed to design an administrative structure. Design a network administration model. Design an organizational unit structure. Design an account strategy.

Required materials

To teach this module, you need Microsoft PowerPoint file 2282A_04.ppt. Important It is recommended that you use PowerPoint 2002 or later to display the slides for this course. If you use PowerPoint Viewer or an earlier version of PowerPoint, features of the slides might not be displayed correctly.

Preparation tasks

To prepare for this module:


! ! !

Read all of the materials for this module. Complete the practices. Complete the lab, practice discussing the answers, and become familiar with the lab environment. Read the additional reading for this module, located under Additional Reading on the Web page on the Student Materials compact disc.

Classroom setup

The information in this section provides setup instructions that are required to prepare the instructor computer or classroom configuration for a lab. The computers in the classroom should be set up in the configuration specified in the Customization Information section at the end of the Automated Classroom Setup Guide for Course 2282A, Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure. No additional classroom setup is required to perform the lab in this module.

iv

Module 4: Designing the Administrative Structure

How to Teach This Module


This section contains information that will help you to teach this module. Note Depending on your students level of knowledge, some of the information contained in this module might be a review of existing knowledge. Assess your students before presenting this moduleyou might be able to present the information fairly quickly, particularly the lesson on designing an account strategy.

Lesson: Gathering Data for Designing an Administrative Structure


This section describes the instructional methods for teaching this lesson. In this lesson, students learn how to examine existing directory and administrative structures and how to gather the business information that is relevant to designing the administrative structure. The lesson focuses on how organizational resources and business requirements influence design decisions. Guidelines for Identifying the Existing Directory Structure Guidelines for Identifying Organizational Resources Guidelines for Identifying Administrative Resources Guidelines for Gathering Data for Administrative Structure Design Explain that before you can design a new administrative structure that will support Active Directory, you need to understand your organizations existing directory structure, including how and why it was created. Point out that because the eventual goal is to group the organizations resources into OUs for simplified management, you first need to determine what resources you have. Specifically, you need to gather information about existing hardware, job roles, and groups. As you discuss requirements for administration, emphasize that the question you really need to answer is: who needs to do what, and at what level?

Emphasize the need to get input from all stakeholders. If you havent discussed the term stakeholder with your class yet, now might be a good time. As it applies to an Active Directory or network infrastructure design, stakeholders are individuals and groups who have an interest in the success of the design and in the success of the organization as a whole. Possible stakeholders include corporate executives, company owners, board members, administrators, managers, operations groups, security groups, and so on. There is no practice for this lesson.

Practice

Lesson: Designing a Network Administration Model


This section describes the instructional methods for teaching this lesson. This lesson focuses on the need to identify the types of information technology (IT) groups that currently exist in an organization in order to have a baseline from which to design a network administration model. Special emphasis is placed on designing for security. Types of IT Administration Models Mention that the outsourced IT model can take the form of any of the other three models, depending on the outside vendors structure and the way it performs the IT services for an organization.

Module 4: Designing the Administrative Structure

Guidelines for Administration Security

Explain the principle of least privilege to students. This principle states that at any one time, a security principal (a user, computer, security group, etc.) should have exactly the permissions and rights it needs and no more. Requiring administrators to use the run as feature is an example of this principle. Restricting the membership of the Schema Admins group is also an example of this principle. In fact, some companies allow no user or group to be a member of the Schema Admins group until the schema actually has to be modified. Then the appropriate user(s) is added to the group for that time, and removed as soon as the modification is complete. This prevents accidental modification of the schema. Highlight the key point in this topic: you should base your network administrative model on your IT administrative model. When you discuss the guideline Limit the number of administrators who have control over an OU to only those who require it, point out that this is another example of the principle of least privilege. There is no practice for this lesson.

Guidelines for Designing a Network Administration Model

Practice

Lesson: Designing an Organizational Unit Structure


This section describes the instructional methods for teaching this lesson. This lesson provides strategies and guidelines for designing an organizational unit (OU) structure. Explain to students that creating an OU design involves designing an OU structure that is based on an organizations business requirements. When designing an OU structure, you must decide how to delegate control, consider how inheritance works, and understand how Group Policy settings influence your design. Strategies for Organizational Unit Structures Consider mentioning that the most widely used OU structure is probably the hybrid of location, then organization. Explain that its usually best to keep the highest level OUs based on locations, which typically dont change as often as organizational units. Emphasize that whether an organization decides to use object-based or taskbased delegation, best practices include: 1) Avoid assigning permissions at the attribute level and 2) Consider placing objects in separate OUs based on how they will be administered. For most students, this topic is probably a review, although inheritance can be a confusing topic. Remind students that inheritance flows down the OU structure from the parent OU to child OUs. Explain that there are tradeoffs involved depending on the number of GPOs you assign and the level (site, domain, OU, and so on) at which they are assigned. You have to balance the need for granular control against the increased administration required as the number of GPOs increases. Emphasize the need to create an OU design that requires the fewest GPOs possible. This greatly simplifies administration.

Strategies for Delegation of Control

Considerations for Inheritance Considerations for Group Policy Structure Design Guidelines for Designing an Organizational Unit Structure

vi

Module 4: Designing the Administrative Structure

Practice

The PowerPoint slide for this topic displays a graphic depicting the forest and domain structure of Northwind Traders. In this practice, students design an OU structure for Northwind Traders. Have students perform this practice in small teams. You can ask a member of each team to draw their teams design on a whiteboard or flip chart. Its okay for students to have different answers as long as they can justify their designs.

Lesson: Designing an Account Strategy


This section describes the instructional methods for teaching this lesson. This lesson describes how to design an effective strategy for creating, naming, and managing the various types of accounts in Active Directory, including user, computer, and group accounts. Special emphasis is placed on designing policies for passwords, authentication, authorization, and administration. Note Assess your students level of knowledge before presenting this lesson you might be able to present the information fairly quickly if students are already familiar with creating and managing accounts. Strategies for Accounts Strategies for Naming Accounts Guidelines for Designing a Password Policy Highlight the Inetorgperson account, which is new for Windows Server 2003. Emphasize the best practices for naming user, computer, and group accounts. Consider asking students what naming conventions are used at their companies. Explain that an organizations password policy should not be so complex that the only way users can comply is by writing their passwords on sticky notes. That said, you can mention that some companies do random walk-throughs of work areas to see if employees have left password information on their desks, on computer monitors, or on sticky notesthis is a huge breach of network security. When you discuss the require multi-factor authentication guideline, ask students if their companies require employees to use smart cards. As the price of using smart cards decreases, more organizations are requiring their use.

Guidelines for Designing Policies for Authentication, Authorization, and Administration Strategies for Security Groups Guidelines for Designing an Account Strategy Discussion

Explain that the purpose of these security groups strategies is simplified, flexible administration. Use this section to summarize and review the key topics covered in this lesson.

Review the account strategy questions listed on the discussion page. Ask students to answer the questions as they apply to their own organizations.

Module 4: Designing the Administrative Structure

vii

Lab A: Designing the Administrative Structure


In this lab, students use the lab browser to gather information about Tailspin Toys. Then, students use this information as a basis for designing an organizational unit structure. After completing this lab, students will be able to design an organization unit structure. Note To prevent confusion, at the start of the lab, remind students that in the practices they have been working with Northwind Traders, but in the labs they are working with Tailspin Toys. To begin the lab, open Microsoft Internet Explorer and then, on the Web page that appears, click the link for this lab. Play the video interviews for students, and then instruct students to begin the lab with their lab teams. Note that:
!

The e-mail message from Tad Orman lists several documents that will provide students with the information they need to complete this lab, including: Administrative Decisions and Acquisitions documents in the Network Files folder, and the Company Locations page on the Intranet Web site. The e-mail message from Michael Alexander provides the specific tasks that must be accomplished in this lab.

Give students approximately 20 to 25 minutes to complete their designs. Then spend approximately 15 to 20 minutes discussing the students designs as a class. Student answers will vary because there are several possible OU structure designs and no single correct solution. After the teams develop their designs, ask one person from each team to draw their teams design on a whiteboard or flip chart. Then you can discuss all of the teams designs as a class. Important Each team will carry forward their OU structure design solutions from this lab as they go forward and complete the remaining labs in this course. Keep the teams drawings on the whiteboard or flip chart throughout the remainder of the course. General lab suggestions For general lab suggestions, see the Instructor Notes for the Module 1 lab titled Preparing to Design an Active Directory Infrastructure in Course 2282A, Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure. Those notes contain detailed suggestions for facilitating the lab environment in this course.

viii

Module 4: Designing the Administrative Structure

Customization Information
This section identifies the lab setup requirements for a module and the configuration changes that occur on student computers during the labs. This information is provided to assist you in replicating or customizing Microsoft Official Curriculum (MOC) courseware. The lab in this module is dependent on the classroom configuration specified in the Customization Information section at the end of the Automated Classroom Setup Guide for Course 2282A, Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure. Important Although no computer configuration changes occur on student computers during the labs, the information gathered and many of the solutions produced in a lab carry forward to subsequent labs in the course. Therefore, if this course is customized and all of the modules are not used, or they are presented in a different order, when the instructor begins a lab the instructor might need to provide students with a possible answer from the previous lab(s) to use as a starting point for the current lab.

Module 4: Designing the Administrative Structure

Overview

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction This module focuses on designing the administrative structure of the network. It describes how to gather data for designing the administrative structure and provides guidelines for designing a network administration model. Typically, you base the network administrative model design on the information technology (IT) administrative structure of the organization. A key topic in this module is designing an organizational unit (OU) structure. A well-designed OU structure enables administrators to delegate authority, which reduces the workload of a centralized administrator. Finally, this module provides guidelines for designing an account strategy, including considerations for creating and naming user, computer, and group accounts. Objectives After completing this module, you will be able to:
! ! ! !

Determine the information needed to design an administrative structure. Design a network administration model. Design an organizational unit structure. Design an account strategy.

Module 4: Designing the Administrative Structure

Lesson: Gathering Data for Designing an Administrative Structure

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction In this lesson, you will learn how to examine your existing directory and administrative structures and gather the business information that is relevant to designing a new administrative structure. The lesson focuses on how organizational resources and business requirements influence your design decisions. After completing this lesson, you will be able to:
!

Lesson objectives

Explain how the existing directory structure influences the administrative structure design. Describe the organizational resources that influence the administrative structure design. Explain how requirements for administration influence the administrative structure design. Distinguish the relevant information needed to design an administrative structure.

Module 4: Designing the Administrative Structure

Guidelines for Identifying the Existing Directory Structure

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Key points Understanding how and why your existing directory structure was created will help you design a new or revised administrative structure that will support Active Directory. Use the data gathered from the following questions to identify if changes are necessary.
!

What were the business reasons for the current directory structure? For example, was it based on physical locations? On groups? Are the business reasons still valid? Does the original directory structure accommodate growth? Who currently owns the forest and domain? Should they continue in those roles? Who are the current service administrators? Is there a satisfactory number of people in that role? Should their responsibilities remain the same?

! !

Additional reading

For more information about Active Directory structure, see Designing the Active Directory Logical Structure under Additional Reading on the Web page on the Student Materials compact disc. For more information about delegation of administration, see Design Considerations for Delegation of Administration in Active Directory under Additional Reading on the Web page on the Student Materials compact disc.

Module 4: Designing the Administrative Structure

Guidelines for Identifying Organizational Resources

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Key points Identifying and categorizing resources is a key aspect of designing an administrative structure. Gathering information about resources enables you to design an administrative structure that accommodates all resource types. For example, you can create an organizational unit (OU) that contains all the Accounting printers that are used for reporting purposes. Include the following information about your organizations resources:
!

Hardware. Identify servers, computers, laptops, printers, and other hardware. Be sure to include: The function of each item. The physical location of each item. The number of each item. Include relevant details about the hardware, such as whether the printers are local or on the network

Job roles. Include each job role (e.g., marketing manager) and a description of the tasks for which that role is responsible. Determine which job roles have particular administrative requirements. Groups. Identify each group, such as a network services security group. Include a description of the roles that are included in the group.

Module 4: Designing the Administrative Structure

Guidelines for Identifying Administrative Resources

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Key points To create an effective administrative structure, you must identify and categorize your organizations resources by administrative function. Based on the information you gather, determine if the OU structure is based on job role, on administrative function, or on both. Gather the following information about your organization:
!

Administrative roles. Which of the following roles currently exist in your organization? Role administrators, such as sales administrators, facilities administrators, helpdesk administrators, services administrators, and data administrators. Functional group administrators, such as server administrators, printer administrators, and desktop administrators. Location administrators, such as corporate office administrators and branch administrators.

Requirements for administration. Ask the following questions: Which business units or individuals require the ability to create, modify, manage, and delete user accounts? Which business units or individuals require the ability to manage file and folder resources, including permissions? Which business units or individuals require the ability to manage group policy?

Module 4: Designing the Administrative Structure

Guidelines for Gathering Data for Administrative Structure Design

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Key points Gathering and analyzing relevant information is essential to creating an effective administrative structure. As you gather information, be sure to:
!

Collect data about the current directory structure, organizational resources, and current administrative roles. In order to design an effective administrative structure design that will support Active Directory, you need to understand your organizations existing administrative structure.

Get input from all stakeholders, such as IT administrators, managers, messaging administrators, and security groups. You need to interview administrator groups, management groups, administrators of e-mail and messaging servers, members of the department that manages network access security, and any other groups who have a vested interest in the administrative structure design.

Gather information about future requirements of the organization. It is vital that you gather information about the future needs and plans of the organization. Is the organization planning to expand in the next one to five years? Is it planning to move any of its major offices? Is it planning any mergers or acquisitions? Is it planning to spin off any divisions? The answers to these questions might significantly influence the type of administrative structure you design.

Gather data about security issues. Determine the organizations current security environment, and any specific organization or network security needs. Your administrative structure design should balance the business needs for accessing data and the security needs for controlling access to data.

Module 4: Designing the Administrative Structure

Lesson: Designing a Network Administration Model

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction A network administration model defines the structure and management of network administration within an organization. This lesson describes four different IT administrative models and describes guidelines for administration security and for designing a network administration model. After completing this lesson, you will be able to:
! ! !

Lesson objectives

Compare choices for network administration. Explain considerations for administration security. Design a network administration model based on relevant business requirements.

Module 4: Designing the Administrative Structure

Types of IT Administrative Models

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction An IT administrative model defines who is responsible for managing specific IT resources across an organizations network and the level of control that each administrator maintains. When you design an organizational unit structure, you define how to administer Active Directory resources. This results in an organizational unit structure that reflects the IT administrative model of your organization. Role of IT models in design If you can identify the type of administrative model an organization uses, you can then design upper-level organizational units that mirror the structure of the IT. This enables you to then assign administrative control of upper-level organizational units to the appropriate IT group in your organization.

Module 4: Designing the Administrative Structure

IT administrative models

To design the organizational unit structure for an organization, you must first identify the type of administrative model used by the existing IT organization. The following table describes and compares the most common types of administrative models used by IT organizations. Note Some companies use a hybrid IT administrative model that combines two or more of the models described in the table.
Centralized IT with Decentralized Administration IT organizations employ distributed management, where control is spread out across more than one location. A centrally located core IT team has responsibility for the base infrastructure services, but delegates most of the day-to-day operations to IT groups in branch offices, which provide local administrative support to their users.

Centralized IT The IT organization reports to a single individual.

Decentralized IT This model allows various business units to select an appropriate IT model to serve the needs of each individual unit This model might have multiple IT groups with varying needs and goals. Whenever there are organization-wide technology initiatives, such as an upgrade to an organization-wide messaging application, the IT groups must work together to implement changes.

Outsourced IT Organizations outsource all or part of their IT organization.

The central IT organization is responsible for all network and information services, although some day-to-day tasks might be delegated to certain groups or departments.

When only parts of the IT organization are outsourced, it is essential that you have additional security to handle the higher level risk that is inherent with outsourcing.

10

Module 4: Designing the Administrative Structure

Guidelines for Administration Security

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction A primary consideration in designing a network administration model is to provide the right access to the right group for the right object. Therefore, you must incorporate secure administrative practices into your network administration model design. When designing a network administration model, be sure to:
! !

Secure administrative practices

Limit exposure by limiting the number of service administrator accounts. Use the run-as feature to perform administrator functions. Use your user account for day-to-day functions. Assign the domain Administrator account a complex password, then rename this Administrator account, and then disable it. Restrict the membership of the Schema Admins group to temporary members. Restrict rights to only those administrators who actually require them. Require smart cards for administrative logon. Prohibit administrators from using cached credentials when unlocking an administrative console. Prohibit administrators from running applications in administrative contexts. Secure traffic between administrative workstations and domain controllers, and require Internet Protocol security (IPSec) on administrative workstations.

! ! !

! !

Module 4: Designing the Administrative Structure

11

Guidelines for Designing a Network Administration Model

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Guidelines Determining your network administration model is an important design task because it will form the foundation for your organizational unit (OU) structure. To create an effective design, use the following guidelines:
!

Base your network administrative model on your IT administrative model, not on your organizations management structure. Achieve balance between ease of administration and detailed organization of resources. If you create a design with many levels of administration, it will require more management time. Conversely, if your design has too few levels of administration, it might not allow for necessary delegation of control.

Create your design based on solid security principles. Limit the number of administrators who have control over an OU to only those who require it. Audit the changes administrators make. Audit the changes to who can administer OUs.

12

Module 4: Designing the Administrative Structure

Lesson: Designing an Organizational Unit Structure

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction You can organize objects in a domain to simplify the administrative tasks of an organization. A well-designed organizational unit (OU) structure reflects the IT administrative model of the organization and enables administrators to delegate authority, which reduces the workload of a centralized administrator. Before you design an OU structure, you must first understand how your organization implements the IT administrative model, and the way that the model is structured. You must also consider strategies for delegation of control, including object-based and task-based delegation of control. In addition, you must consider inheritance and Group Policy. Lesson objectives After completing this lesson, you will be able to:
! ! ! ! !

Compare choices for OU structures. Explain considerations for delegation of control. Explain considerations for inheritance. Explain how Group Policy design influences the OU design. Design an OU structure based on relevant business requirements.

Module 4: Designing the Administrative Structure

13

Strategies for Organizational Unit Structures

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction After you determine the best network administration model for your organization, you need to structure the model so that it reflects the way that the organization manages its IT resources. These resources include users, computers, groups, printers, and shared files. The structure of the administrative model shows how the people or groups responsible for managing specific resources are organized.
!

Identifying the structure of the administrative model will help you determine how to make your OU design mirror the IT organization structure and the IT resource management structure. When designing an OU structure, ensure that it can accommodate change and growth in your organization. Organizational changes should not affect the OU structure.

14

Module 4: Designing the Administrative Structure

Strategies for OU structures


Description Location-based

The following table describes different strategies for OU structures. The table also describes the characteristics of each of the strategies, which will help you decide which strategy to use for your OU structure design.
Advantage Disadvantage

You can organize your OUs by location at the higher levels of the tree if the IT organization is centralized, but network administration is geographically distributed.

Resistant to company reorganization Accommodates mergers and expansions

Possible security compromises because if a location includes multiple divisions or departments, an individual or group with administrative authority over that domain or OU might also have authority over any child domains or OUs Need network administrators at each location

Organization-based You can organize the OUs at the higher levels in the tree by department or business unit if the IT organization is divided into departments or business units so that each has its own IT group. Function-based You can organize the OUs at the higher levels in the tree by function if the IT organization is decentralized, but bases its administrative model on business functions within the organization. This is an ideal choice for small organizations that have job functions that span several departments. A hybrid of location, then organization You can organize the OUs or domains that are higher in the hierarchy by location, and then organize the OUs or domains that are lower in the hierarchy by organization. A hybrid of organization, then location You can organize the OUs or domains that are higher in the hierarchy by organization, and then organize the OUs or domains that are lower in the hierarchy by location. Allows for strong security between departments or divisions, while still allowing administrative delegation based on a physical location Vulnerable to reorganization Allows for additional departmental and divisional growth Allows for distinct security boundaries Requires a new design if the IT organization becomes decentralized Requires cooperation among IT administrators if they are in the same location but different departments Immune to reorganization Might impact replication Might be necessary to create additional layers in the OU hierarchy to accommodate administration of users, servers, printers, and network shares Maintain departmental and divisional autonomy Accommodates mergers and expansions Might impact replication Vulnerable to reorganization

Module 4: Designing the Administrative Structure

15

Strategies for Delegation of Control

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction You can base administrative delegation on objects or tasks. First, determine the administrative tasks, the level of delegation, and the objects that will be affected. Then you can base your design for delegation of control based on objects or tasks. In this type of OU design, delegation of control is based on object types. Examples of objects include users, computers, sites, domains, and organizational units. You can delegate the administration of objects within the OU to a designated individual or group. To delegate administration by using an OU, place the individual or group to which you are delegating administrative rights into a group, place the set of objects to be controlled into an OU, and then delegate administrative tasks for the OU to that group. In this type of OU design, delegation of control is based on administrative tasks that must be accomplished, such as resetting passwords or creating, deleting, and managing user accounts in the OU. Determining whether to use object-based or task-based delegation depends on the administrative model used in the organization. However, use the following best practices when delegating control of objects: 1. Avoid assigning permissions at the task or attribute level. Assigning permissions at this level is time-consuming, thereby increasing administrative overhead. It is also difficult to document administrative authority. 2. Consider placing objects in separate OUs based on how they will be managed. This allows for inheritance, easier documentation, and better troubleshooting.

Object-based delegation of control

Task-based delegation of control Best practices for delegation of control

16

Module 4: Designing the Administrative Structure

Considerations for Inheritance

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Why use inheritance? Inheritance is an efficient way to grant or delegate permissions to objects. Objects that you create inherit the parent object permissions. The advantage of inheritance is that an administrator can manage permissions of all objects in an OU by setting permissions on the OU without having to configure all of the child objects individually. Administrators can assign permissions to an object only; an object and all of its child objects; child objects only; or specific types of child objects, such as computers, users, or groups. In Active Directory, the permissions on directory objects are stored as attributes of the objects. When an object is created, its Discretionary Access Control List (DACL) contents are determined, based on the default permissions for the type of object in the schema and the permissions on the parent container. These permissions can then be modified as needed. Considerations for using inheritance When creating the OU design, take the following into consideration if you plan to use inheritance: 1. Organize your OUs to take advantage of inheritance. Logically organize your OUs to create a simple structure in which the permissions that apply to a parent OU apply to child OUs. 2. Limit administrative control. At times, you might need the specific permissions on an object to override the permissions that might be inherited from a parent. You can block inheritance of the permissions that apply to a parent OU so that they do not apply to the child OU.

Module 4: Designing the Administrative Structure

17

Considerations for Group Policy Structure Design

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Group Policy objects and OUs You can use Group Policy to define user and computer configurations and associate policy settings with sites, domains, or organizational units. If you apply a Group Policy object (GPO) at the site or domain level, it affects more objects than if you apply a GPO at an organizational unit level. However, you also have less control over each individual object. Creating GPOs for organizational units gives you precise control over applying Group Policy settings, because it eliminates the need to filter Group Policy settings. Creating GPOs for organizational units also means that there are more GPOs to manage. Conflicts between GPOs can occur, because organizational units can be nested and because Group Policy is inherited from parent organizational unit to child organizational unit. Design organizational units and GPOs carefully to reduce conflicts caused by Group Policy inheritance. Considerations for adding OUs to support Group Policy In addition to modeling the organizations administrative structure, consider the following when designing for group policy:
!

Subdivide an OU. An OU that contains users that are managed by a single administrator might need to be subdivided when there are two distinct groups of users in the OU that have different Group Policy requirements. Create new OUs based on location. For example, you might have Group Policy settings which need to be applied to all users or all computers in a specific location. In this case you might need to create an OU for the location, and then subdivide it by administrative functions as needed. Create new OUs based on type of object, such as users or computers. For example, you might need to create an OU high up in the tree that contains all of the users or all of the computers in an organization, department, or location so that a GPO can be created that applies to all of these users.

18

Module 4: Designing the Administrative Structure

Guidelines for Designing an Organizational Unit Structure

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Guidelines Guidelines for designing an organizational unit structure in Active Directory include:
!

Delegate control at the highest organizational unit level and take advantage of inheritance whenever possible. If you delegate control at the highest organizational unit level possible rather than on individual objects, managing permissions will be much easier and more efficient. In addition, there is less potential for damage if an administrator makes a mistake while logged on with an administrative account.

Avoid assigning permissions at the property or task level as much as possible to simplify administration. When permissions are assigned at the property or task level, the complexity of permissions assignment is increased dramatically and troubleshooting permissions becomes very difficult.

Create an organizational unit design that requires the use of the fewest GPOs possible. The more GPOs you have associated with any object, the more network traffic will be generated and the longer it will take for users to log on to the network. Create lower-level organizational units based on the need for GPOs.

Create additional organizational units to avoid the need to use filters to exempt a group of users in an organizational unit from a GPO. The need to filter GPOs can be reduced by creating additional organizational units, thereby isolating the users or computers that require certain policy settings.

Module 4: Designing the Administrative Structure

19

Practice: Designing an Organizational Unit Structure

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Company background In this practice, you will design an organizational unit structure for Northwind Traders. Northwind Traders manufactures a line of network appliances that are designed to help companies improve their data transmission capabilities. Northwind Traders currently uses a Microsoft Windows NT 4.0 master domain model. In recent years, the company has undergone significant growth and expansion. The company expects substantial growth over the next three years, including growth in market share, revenue, and number of employees. In addition to opening two new offices, the executive management has committed to implementing a new Windows Server 2003 Active Directory design to meet the current and future needs of the company. The following table shows the geographical locations, the departments residing in each location, and the number of users in each of the locations.
Location Paris, France Departments represented Headquarters (HQ) Management staff Finance Sales Marketing Production Research Development Information Technology (IT) Los Angeles, CA, United States Sales Marketing Finance IT 1,000 Number of users 2,000

20

Module 4: Designing the Administrative Structure (continued) Location Atlanta, GA, United States Departments represented Customer Service Customer Support Training Glasgow, Scotland Research Development Sustained Engineering IT Sydney, Australia Consulting Production Sales Finance 500 750 Number of users 750

User accounts

The following table shows the user account information.


Users All personnel in Sales and Marketing All personnel in Production All personnel in Research and Development All personnel in Finance Have user accounts in(domain) NAwest domain AsiaPacific domain Glasgow domain Corp domain

Forest and domain design Practice

Northwind Traders has already decided on its forest and domain design, as illustrated in the diagram on the PowerPoint slide. Based on the newly approved forest and domain design, create the organizational unit structure for Northwind Traders. Use the table to complete your design.
Domain Corp.nwtraders.local Organizational units HQ Management Finance IT NAwest.nwtraders.local Sales Marketing IT NAeast.nwtraders.local Customer Service Customer Support Training Glasgow.RDNwtraders.local Research Development Sustained Engineering IT AsiaPacific.nwtraders.local Consulting Production

Module 4: Designing the Administrative Structure

21

Lesson: Designing an Account Strategy

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Creating and managing user accounts, computer accounts, and group accounts is the largest part of administering Active Directory. Therefore, administration is easier if you have an effective strategy for performing these actions. After completing this lesson, you will be able to:
! ! ! !

Lesson objectives

Compare choices for account strategies. Identify strategies for naming conventions. Describe guidelines for designing password policies. Describe guidelines for designing authentication, authorization, and administration policies. Explain considerations for security group strategies. Explain considerations for user and computer account strategies. Design an account strategy based on relevant business requirements.

! ! !

22

Module 4: Designing the Administrative Structure

Strategies for Accounts

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction You can create five types of accounts in Active Directory: user, inetorgperson, contact, group, and computer accounts.
!

An Active Directory user, inetorgperson, contact, or computer account represents a physical entity, such as a computer or person. You can also use user and inetorgperson accounts as dedicated service accounts for some applications.

User accounts

A user account is an object stored in Active Directory that enables single sign-on. A user enters her name and password only once when logging on to a workstation to gain authenticated access to network resources. There are three types of user accounts, each of which has a specific function:
!

A local user account enables a user to log on to a specific computer to access resources on that computer. A domain user account enables a user to log on to the domain to access network resources and to log on to an individual computer to access resources on that computer. A built-in user account enables a user to perform administrative tasks or gain temporary access to network resources.

Inetorgperson accounts

An inetorgperson account is a domain account that functions in the same manner as a user account. Inetorgperson accounts are compatible with other Lightweight Directory Access Protocol (LDAP)-compatible directory services. These other directory services use inetorgperson account objects instead of user account objects. In Windows Server 2003, you can use either user account objects or inetorgperson account objects to enable users to log on and access resources. If you have other directory services on your network, use inetorgperson accounts instead of user accounts.

Module 4: Designing the Administrative Structure

23

Contact accounts

A contact account is an object that is stored in Active Directory that does not have any security permissions. You cannot log on to the network as a contact. Contacts are typically used to represent external users for the purpose of e-mail. Each computer running Microsoft Windows NT, Windows 2000, or Windows XP, or a server running Windows Server 2003 that joins a domain, has a computer account. Like user accounts, computer accounts provide a way to authenticate and audit computer access to the network and to domain resources. Each computer account must be unique. Note NT 4.0 computers that have not been updated to service pack 4 or higher cannot authenticate to a Windows Server 2003 Active Directory Domain unless SMB signing is turned off in the domain.

Computer accounts

Group accounts

A group account is a collection of users, computers, or other groups. You can use groups to efficiently manage access to domain resources, which helps simplify administration. When you use groups, you assign permissions for shared resources, such as folders and printers, only oncerather than multiple timesto individual users. When designing an account strategy, consider the following:
!

Considerations for designing an account strategy

What naming convention best suits the organization and makes searching for an account in Active Directory efficient? If a user account has the unique information in the first few characters, it will be easier to locate. For example, if user accounts named Michael Alexander and Michael Allen, are searched for, you must type nine characters to find the one you are searching for. If the user accounts are named Malex and Mallen, then you must type only four characters to find the one you are searching for.

Does the account strategy cover possible contingencies in accounts? Do the user account and the contact account conflict? For example, if there is a user account for Michael Alexander and a user account for Michelle Alexander, there must be additional information to differentiate between the user accounts. You add the last letter of their first names, such as in MlAlexander and MeAlexander, to differentiate between the user accounts.

How will different accounts be identified? Determine what, if any, kind of identifier you will use for user accounts, contact accounts, computer accounts, and group accounts. You can place an identifier in the computer account name that designates the location of that computer. For example, you can place characters in the beginning of a computer account name to identify the location and role of the computer. You can add the prefix MinNDwks to the name of a workstation in Minot, North Dakota, to identify its location and role.

24

Module 4: Designing the Administrative Structure

Strategies for Naming Accounts

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction When you create an account strategy for the forests and domains in your organizations network, you must set up conventions for naming user, computer, and group accounts in a Windows Server 2003 network. Define a user account naming convention for your organization that makes the user names easy for other users to identify and enables you to manage user name conflicts for users who have very similar names. The naming convention should include:
!

Naming a user account

The users first name, the first three characters of it, or the first initial of the user. For example, use Brenda for the user Brenda Diaz. The first initial, the first few letters of the users last name, or the complete last name of the user. For example, use BDiaz for the user Brenda Diaz. Additional characters from the first or last name, or the users middle initial, to resolve naming conflicts.

Consider using:
!

Prefixes or suffixes to identify special user account types, such as contractors, part-time personnel, and service accounts. An alternative domain name for the userPrincipalName (UPN) suffix to increase logon security and simplify logon names. For example, if your organization has a deep domain tree that is organized by department and region, domain names can get quite long. The default UPN suffix for a user in that domain could be sales.example.nwtraders.msft. The logon name for a user named Brenda Diaz in that domain could be BDiaz@sales.example.nwtraders.msft. However, if you create the suffix nwtraders or nwtraders.msft, a user can log on by using the much simpler logon name of BDiaz@nwtraders or BDiaz@nwtraders.msft. It is not necessary for these alternative UPN suffixes to be valid DNS names.

Module 4: Designing the Administrative Structure

25

Naming a computer account

Define a computer account naming convention that identifies the computers owner, location, and computer type. The following table describes computer account naming conventions.
Naming convention Owners user name Location or an abbreviation Type of computer or an abbreviation Example BDiaz1 RED or Redmond SVR or server

For example, a server computer that belongs to Brenda Diaz in the Redmond location could be named BDIAZ1_RED_SVR. Naming a group Define a group naming convention that identifies the groups type, location, and the purpose. The following table describes group naming conventions.
Naming convention Group type Location of the group Purpose of the group Example G for global group, UN for universal group, DL for domain local group Red for Redmond Admins for administrators

For example, a domain local group in the Redmond location that had administrative permissions could be named DL_RED_Admins.

26

Module 4: Designing the Administrative Structure

Guidelines for Designing a Password Policy

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Designing an effective password policy is an important part of designing your networks administrative structure. The role that passwords play in securing an organizations network is often underestimated and overlooked. Passwords provide the first line of defense against unauthorized access to your organization. The Windows Server 2003 family includes a new feature that checks the complexity of the password for the Administrator account. If the password is blank or does not meet complexity requirements, the Windows Setup dialog box appears, warning you about the dangers of not using a strong password for the Administrator account. Also, if you leave the password blank, you cannot access the account over the network. A password policy ensures that every user is following the password guidelines that you determine are appropriate for your organization. Consider the following guidelines when you design a password policy:
!

Windows Server 2003 family password security

Password guidelines

Require the enforcement of password history. The default setting is 24 passwords remembered. This way, users cannot use the same password when their password expires. Require the enforcement of a maximum password age. The default setting is 42 days. Guidelines recommend that you require users to change their passwords at regular intervals, as often as necessary for your environment and the access level of users. This prevents an attacker who cracks a password from accessing the network after the password expires. For users who have domain administrator access, set the maximum password age lower than that for normal users. Require the enforcement of a minimum password age. The default setting is one day. Its a good idea to require users to keep a password for a certain number of days, so that users cannot repeatedly change their passwords until they have satisfied the requirements for the number of unique passwords and change back to their original password.

Module 4: Designing the Administrative Structure


!

27

Require the enforcement of a minimum password length. The default setting is seven characters. Passwords should consist of at least a specified minimum number of characters. Long passwordsat least eight charactersare usually more difficult to discover than short ones. Require complex passwords. The default setting for this policy is Enabled. Passwords that contain multiple different types of characters are less susceptible to dictionary attacks than passwords that are all lowercase characters or all numbers.

Tip If you create a root domain in your forest for the purpose of placing administrative accounts, consider requiring more stringent password policy settings on this domain than on your account domains. For example, consider requiring a maximum password age of 30 days, a minimum password age of seven days, and a minimum password length of 14 characters. Other guidelines to consider when designing a password policy:
!

If your organization requires high security, view the Security Templates for various recommended password policy settings for domain controllers in secure or high security environments. Consult industry guidelines for specific recommendations on password policy settings.

28

Module 4: Designing the Administrative Structure

Guidelines for Designing Policies for Authentication, Authorization, and Administration

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Designing an account authentication, authorization, and administration strategy will help protect your organizations network. For example, an account lockout policy can help prevent an attack on your organization. However, use care when you create an account lockout policy to avoid unintentionally locking out authorized users. Use the following guidelines to create a design for authentication, authorization, and administration for your organization:
!

Guidelines

Require that the account lockout threshold be set to a high value. This way authorized users are not locked out of their user accounts if they mistype a password. If this setting is too low, users who have trouble typing the long, complex passwords specified in your password policy will often get locked out while trying to log on. Try to strike a balance between locking users out and preventing attackers from being able to guess passwords. Require administrators to log on as regular users. Require administrators to log on by using a regular user account and to use the run as command to perform all administrative tasks. Also, minimize the number of users who are members of the Administrators group in the domain. Instead, consider delegating control over a portion of the directory to users who must administer that portion of the directory. Require multi-factor authentication. For example, require smart cards for administrative accounts and remote access to help validate that the user is who he claims to be. Require that the Administrator account in the domain be renamed and disabled. You can never delete or remove the Administrator account from the Administrators built-in group. However, it is a good practice to rename and disable the account.

Module 4: Designing the Administrative Structure

29

Strategies for Security Groups

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction The scope of a security group dictates who can belong to the group and what permissions that group can be granted. Add user accounts to global groups rather than to universal or domain local groups. Try to create a global group in each domain for each job description. Create further groupings by nesting the global groups in other global groups. Add global groups to universal groups. Because universal group membership is replicated to all global catalog servers every time it changes, try to keep the universal group membership static. Instead of creating redundant universal groups, use nesting whenever possible. Use security groups based on the A-G-G-U-DL-P strategy. This strategy provides the most flexibility while also reducing the complexity of assigning access permissions to the network. Also, implement a role-based security model for granting permissions. In the A-G-G-U-DL-P strategy:
! ! ! ! !

Strategies for global groups

(A) Add user accounts to global groups (G). Add global groups to other global groups (G). Add global groups to universal groups (U). Add universal groups to domain local groups (DL). Assign resource permissions (P) to domain local groups.

30

Module 4: Designing the Administrative Structure

Strategies for domain local groups

Usually, you only need to add global groups to domain local groups. You can also add global groups to a universal group and then add the universal group to a domain local group. However, creating a universal group solely for this purpose is not recommended, because the security requirements of each global group might change. Consider the following strategies:
!

Grant rights and permissions to domain local groups, instead of global or universal groups, for greater flexibility and less complex administration. Delegate the authority to manage group memberships. If you follow these strategies, the resource owners can manage access to their resources in the domain local groups, and assistant administrators can manage the membership of global groups. However, only Enterprise Admins can manage the membership of universal groups.

Module 4: Designing the Administrative Structure

31

Guidelines for Designing an Account Strategy

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Design guidelines for user and group accounts Because creating and managing user and group accounts is a substantial part of administering the network, it is important to have an effective account strategy design. Consider the following guidelines:
!

Specify the appropriate type of account for each user. Use user accounts for all users who need to log on and authenticate to the domain, unless you need to interoperate with another directory service. If you have multiple directory services in use on your network, use inetorgperson accounts instead of user accounts. Use contacts for users that people in your organization need to be able to send e-mail to, but who do not need to log on to your network. Specify a password policy that meets your organizations security needs. This can be a balancing act. If you specify a password policy that is not stringent enough, it might be possible for unauthorized users to access your resources due to password compromise. If you make your policy too strict, it will become very difficult for users to remember their passwords. Require an appropriate authorization strategy for your network. Include an account lockout strategy, as well as the use of multi-factor authentication for accounts with very high privilege levels, such as administrator accounts. Specify a naming strategy for groups that includes a prefix that identifies the type of group. Universal, global, domain local, and computer accounts should be named so that their function and location are easily identifiable. Create a user account naming strategy that is flexible and supports growth. For example, if two divisions create an incompatible user account naming strategy, interoperability between these divisions is complicated. Ensure that user and group accounts are easily searchable. If you make the initial characters in user and group names unique, it will be easier to search for an account in Active Directory. For instance, differentiate between full time employees, vendors, and temporary employees.

32

Module 4: Designing the Administrative Structure

Discussion: Designing an Account Strategy

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Discussion Work as a class to create a set of minimum requirements for account strategy. Use the following questions to guide your discussion regarding account strategy: 1. What are the naming conventions that you have in your organization? 2. What password requirements do you have in your organization? 3. What group strategies do you use on your network? Answers will vary based on the work experience of the students who are participating in the class.

Module 4: Designing the Administrative Structure

33

Lab A: Designing the Administrative Structure

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Objectives Scenario After completing this lab, you will be able to design an organizational unit structure. You are a consultant who has been hired to design an organizational unit structure for Tailspin Toys. The lab uses an interactive application to convey scenario-based information. To begin this lab, open Internet Explorer, and then, on the Web page that appears, click the link for this lab. View the videos, read the e-mail messages and other company documents, and then, using the exercise below as a guide, complete the tasks that are assigned in the e-mail messages. Estimated time to complete this lab: 60 minutes Your instructor will break the class into groups to do the lab. Each group should be prepared to present their design to the class at the end of the lab.

34

Module 4: Designing the Administrative Structure

Exercise 1 Designing an Organizational Unit Structure


In this exercise, you will design an OU structure for the Tailspin Toys organization. Tailspin Toys needs to maintain control over the entire enterprise, except for the Finance department, but also needs to delegate control of its subsidiaries to their existing IT personnel. Use the information you have gathered in previous labs and the new information presented in the scenario to create your OU structure design. In the space below, draw the organizational unit structure you will use for Tailspin Toys. If your design includes multiple domains, document the OU structure you will use for each domain. Use additional sheets of paper if necessary. Answers may vary; the drawings below represent one possible answer. Many other possible OU designs can be created and justified given the information that is available to students in the lab scenario. In the answer below, the OU design is based on the geographically distributed nature of the organization, with location-based OUs higher in the tree, and function/department-based OUs lower in the tree. Two forests are represented, one for the Finance department and one for Tailspin and its subsidiaries. Finance Forest OU Structure:

Module 4: Designing the Administrative Structure

35

Tailspin Toys Forest OU Structure:

THIS PAGE INTENTIONALLY LEFT BLANK

You might also like