Tài liệu Module 3: Designing Active Directory to Delegate Administrative Authority docx

Contents
Overview 1
Identifying Business Needs 2
Characterizing the IT Organization 4
Developing a Strategy for Administrative
Design 5
Developing a Strategy for Delegation 15
Lab A: Designing Delegated
Administration 24
Review 35

Module 3: Designing
Active Directory to
Delegate Administrative
Authority


Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

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.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Windows, Windows NT, Active Directory, BackOffice, PowerPoint, Visual Basic, and
Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the
U.S.A. and/or other countries.

The names of companies, products, people, characters, and/or data mentioned herein are fictitious
and are in no way intended to represent any real individual, company, product, or event, unless
otherwise noted.

Other product and company names mentioned herein may be the trademarks of their respective
owners.

Project Lead: Andy Sweet (S&T OnSite)
Instructional Designers: Andy Sweet (S&T OnSite), Ravi Acharya (NIIT), Sid Benavente,
Richard Rose, Kathleen Norton
Instructional Design Consultants: Paul Howard, Susan Greenberg
Program Managers: Lorrin Smith-Bates (Volt), Megan Camp (Independent Contractor)
Technical Contributors: Angie Fultz, Lyle Curry, Brian Komar (3947018 Manitoba, Inc.), Jim
Clark (Infotec Commercial Systems), Bill Wade (Excell Data Corporation), David Stern, Steve
Tate, Greg Bulette (Independent Contractor), Kathleen Cole (S&T OnSite)
Graphic Artist: Kirsten Larson (S&T OnSite)
Editing Manager: Lynette Skinner
Editor: Jeffrey Gilbert (Wasser)
Copy Editor: Patti Neff (S&T Consulting)
Online Program Manager: Debbi Conger
Online Publications Manager: Arlo Emerson (Aditi)

Online Support: Eric Brandt (S&T Consulting)
Multimedia Development: Kelly Renner (Entex)
Testing Leads: Sid Benavente, Keith Cotton
Testing Developer: Greg Stemp (S&T OnSite)
Compact Disc and Lab Testing: Testing Testing 123
Production Support: Ed Casper (S&T Consulting)
Manufacturing Manager: Rick Terek (S&T OnSite)
Manufacturing Support: Laura King (S&T OnSite)
Lead Product Manager, Development Services: Bo Galford
Lead Product Managers: Dean Murray, Ken Rosen
Group Product Manager: Robert Stewart

Module 3: Designing Active Directory to Delegate Administrative Authority iii


Instructor Notes
Microsoft
®
Windows
®
2000 Active Directory
™
provides administrators with
control over who has access to information in Active Directory. This module
identifies strategies for planning the hierarchy of an Active Directory structure
that best supports the delegation needs of an organization. The module also
discusses how to manage permissions on directory objects and properties. By
directly managing permissions, administrators can specify precisely which
accounts can access the directory and the level of access that they can have.
At the end of this module, students will be able to:

!
Identify the administrative needs of an organization that impact an Active
Directory design.
!
Develop a strategy for administrative design of Active Directory.
!
Develop a strategy for administrative delegation at the site, domain, and
organizational unit (OU) level.

Lab A, Designing Delegated Administration, begins with hands-on exercises in
which the student will be given predefined requirements for the delegation of
administrative authority within an organization. The student will run a script
that implements a delegation design scenario for testing purposes. The student
will then examine and test the design against the predefined requirements to
determine whether or not the design is successful. In the scenario-based
exercises, the students will work in pairs to determine a delegation strategy for
a small and a medium organization. The students will create an OU design to
meet the business and administrative needs of the organizations and defend
their designs to the class. As you lead the discussion, be sure to reinforce best
practices and map design decisions back to business needs.
Materials and Preparation
This section provides you with the materials and preparation needed to teach
this module.
Required Materials
To teach this module, you need the following materials:
!
Microsoft PowerPoint
®
file 1561b_03.ppt
!

Visio 2000

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the lab.
!
Practice the demonstration.
!
Read the following technical white paper located on the Trainer Materials
compact disc:
• Chapter 11, “Planning Distributed Security,” of the Windows 2000
Server Resource Kit Deployment Planning Guide
Presentation:
75 Minutes

