Lesson 2 - Designing an Active Directory Hierarchy

ITMT 2456 70-647

Design Active Directory forests and domains.
Designing core identity and access management components
2.1
Design the Active Directory administrative model.
Designing core identity and access management components
2.3

Creating a Forest and Domain Design
Creating Active Directory Domain Services (AD DS) objects, such as forests
and domains, is easy. Windows Server 2008 R2 provides wizards that walk you
through the process in a few simple steps.
Every AD DS infrastructure starts with a single forest containing a single domain,
Designing an AD DS hierarchy is a high-level process that is concerned with
business and management issues as much as it is with technical ones.

Using Microsoft Operations Framework
Depending on the size and nature of the organization, designing an Active Directory hierarchy
can be an extremely large and complex project.
To organize and define projects of this type, Microsoft has created a collection of documents
called the Microsoft Operations Framework (MOF).
o Plan
o Deliver
o Operate

Gathering Information
Before you can actually begin to design the forest and domain structure for your enterprise
network, you must assemble a body if information about the organization that AD DS will
service and about the infrastructure on which you will build.

Ascertaining the Role of AD DS
Arguably the most important question you have to answer is what role the AD DS database will
play in your organization. More specifically, what kind of information will be stored in the AD
DS database?





AD DS Schema
The default AD DS schema defines a variety of
informational attributes for user objects







Diagramming the Current Infrastructure
Before you can begin designing your forests and domain, you must collect the following
information:
o Organizational infrastructure
o Geographical infrastructure
o Network infrastructure

Determining Business Requirements
As a business decision, implementing or extending an Active Directory infrastructure must
yield some palpable benefits to the organization benefits beyond the satisfaction and
convenience of the IT staff:
o Functional requirements
o Legal stipulations
o Service level agreements
o Security requirements
o Project constraints

Designing a Forest Structure
Active Directory forests are designed to keep things separated, things like directory information
and administrative permissions.
Within a single forest, the default behavior is to share information unless an administrator
expressly prohibits that sharing.

Shared Forest Elements
A single forest shares each of the following elements:
o Global catalog
o Configuration directory partition
o Trust relationships
o Schema
o Trustworthy administrators

Multiple Forests
As a general rule of Active Directory design, enterprise administrators should stick to one
forest, unless they have an explicit reason to create more.
Some of the most common reasons are:
o Perimeter Networks
o Incompatible Schema
o Trust Relationships
o Information Protection
o Administrative Isolation

Choosing a Forest Model
Once you have decided to create multiple forests, there are several models you can use to
separate the enterprise resources:
o Organizational Forest Model
o Resource Forest Model
o Restricted Access Forest Model




Organization Forest Model


Resource Forest Model


Restricted Access Forest Model








Designing a Domain Structure
Once you have determined how many forests you will create in your enterprise, the next step
is to move down one level in the AD DS hierarchy and populate each forest with one or more
domains.
The most common reasons for creating more than one domain in a forest are as follows:
o Security
o Administration
o Namespaces
o Replication
Enterprise administrators should consider also some of the disadvantages of creating multiple
domains, including the following:
o Group Policy
o Moving objects
o Domain controllers
o Administration policies
o Access control
o Global catalog

Forest Root Domain
When you create a new forest and assign it a name, that becomes the name of the first
domain in the forest, called the forest root domain.
The forest root domain performs critical forest-level functions that make it vital to the operation
of the other domains in the forest:
o Forest-level administration groups
o Forest-level operations masters
o Inter-domain authentication and authorization

Forest with Dedicated Root Domain

There are a number of benefits to creating a dedicated root domain, including the following:
o Forest-level group security
o Simplified replication
o Easy backup




Domain Hierarchy
The most common models that enterprise administrators use to create multiple domains are as
follows:
o Geographical divisions
o Business unit divisions
o Account and resource divisions

Forest with Multiple Domain Trees


Trusts Relationships
By default, every parent domain in a tree has a trust relationship with its child domains.
In addition, the root domain of every tree has a trust relationship with the root domains of the
other trees.