Lab:
60 Minutes
iv Module 3: Designing Active Directory to Delegate Administrative Authority


Instructor Setup for a Lab
This section provides setup instructions required to prepare the instructor
computer or classroom configuration for a lab.
Lab A
1. Make sure you have a share titled \\London\solutions.
2. Stress to the students that the validation portion of the lab will be in two
parts: one to delegate authority and another to test it.

3. Make sure the students do not create a design with too many details, such as
Group Policy or security groups, for the OU structure in the design portion
of the lab. The design should reflect the OU structure only.
4. Be certain to discuss the design exercises with the students after the lab is
complete.

Demonstration
This section provides demonstration procedures that will not fit in the margin
notes or are not appropriate for the student notes.
Visio 2000 Enterprise Edition
!
To start the Visio 2000 Active Directory template
1. Start Visio 2000 Enterprise Edition.
2. Select Choose drawing type in the Create new drawing dialog box and
click OK.
3. In the Choose Drawing Type dialog box, select Network Diagram in the
Category list, select Active Directory in the Drawing type window, and
then click OK.
4. Ensure that Work offline is selected, and then click OK in the Connect to
Directory dialog box.

!
To start an Active Directory drawing
1. Drag the Domain shape from the Active Directory Objects stencil on the
right side of the window on to the drawing page.
2. Use the toolbar at the top of the Visio window to zoom in on the domain
shape.
3. Select the shape, and then type nwtraders.msft to name it. Press ESC to
accept the change.
4. Drag the Organizational Unit shape from the Active Directory Objects

stencil and place it on the existing domain shape. Type Paris and then press
ESC.
5. Drag two more Organizational Unit shapes onto the domain shape from
the Active Directory Objects stencil. Name the OUs by clicking on them
and typing Denver and Singapore.
Module 3: Designing Active Directory to Delegate Administrative Authority v


6. Drag an Organizational Unit shape onto the Singapore OU. Type
Bangalore and then press ESC.
7. Drag an Organizational Unit shape onto the nwtraders.msft domain and
name it Marketing.

!
To modify the drawing
1. Select the Marketing OU in the Directory Navigator window and press
DELETE.
Deleting the OU in the drawing window will only delete it from the
drawing. Right-clicking the parent shape and selecting show children will
cause the shape to reappear. The only way to permanently delete a shape is
to delete it from the Directory navigator.
2. Drag the Bangalore shape in the drawing window so that it is on top of the
nwtraders.msft shape.
This will move the shape so that it is at the same level as the other OUs.
3. Right-click the nwtraders.msft domain shape and select Layout children.
Select one of the Vertical layouts, and then click OK.

!
To view other shapes
1. Show students the other shapes that are in the Active Directory objects

stencil.
2. View the Active Directory Sites and Services stencil by clicking on Active
Directory Sites and Services in the lower left corner of the Visio window.
3. Show students the shapes in this stencil as well.

Module Strategy
Use the following strategy to present this module:
!
Identifying Business Needs
Begin the module by describing methods to identify and document the
administrative needs of an organization as they relate to an Active Directory
design.
!
Characterizing the IT Organization
This page describes how the Information Technology (IT) organization can
be characterized. Emphasize the importance of designing an Active
Directory structure to meet IT needs.
!
Developing a Strategy for Administrative Design
This section describes the different strategies of designing the Active
Directory in compliance with the administrative model of the organization.
Explain in detail the common strategies used to design an Active Directory
hierarchy, and discuss how these strategies can be combined into hybrid
hierarchies.
!
Developing a Strategy for Delegation
The section describes the strategies used for delegating authority. Describe
how both object-based and task-based administrative authority can be
delegated within an Active Directory structure. Explain the guidelines for
determining the appropriate level of delegation.

vi Module 3: Designing Active Directory to Delegate Administrative Authority


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 includes a script to be run at the beginning and end of
the lab, creating and returning the computer to the default configuration for the
course. As a result, there are no lab setup requirements or configuration changes
that affect replication or customization.
Module 3: Designing Active Directory to Delegate Administrative Authority 1


Overview
! Identifying Business Needs
! Characterizing the IT Organization
! Developing a Strategy for Administrative Design
! Developing a Strategy for Delegation


Microsoft
®
Windows
®
2000 Active Directory
™
provides network architects
with control over information access in Active Directory. By structuring the

Active Directory hierarchy and then managing the permissions on directory
objects and properties, you can precisely specify the accounts that can access
the directory and the level of permissions that they can have. For example, you
can give a person authority over user passwords in a particular organizational
unit (OU), without giving that person any control over other objects or
attributes in Active Directory. This precise specification allows administrators
to delegate specific authority over portions of the directory to groups of users,
without making directory information vulnerable to unauthorized access.
At the end of this module, you will be able to:
!
Identify the business needs of an organization that will impact the
hierarchical design of Active Directory.
!
Develop a strategy for planning an administrative design that facilitates
delegation.
!
Develop strategies for delegation of administrative authority.

Slide Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about the different strategies
that are used to delegate
administrative authority by
using Active Directory.
2 Module 3: Designing Active Directory to Delegate Administrative Authority

Identifying Business Needs
Documenting the
Administrative Process:
#Level of Administration
#Who Administers What
#Build Flexibility Into Plan
Accounting
Accounting
Accounts
Accounts
Payable
Payable
Organizational
Chart
IT
Infrastructure
Infrastructure
Infrastructure
Atlanta
Atlanta
Seattle
Seattle
Northwest
Northwest
Northeast
Northeast
Southeast
Southeast
Charlotte

Charlotte
Information
Information
Technology
Technology
Portland
Portland
Information
Information
Technology
Technology
Accounts
Accounts
Receivable
Receivable
Logistics
Logistics
Purchasing
Purchasing
Human
Human
Resources
Resources
Production
Production
CEO
CEO


Organizations can delegate administrative authority by granting limited

administrative permissions to trusted individuals. Delegation reduces the
workload and responsibility of a single administrator. Delegation also safely
separates administrative authority from other areas of the organization.
Managers who have the appropriate administrative rights can, in turn, delegate
administration of a subset of their accounts and resources to other individuals.
To support delegation of administrative authority, you should design the Active
Directory structure to support the organization’s desired administrative
Information Technology (IT) structure.
Documenting the Administrative Process
Begin by documenting the existing structure of the organization. One strategy is
to divide the administrative tasks into categories and then document the
administrator or administrators responsible for each category.
Once the existing process has been documented, you should work with the
planning team to identify areas for improvement. For example, it may be more
cost-effective to combine several IT teams from different divisions. You may
identify non-IT employees who can assist in the administrative process and
reduce the IT staff workload. This allows the IT staff to focus on the areas
where their expertise is most needed.
Slide Objective
To emphasize the
importance of identifying the
existing administrative
process of an organization.
Lead-in
The Active Directory
structure should support an
organization’s administrative
structure.
Key Points
Make the Active Directory

design support the
administrative structure,
allowing the ability to
delegate administrative
tasks, including permission
to delegate to the lower
layers.
Do not try to map to the
organizational chart.
It’s important to document
the way you want to
administer your network.
Module 3: Designing Active Directory to Delegate Administrative Authority 3


Once the existing and desired processes are identified, use the following as
guidelines for your delegation plan:
!
Determine the level of administration. Decide what each group should
control and at what level in the administrative hierarchy you will delegate
administration. The delegation plan should define what permissions a group
of users may have for that level of the hierarchy.
!
Identify the administrators and the users and resources they administer.
This information will help determine the ownership and permissions
assignment to the OUs you create to support the delegation plan. An
administrator or the object owner must grant users access rights to an object
in Active Directory before users can have access to the object.
!
Build flexibility into your delegation model. You can grant rights to

administrators to manage a small set of users or groups within their area of
responsibility and, at the same time, deny rights to manage accounts in other
parts of the organization. For example, you may want to grant printer
control rights to a small group of users. You may allow certain OU
administrators to have Full Control over specific OUs and objects. You may
restrict other administrators altogether, so that they are not able to view
the OU.

4 Module 3: Designing Active Directory to Delegate Administrative Authority