Shortcut Trusts
Administrators can create shortcut trusts between domains at the lower levels of the trees.


Function Levels
Functional levels are essentially a version control mechanism for Active Directory forests and
domains.
When you select a functional level for a domain or a forest, you activate features that Microsoft
introduced in successive version of Windows Server

Forest Functional Level Features







Domain Functional Levels Features


Set Forest Functional Level Page
Active Directory Domain Services














Active Directory Domains and Trusts Console


Evaluating Schema Modifications
When faced with the prospect of a schema modification, the first question to consider is
whether the application requiring the changes is worth deploying.
Schema modifications are one-way processes, and permanent.
Once you have modified the AD DS schema, you cannot reverse the modifications, except by
restoring the entire schema from a backup.

Designing an Active Directory Administrative Model
By creating an administrative model, enterprise administrators decide who will be responsible
for the various tasks involved in creating and maintaining the Active Directory infrastructure.
By delegating these tasks, enterprise administrators pass certain elements of their
responsibility down to their subordinates.
This increases the efficiency of the administrative effort while reducing the overall cost.

Administrative Tasks


Administrative Delegation Models
Administrative delegation is often based on geographic or business unit divisions.
However, it is also possible to create a task-based distribution of labor.
Microsoft defines three types of administrative model
o Centralized
o Distributed
o Mixed
Delegating Administrative Tasks
There are two basic elements that individuals need to be able to delegate:
o Active Directory permissions
o User rights.

Active Directory Permissions


Delegation of Control Wizard

User Rights

Creating an Organization Structure
Based on geographical divisions - Based on business unit divisions and then geographical
divisions



Creating a Group Strategy
Windows three-step policy for creating groups, which is as follows:
1. Create domain local groups and grant them access to resources.
2. Create global groups and add users (or other global groups) to them.
3. Add the global groups as members of the domain local groups.

Built-in Domain Local Groups
Active Directory Management Roles

Auditing Administrator Compliance
The best way to monitor Active Directory administrative procedures is to use auditing, which
records the success and/or failure of specific activities in the Windows Security event log.
However, auditing is a Windows feature that you must configure carefully, as it is capable of
recording vast amounts of information.
o Too much information can be as bad as no information at all.
To audit AD DS activity, you must enable the Audit directory service access policy in the
Default Domain Controllers Policy GPO. You can elect to audit only successful accesses, only
failed accesses, or both.

Auditing Tab of an AD DS Object

Advanced Audit Policy Configuration Settings
You Learned
A competent enterprise administrator is an individual who, when designing an Active Directory
hierarchy, adds domains and forests only when the organizations requirements call for them.
A competent enterprise administrator is an individual who, when designing an Active Directory
hierarchy, adds domains and forests only when the organizations requirements call for them.
Designing an AD DS hierarchy is a high-level process that is concerned with business and
management issues as much as it is with technical ones.
The enterprise administrator must know what Active Directory can do and also what the
organization needs it to do.
The design process is a matter of finding a common ground between those AD DS capabilities
and the organizations requirements.
The most important question you have to answer is what role the AD DS database will play in
your organization. More specifically, what kind of information will be stored in the AD DS
database?
The first question in Active Directory design is whether to use one forest or multiple forests.
The default configuration is to have one domain per forest; you should only create multiple
domains if you have specific reasons for doing so.
The main issues for the enterprise administrator regarding schema are not how to make the
changes but what changes to make and whether it is worthwhile to make them.
It is the enterprise administrators job to create a model for the delegation of tasks like these to
other administrators, technicians, and trustworthy users, all over the enterprise.
There are two basic elements that individuals need to be able to perform AD DS service
management and data management tasks: Active Directory permissions and user rights.
One of the most common reasons for creating OUs is to delegate administrative control over
them.
OUs are the means by which you can delegate low-level tasks on a departmental basis, or
give administrators autonomy over a relatively small part of the AD DS hierarchy.
With a hierarchy of organizational units in place, you must create a group strategy before you
can use the OUs to delegate control and assign user rights.