Characterizing the IT Organization
! Centralized IT
! Centralized IT with Decentralized Management
! Decentralized IT
! Outsourced IT


Before designing the administrative structure of an organization, you must first
characterize your IT organization. The most common IT organizations are:
!
Centralized IT. The centralized IT organization reports to a single
individual, and is usually the group responsible for all network and
information services, although some day-to-day tasks may be delegated to
certain groups or departments.
!
Centralized IT with Decentralized Management. IT organizations often
employ distributed management, where control is spread out across more
than one location. In this model, 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.
!
Decentralized IT. This type of organization allows various business units to
select an appropriate IT model to serve the needs of each individual unit.
This type of organization may 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. Some organizations may choose to outsource all or part of
their IT organization. When only parts of the IT organization are
outsourced, it becomes imperative that a proper delegation model be
implemented. Thus, the internal IT group maintains control of the
organization without compromising the service level agreements the
outsourced company has committed to provide. For example, if an
outsourced company has committed to support the physical infrastructure of
an organization’s network, you may choose to create OUs to contain the
routers, servers, and any other items over which they may need control.

Slide Objective
To illustrate the design of a
location-based hierarchy.
Lead-in
An Active Directory
delegation strategy should
reflect the IT needs of an
organization.
Module 3: Designing Active Directory to Delegate Administrative Authority 5

$
$$
$

Developing a Strategy for Administrative Design
! Designing a Hierarchy Based on Location
! Designing a Hierarchy Based on Organization
! Designing a Hierarchy Based on Function
! Designing a Hybrid Hierarchy by Location then
Organization
! Designing a Hybrid Hierarchy by Organization then
Location
! Design Guidelines


If your Active Directory design is accurately modeled after the needs of an
organization’s administrative IT model, then that design will best support
delegation of administrative authority.
When planning the Active Directory administrative structure, it is important to
accommodate for change and growth in the organization. Organizational
changes should not impact the domain and high level OU structure, for
example.
Slide Objective
To describe how
administrative designs can
be organized.
Lead-in
You may choose from
several strategies for

administrative design.
Key Points
To plan for change and
growth, first identify whether
the IT organization is
centralized or decentralized.
6 Module 3: Designing Active Directory to Delegate Administrative Authority


Designing a Hierarchy Based on Location
! Is Resistant to Change
! Accommodates Mergers and Expansions
! May Compromise Security
! Takes Advantage of Network Strengths
OU
New
England
New
New
England
England
Boston
Boston
Boston
Hartford
Hartford
Hartford
na.nwtraders.msft asia.nwtraders.msft
Domain
nwtraders.msft

If the IT organization is centralized, but network management is geographically
distributed, then organizing the Active Directory structure by location may be
the best strategy. For example, you may decide to create OUs for New England,
Boston and Hartford within the same domain, such as contoso.msft.
Characteristics of Location-based Designs
A location-based OU or domain hierarchy possesses the following
characteristics:
!
Resistant to company reorganizations. While divisions and departments
may change frequently, location rarely does in most organizations.
!
Accommodates Mergers and Expansions. If an organization merges with or
acquires another company, it is simple to add new locations to the OU or
domain hierarchy.
!
Takes Advantage of Network Strengths. Typically, an organization’s
physical network topology will resemble a location-based hierarchy. If you
create domains with this method, you can take advantage of areas where the
network has high bandwidth, and limit the amount of data replicated across
low bandwidth areas.
!
Possible Security Compromises. If a location includes multiple divisions or
departments, an individual or group with administrative authority over that
domain or OU may also have authority over any child domains or OUs.


A location-based OU or domain hierarchy is recommended only if
administrators are present at each location. If administrators from multiple

departments or divisions are in the same location, they may need to cooperate
with each other for certain administrative tasks.

Slide Objective
To illustrate the design of a
location-based hierarchy.
Lead-in
A centralized IT organization
with distributed
management may choose
this strategy.
Key Points
An organization with a
centralized but
geographically distributed IT
function may benefit from
this strategy.

Use this strategy only if
there are administrators at
each location.
Importan
t

Module 3: Designing Active Directory to Delegate Administrative Authority 7


Designing a Hierarchy Based on Organization
! Reflects Business Model
! Is Vulnerable to Reorganizations

! Maintains Departmental Autonomy
! Accommodates Mergers and Expansions
! May Affect Replication
OU
manufacturing
manufacturing
manufacturing
engineering
engineering
engineering
purchasing
purchasing
purchasing
research
research
research
Domain
nwtraders.msft
mfg.nwtraders.msft
distrib.nwtraders.msft


An organization that separates IT administration by department or division may
choose to design Active Directory based on the structure of the organization.
An architect must be very careful to follow the administrative structure, rather
than the organizational chart, when designing an organization-based Active
Directory. The organizational chart may not map to the administrative needs of
an organization. If you design the Active Directory structure to reflect the
organizational chart, it may be difficult to delegate administrative authority,
because the objects in the Active Directory, such as printers and file shares,

may not be grouped in a way that facilitates delegation of administrative
authority. Because users never see the Active Directory structure, the design
should accommodate the administrator’s convenience instead of the users’
convenience.
Slide Objective
To illustrate the design of an
organization-based
hierarchy.
Lead-in
A decentralized IT function
may choose an
organization-based design
of the hierarchy.
Key Points
A decentralized IT function
may benefit from this
strategy. Design the
hierarchy for the
convenience of
administrators rather than
users.
8 Module 3: Designing Active Directory to Delegate Administrative Authority


Characteristics of Organization-based Designs
When deciding whether to organize the Active Directory structure by
organization, consider the following characteristics of organization-based
designs:
!
Reflects Business Model. An organizational structure tends to better reflect

the organization's actual business practices than a structure based on
location. However, users do not see the hierarchical structure.
!
Vulnerable to Reorganizations. Because the reorganization of the corporate
structure can greatly alter the organization-based design, extensive IT
resources may be needed to restructure Active Directory.
!
Maintains Departmental and Divisional Autonomy. An organizational
hierarchy presents few security concerns, because there will likely be no
crossing of departmental or divisional boundaries with this design. When
trying to define the hierarchy design, the security requirements at the
departmental level are an important factor.
!
Accommodates Mergers and Expansions. If an organization merges with or
acquires another organization, additional departments can be easily added to
the organization-based hierarchy.
!
May Impact Replication. Organization-based structures that are used to
create domains may not make efficient use of the network, because the
domain naming context may replicate across one or more low bandwidth
areas.

Module 3: Designing Active Directory to Delegate Administrative Authority 9


Designing a Hierarchy Based on Function
! Is Immune to Reorganizations
! May Require Additional Layers
! May Affect Replication
sales

sales
sales
consultants
consultants
consultants
marketing
marketing
marketing
hardware
hardware
hardware
project1
project1
project1
project2
project2
project2


An organization with decentralized administration may choose to design the
Active Directory structure based on the functions within the organization. A
function-based hierarchy is an ideal choice for small organizations that have job
functions that span several departments. For instance, an organization such as a
consulting agency may have a cross-departmental team that is dedicated to
supporting a particular customer. Such a company could benefit from a
function-based design.
A function-based hierarchy considers only the business functions of the
organization, without regard to geographical location, departmental or
divisional barriers. Choose this approach only if the IT function is not based on
location or organization.

Characteristics of Function-based Designs
When deciding whether to organize the Active Directory structure by function,
consider the following characteristics of function-based designs:
!
Immune to Reorganizations. A function-based hierarchy is not affected by
corporate or organizational reorganizations.
!
May Require Additional Layers. When using this structure, it may be
necessary to create additional layers in the OU hierarchy to accommodate
administration of users, printers, servers, and network shares.
!
May Impact Replication. Organization-based structures that are used to
create domains may not make efficient use of the network, because the
domain naming context may replicate across one or more areas of low
bandwidth.


Function-based hierarchies are only appropriate in small organizations
because functional departments in medium and large organizations are often
very diverse and do not group effectively into broad categories.

Slide Objective
To illustrate the design of a
function-based hierarchy.
Lead-in
Small companies with a
decentralized IT function
that focuses on cross-
departmental teams may
choose a function-based

design.
Key Point
Function-based hierarchies
are suitable for small
companies with cross-
departmental teams.
Delivery Tip
Ask the students to list the
other types of companies
that may benefit from this
model.
Note
10 Module 3: Designing Active Directory to Delegate Administrative Authority


Designing a Hybrid Hierarchy by Location then Organization
!
Allows for Growth
!
Allows for Security Boundaries
!
Leverages Strength of Physical
Network
!
May Require Lower Level
Changes After
a Reorganization
asia.nwtraders.msft
Mfg
Mfg

Mfg
research
research
research
HR
HR
HR
recruiting
recruiting
recruiting
training
training
training


Some organizations combine various strategies to accommodate the most
appropriate administrative structure. Designing a hybrid hierarchy combines
strengths from several areas to meet the needs of the organization.
Designing the higher OUs or domains by location, and the lower OU or domain
levels by organization works well in a highly distributed organization with a
centralized IT function and strong departmental or divisional separation.
Because the highest levels are based on location, this model is less likely to
change, and therefore less likely to require a major effort in the event of a
reorganization.
When designing a hybrid hierarchy by location then organization, consider that
this type of hierarchy has the following characteristics:
!
Allows for additional geographic, departmental, or divisional growth.
!
Allows for distinct security boundaries by department or division.

!
May necessitate a new design of the lower OUs or domains if the IT
function is reorganized.
!
May require administrators to cooperate with each other for some
administrative tasks if they are in the same location but in different divisions
or departments.

Slide Objective
To illustrate the design of a
hybrid hierarchy by location
then organization.
Lead-in
You may need to combine
strategies for the best
design.
Key Point
A highly distributed
organization with centralized
IT function and strong
departmental separation
may implement hierarchies
with location-based upper
levels and organization-
based lower levels.
Module 3: Designing Active Directory to Delegate Administrative Authority 11


Designing a Hybrid Hierarchy by Organization then Location
!

Allows for Security
Boundaries
!
Allows Administration by
Location
!
Vulnerable to Reorganizations
sales.nwtraders.msft
New England
New England
New England
Boston
Boston
Boston
Hartford
Hartford
Hartford


Designing the higher OUs or domains by organization and the lower OUs or
domains by location works well in a large, highly distributed organization that
has physically distributed distinct business units with a need for distinct
security policies in each division. The upper organizational/lower location
hierarchy supports the business organization, while still accommodating
geographic distribution of the IT function.
When deciding whether to choose a hybrid hierarchy by organization then
location, consider that this type of hierarchy has the following characteristics:
!
Allows for strong separation of administrative function between
departments or divisions, while still allowing administrative delegation

based on a physical location.
!
A reorganization will alter the design of the OU or domain hierarchy, which
will in turn require an extensive amount of work for the IT department to
reconstruct it.
!
If this method is used for domain creation, it may not make effective use of
the physical network, because domains will likely be located in multiple
sites.

Regardless of the hybrid hierarchy used, organizations can add additional OUs
to facilitate function-based administration. For example, you can create
additional OUs that divide the users, mail servers, domain controllers, and print
servers into separate containers, if each is managed by a different group of
individuals.
Slide Objective
To illustrate the design of a
hybrid hierarchy by
organization then location.
Lead-in
Another common hybrid
design is by organization
then location.
Key Point
An organization with
physically distributed distinct
business units with a need
for different security policies
in each may implement
hierarchies with

organization-based upper
levels and location-based
lower levels.
12 Module 3: Designing Active Directory to Delegate Administrative Authority


Design Guidelines
! Hierarchy
%
Location
%
Organization
%
Function
! Hybrid Hierarchy
%
By Location then Organization
%
By Organization then Location


The table summarizes various design strategies for hierarchical design and the
characteristics of each. The following flow chart represents a decision tree that
is useful for determining the appropriate hierarchical strategy for an
organization.
Strategy Characteristics

By Location Resistant to company reorganizations.
Accommodates mergers and expansions.
Takes advantage of network strengths.

Requires administrators at each location.
Compromises on some security issues.
By Organization Reflects the business model.
Maintains departmental or divisional
autonomy.
Accommodates mergers and expansions.
May impact replication.
Vulnerable to reorganization.
By Function Used with small organizations only.
Immune to reorganizations.
May require additional layers.
May impact replication.

Slide Objective
To identify the hierarchy
design that can be used for
a given scenario.
Lead-in
The type of hierarchy that
you chose for an
organization depends on the
context in which it is used.
The summary below is
intended as a guide only.
Module 3: Designing Active Directory to Delegate Administrative Authority 13


(continued)
Strategy Characteristics

By Location then Organization Allows for additional geographic or
departmental growth.
Allows for distinct security boundaries.
Requires a new design if the IT
organization were to become
decentralized.
Requires cooperation among IT
administrators if they are in the same
location but in different departments or
divisions.
By Organization then Location Allows for strong security between
departments or divisions, while still
allowing administrative delegation based
on a physical location.
Vulnerable to reorganization.

14 Module 3: Designing Active Directory to Delegate Administrative Authority


Centralized IT
function?
Distributed
administration?
Geographically
distributed?
Departmental
or divisional
separation?
Location then
organization

Location Organization
Single central
group
Departmental
or divisional
separation?
Geographically
distributed?
Organization then
Location
Organization
Cross-
departmental
teams?
Function
Single central
group
Yes No
Yes No
Yes No
Yes
No Yes
No
Yes No
Yes No
Yes No
Departmental
or divisional
separation?

Module 3: Designing Active Directory to Delegate Administrative Authority 15


$
$$
$

Developing a Strategy for Delegation
! Determining Delegation Methods
! Determining Object Ownership
! Creating a Strategy for Object-Based and Task-Based
Delegation
! Creating a Strategy for Delegating Authority
! Creating Strategies for Inheritance of Permissions
! Design Choice Guidelines
! Demonstration: Using Visio 2000


Delegation of administration is the process of decentralizing the responsibility
for container ownership and administration from a central administrator to other
people or groups within the organization. You can use several methods to
delegate authority, and assign to users and groups different categories of
ownership. The ability to establish separate access to sites, domains, and OUs is
an important security feature in Active Directory.
Use the following to identify the important factors to consider when planning
administrative delegation:
!

Determining methods used for delegating authority.
!
Examining object ownership.
!
Creating strategies for object-based and task-based ownership.
!
Creating strategies for delegating authority at different administrative levels.
!
Creating strategies for planning inheritance of permissions.
!
Documenting the delegation plan.
!
Examining guidelines for designing delegation of authority.

Slide Objective
To identify the important
factors when planning
administrative delegation.
Lead-in
There are several strategies
you can use to delegate
administrative authority.
16 Module 3: Designing Active Directory to Delegate Administrative Authority


Determining Delegation Methods
! Delegating Authority Includes:
%
Changing Container Properties
%

Creating, Changing, and Deleting Child Objects
%
Updating Object Attributes
%
Creating New Users or Groups
%
Managing Small Groups of Users or Groups


When you are planning to delegate administration, you should decide what
permissions you want to assign to various users in your organization. You may
apply permissions to an object, a branch of the Active Directory tree, a
particular object type, or an attribute. The following are types of permissions
you may want users to have:
!
Change container properties. Designated users will be able to change
properties on a particular container, such as the GPOs set on an OU.
!
Create, change, and delete child objects. Designated users will be able to
create, change, and delete child objects of a specific type within a container,
such as users, groups, or printers.
!
Update object attributes in a certain class. Designated users will be able to
update specific attributes on child objects of a specific class within a
container, for example, the right to set passwords on user objects.
!
Create new users or groups. Designated users will be able to create new
users or groups within the container.
!
Manage a small group of users or groups within a given area of

responsibility. Designated users will be able to manage a small set of users
or groups within their area of responsibility, such as a container in the
Active Directory structure. For example, a user can be given the ability to
manage printer queues and file resources within a particular OU or among
several OUs.

Slide Objective
To describe the methods
that can be used to delegate
users in an organization.
Lead-in
After determining access
type, choose the appropriate
delegation method to match
the access type.
Key Points
You can apply permissions
to objects in many ways.
Module 3: Designing Active Directory to Delegate Administrative Authority 17


Determining Object Ownership
1. Creator Grants Permission
to User to Take Ownership
1. Creator Grants Permission
1. Creator Grants Permission
to User to Take Ownership
to User to Take Ownership
Creator
Creator

User Account
User Account
2. User Takes
Ownership
2. User Takes
2. User Takes
Ownership
Ownership
3. New Owner
3. New Owner
3. New Owner


Every object in Active Directory has an owner. The person who creates the
object automatically becomes the owner and, by default, has Full Control over
the object. When assigning permission to create objects, remember that the
owner of an object controls how permissions are set for an object and to whom
permissions are assigned, even if the owner is not listed in the discretionary
access control list (DACL).
Owners can assign the Take Ownership permission to any user or group
account. When creating a plan to delegate administrative authority, remember
that a user or group account with this permission can take ownership of the
object, and will retain ownership until the permission is removed.

Members of the Domain Admins group always have the ability to take
ownership of any object in the domain and then change the permissions. This is
one reason to limit the number of users in the Domain Admins group. If a
member of the Administrators group creates an object or takes ownership of an
object, the Administrators group becomes the object’s owner. For tracking
purposes, the name of the specific Administrators group member who created

the object or took ownership is also listed as owner.

Slide Objective
To illustrate the concept of
object ownership.
Lead-in
Every object in Active
Directory has an owner. The
creator of an object is the
object’s owner.
Key Points
Object owners have Full
Control over the object by
default.

Object ownership can be
taken by administrators or
users who have Take
Ownership permission.
Delivery Tip
Emphasize to students that
unlike Windows NT 4.0,
when an administrator takes
ownership, that person is
distinctly listed as the
owner, in addition to the
Administrators group.
Note
18 Module 3: Designing Active Directory to Delegate Administrative Authority

Creating a Strategy for Object-Based and Task-Based Delegation
OUAdmins
Full Control
Entire OU
Entire OU
OUAdmins
Reset password
Object-Based Task-Based
Users Only


Administrative delegation can be based on objects, such as sites, domains, and
organizational units, or on tasks. An example of a task is “change all passwords
for all user objects in this organizational unit.” Determining whether the object-
based or task-based delegation is best depends on the administrative model used
in the organization.
In general, 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. Consider
placing objects in separate OUs based on how they will be managed. This
allows for inheritance, easier documentation, and better troubleshooting.
Slide Objective
To emphasize the
granularity of delegation
levels.
Lead-in
You can apply permissions
to an entire object, or to
portions of that object.

Key Points
Object-based delegation
applies to all objects and
properties. Task-based
delegation can apply to only
certain types of objects or
their attributes.
Try to group similarly
managed objects in one
container, because it is
easier to apply permissions
to the entire object.
Module 3: Designing Active Directory to Delegate Administrative Authority 19


Creating a Strategy for Delegating Authority
Domain-Level Delegation
Affects All Objects
in the Domain
OU-Level Delegation
Can Affect Parent
OU Only, or Parent
and All Child OUs
Site-Level
Delegation May
Affect Multiple
Domains


The goal of delegating the ability to grant permissions wherever possible is to

conserve administrative effort and cost, thus reducing the total cost of
ownership (TCO). Assigning permissions to users in an organization involves
deciding who can and cannot gain access to an object and its contents, and the
type of access that a person may or may not have.
The following methods can be used to assign permissions to users in an
organization:
!
Delegating the ability to assign access control permissions for objects to
users or groups of users; in other words, delegating the ability to delegate.
!
Controlling which users can gain access to individual objects or object
attributes, and the type of access these users have.
!
Assigning common or special permissions on objects.
!
Using inheritance to allow access control permissions to flow to
child objects.


The object type defines the available permissions and varies from one
object type to another.

When deciding whether to delegate authority at the site, domain, or
organizational unit level, remember the following points:
!
Authority delegated at the site level will likely span domains, or conversely
may not include targets within the domain.
!
Authority delegated at the domain level will affect all objects in the domain.
!

Authority delegated at the organizational unit level can affect that object and
all of its child objects, or just the object itself.

Slide Objective
To illustrate the various
levels at which authority can
be delegated.
Lead-in
Delegating authority at
appropriate levels in an
organization can help
minimize administrative
overhead.
Note