Active Directory (AD)

Made by :
Guerbi Mohamed Lakhdar & Saidi Mohamed

1
 TABLE OF CONTENTS
Executive Summary ........................................................................................................... 1
1. Introduction............................................................................................................ 1
Part I: Active Directory Overview ..................................................................................... 3
2. Active Directory Tutorial ....................................................................................... 3
1. Directory Services ........................................................................................................ 3
2. Microsoft Active Directory.......................................................................................... 4
3. Components of the Active Directory .......................................................................... 4
1. Domain ................................................................................................................................... 4
2. Trees ....................................................................................................................................... 5
3. Forest ...................................................................................................................................... 6
4. Organizational Units............................................................................................................... 7
5. Schema ................................................................................................................................... 7
6. Group Policy Objects.............................................................................................................. 8
7. Global Catalog ...................................................................................................................... 10
2.4 Naming Contexts, Partitioning, and Replication .................................................... 11
2.5 Kerberos Trusts.......................................................................................................... 12
2.6 Delegation of Authority ............................................................................................. 13
3.0 Microsoft’s Active Directory Design Process...................................................... 15
3.1 Forest Plan.................................................................................................................. 17
1. Forest Planning Process........................................................................................................ 17
2. Determining the Number of Forests ..................................................................................... 17
3. Forest Change Control Policy............................................................................................... 18
4. Changing the Forest Plan after Deployment......................................................................... 19
2. Domain Plan ............................................................................................................... 19
1. Domain Planning Process ..................................................................................................... 19
2. Determining the Number of Domains in each Forest ........................................................... 20
3. Choose a Forest Root Domain .............................................................................................. 20
4. Assign a DNS name to each domain to create a domain hierarchy ...................................... 20
5. Plan the DNS Server Deployment ........................................................................................ 21
1. Background ................................................................................................................. 21
3. Organizational Unit Plan........................................................................................... 22
4. Site Planning Process................................................................................................. 25
4. Scope of AD Design ............................................................................................. 27
Part II: Active Directory Design Scenario...................................................................... 29
5. Description of Hypothetical Site.......................................................................... 29
1. Pragmatic Discussion of Forest and Domain Planning........................................... 29
2. LCIS Design Requirements....................................................................................... 31
1. Programmatic Requirements ................................................................................................ 31

ii
1. Comparison of Three Design Approaches.......................................................... 32
2. Single Domain............................................................................................................. 33
1. Single Domain Design Description ...................................................................................... 33
2. Single Domain Benefits ........................................................................................................ 34
3. Single Domain Draw Backs.................................................................................................. 34
4. Single Domain User Perspectives......................................................................................... 35
5. Single Domain Concluding Remarks ................................................................................... 35
3. Multiple Domain Model............................................................................................. 36
1. Multiple Domain Description ............................................................................................... 37
2. Multiple Domain Benefits .................................................................................................... 38
3. Multiple Domain Draw Backs .............................................................................................. 38
4. Multiple Domain User Perspective....................................................................................... 39
5. Multiple Domain Concluding Remarks ................................................................................ 39
4. Multiple Forests.......................................................................................................... 40
1. Multiple Forest Description .................................................................................................. 41
2. Multiple Forest Benefits ....................................................................................................... 42
3. Multiple Forest Drawbacks................................................................................................... 42
4. Multiple Forest User Perspectives ........................................................................................ 43
5. Multiple Forest Concluding Remarks................................................................................... 43
5. LCIS’ Active Directory Design................................................................................. 44
Part III: Active Directory Best Practices ........................................................................ 46
7.0 Best Practices for Active Directory Design ......................................................... 46
Appendix A. DNS Options.............................................................................................. 48
Appendix B. Bibliography............................................................................................... 55

iii
Part I: Active Directory Overview

1. Active Directory Tutorial

Unfortunately, many aspects of AD are technically complex and most of the terms used
to describe this suite of technologies are new. As a result, this tutorial is complicated but
necessary to comprehend the design process.

1. Directory Services

What is a directory in computing terms? A classic analogy is the white and yellow pages
of a telephone book. A common feature of both white and yellow pages is the ability to
search for information; the difference in the two is the way they are indexed.

Publishing information in a directory and allowing users, applications, and systems

administrators to make use of this information is the fundamental advantage of a
Directory.

Directories, such as Lightweight Directory Access Protocol (LDAP) and Active

Directory (AD) are types of databases that can be searched to provide useful network
information. A user can find network information without any knowledge of the
structure of the network. For example, the user can search the Active Directory for a
share, requiring no knowledge of the network. This is because the directory has
abstracted a server’s share to a directory share. Without Directory Services, a user has to
know the server name and its share name to mount a network file share. AD changes this.

Searching is a fundamental service provided by LDAP, so the more information

“published” in the directory, the more productive the user community becomes. LDAP
is a standard and the Active Directory is LDAP compliant. Since AD adheres to the
LDAP standard, third party applications are leveraging the directory. AD-aware
applications can use Windows 2000 services for authentication and access controls.
These applications can store configuration information in the directory.

For example, consider Microsoft’s firewall Internet Security and Acceleration Server
(ISA) as an LDAP aware application. When ISA is used as an Intranet Proxy and cache
server, the security policy for each proxy server is published in the Active Directory.
Picture an enterprise with 10 internal firewalls protecting internal web based applications.
Since the policy is located in the directory, the security organization can enforce common
rules on each and every firewall. The directory makes complicated policies possible such
as applying a baseline firewall policy for all servers, then a more restrictive policy for
specific servers.

System managers can gain the most benefit from directory services. Currently, NT and
UNIX models for system management are comprised of discrete tools for each type of
management operation. Each tool has its own configuration data storage (files, databases)

3
and the configuration information is scattered throughout the system. Also, there is a
steep learning curve for the systems managers to learn nuances of each management
utility.

Active Directory, on the other hand, stores all of the domain information in a common
and searchable format. All the user accounts, computer accounts, group accounts, access
control lists, security identifiers, Group Policy Objects (GPOs), shares, printers,
properties about people and their locations, are all stored in the Active Directory.
Moreover, a common interface and management paradigm, Microsoft Management
Console, is provided to the administrator for each of the administrative tasks and
functions.

2. Microsoft Active Directory

Active Directory is Microsoft’s implementation of directory services. It is based on

various standards, most importantly LDAP and X.500 (the schema is based on X.500).

In addition to compliance with LDAP, AD has additional features and compatibility such
as the close integration of the directory services to Windows domains and Domain Name
Service (DNS). The integration of directory services to Windows domains is the key to
directory scalability (domains and scalability will be described below). AD security,
authentication, and access control are also provided by the integration of the domains to
the directory. While this approach works well, the integration of AD to Windows
domains forces the choice of Active Directory services when selecting the Windows 2000
operating system.

The integration of DNS to Windows domains is a feature that makes the design and
implementation of Active Directory both complicated and invasive to the existing
infrastructure. Importantly, A Windows domain must be named identically to its DNS
domain. The same DNS name is used for both the IP address resolution and the Active
Directory domain name.

3. Components of the Active Directory

1. Domain
The core unit of logical structure in the Active Directory is the domain, which can store
millions of objects. Objects stored in the domain are considered “Interesting” to the
network. “Interesting” objects are items the networking community members need to do
their jobs: printers, documents, e-mail addresses, databases, users, and other resources.
All network objects exist within a domain and each domain stores information only about
objects it contains. Active Directory is made up of one or more domains.

Grouping objects into one or more domains will allow the network to reflect a DOE site’s
organization. Domains will allow each internal division to partition their information
from the rest of the organization.

4
Domains share these characteristics:

• All network objects exist within a domain and each domain stores information
only about the objects that it contains.
• A domain is a security boundary. Assess control lists (ACLs) control access to
domain objects. All security policies and settings such as administrative rights,
security policies, and ACLs do not cross from one domain to another.
• The Domain Administrator has absolute rights to set policies only within that
domain.

The atomic unit of the Windows 2000 is the domain. A domain is an administrative
boundary, a security boundary, and represents a name space that corresponds to a DNS
domain.

The first domain created in a Windows 2000 deployment is called the root domain. Since
Windows 2000 domain structure is married to DNS domain hierarchies, the
structure of the domain hierarchies are similar.

Most organizations large enough to require more than one domain have a logical
structure that divides responsibilities or work focus. Domains are ideal for logical
partitioning.

Windows 2000 network domains are organized in a hierarchy. The concepts of forests
and trees were introduced to leverage the hierarchical approach to domains.

An important note: in the domain hierarchical structure, user rights and group policy are
inherited throughout the OU hierarchy.

2.3.2 Trees
Domain trees are collections of Windows 2000 domains that form a contiguous name
space. A domain tree is formed as soon as a child domain is created and associated with a
given root domain. A domain tree looks like an inverted tree (with the root on top), with
branches (child domains) sprouting out below.

Trees are the structural elements that ensure the scalability of the Active Directory. As
each domain is a partition (part of the entire directory), trees allow the hierarchical
structure necessary for organizations, much like DNS domain structure does for the
Internet. Domains within a tree must be named identically to their DNS domain
names.

The diagram below shows a hierarchical tree; the domain names are the same as the DNS
domain names (note: the domain names are hypothetical examples only).

5
 doesite.gov

A-Div.doesite.gov B-Div.doesite.gov

Active Directory Domain names are

the same as the DNS domain names

3. Forest
There are cases where two or more domain trees, each represented by separate DNS
name space, need to be included as one enterprise. A tree must be represented by a
contiguous DNS name space and disallow participation of domains that are not within its
name space. The mechanism for connecting one or more trees is the Forest.

All trees within a forest share the following benefits:

• Common Schema
• Common Configuration (AD infrastructure information)
• Global Catalog
• Each and every domain within the forest can leverage the Kerberos transitive trust
mechanism

(Note: An Active Directory consisting of only one tree with a single domain is considered
a forest. A non-contiguously named single domain is still considered a tree).

Consider the diagram of a forest below. This forest consists of two trees. The w2k.local
DNS domain (which is a private unregistered DNS domain), and the doesite.gov DNS
domain are non contiguous and therefore are separate trees. The w2k.local domain is the
root of its tree and the doesite.gov domain is the root of its tree. Since w2k.local was the
first domain created in the forest, it is also the root of the forest.

w2k.local doesite.gov

x.w2k.local y.w2k.local x.doesite.gov y.doesite.gov

A Forest with 2 Trees

6
4. Organizational Units
The Organizational Unit (OU) is a critical design factor impacting security, policy,
efficiency, and the cost of administration. Organizational Units are a type of LDAP
(X.500) container. It can be thought of as a sub-domain element with similar properties to
domains. They are components internal to domains. OUs are part of the LDAP name
space and not the DNS name space.

OUs can be arranged in a hierarchical structure. Unlike the domain hierarchical

structure, user rights and group policy are inherited throughout the OU hierarchy.

One of the main benefits of OUs is their ability to accomplish domain functions and
therefore reduce the total number of required domains. In fact, a common NT to
Windows 2000 migration strategy is to upgrade the NT domain master domain to a
Windows 2000 AD, then collapse all of the NT resource domains into Organizational
Units.

OUs are commonly used to contain user accounts, group accounts, and computer
accounts. Powerful configurations can be obtained when the OU design is harmonized
with group policy and security groups.

Another benefit of Organizational Units is the concept of delegation of authority. Domain

Administrators can delegate partial administration rights through the OU. The granularity
of the delegated rights is quite fine. Take the case of a help desk as an example. The
domain administrator can delegate the “right” to reset passwords to help desk personnel
and therefore, offload the domain administrator’s responsibility of fielding calls
pertaining to lost or expired passwords. The change-the-password right is usually
enforced by a Group Policy Object (GPO), filtered by security groups, and applied at the
OU level.

Architecturally, the design of the OU structure usually reflects the Information

Technology structure. To paraphrase many authors on this subject, “design the OU
structure with the administrators in mind.”

5. Schema
The schema dictates the data definitions for the AD. If an object or attribute is not in the
schema, that object/attribute will not be stored in the AD.

The directory contains information in the form of objects and object attributes. The
directory is actually a type of database that is optimized for querying. Data that is more or
less static and is searched often can be beneficially stored in the directory. Data that
changes often is not a good choice for storage in the directory. For example, user
properties such as phone number, building number, pager number, and application
configuration data are examples of information that can be effectively managed by
directory services, as these types of data are fairly static. These types of data are queried
much more often than they are changed. System logs and file systems are not good
candidates for the directory as these data are extremely dynamic.

7
The schema manager, an administrative utility, defines what attributes are published in
the Global Catalog (GC), see below. A very important aspect of the AD design is
choosing the information to be published in the GC. The schema manager allows this
definition.

2.3.6 Group Policy Objects

Group Policy Objects are especially critical to the justification for additional domains.
Group Policy is the primary component of Windows 2000’s implementation of Change
and Configuration Management (CCM), and is the primary mechanism for establishing
uniform, effective security policies within a Windows 2000 domain.

As the name implies, Change and Configuration Management involves managing the
ongoing change and configuration issues that arise as administrators try to ensure that
people are productive as they use their computers. This ability, once the associated GPOs
are designed correctly, is central to reducing the Total Cost of Ownership of a Windows
network.

The table below highlights CCM.

Feature Benefits Technologies

User Data “My data and documents follow me!” • Active Directory™
Management Users can access the data that they • Group Policy
need to do their job, whether they are • Offline Folders
working online or offline, or when • Synchronization
roaming from one computer to Manager
another on the network. • Enhancements to
Administrators centrally manage this the Windows Shell
feature by policy to minimize support • Disk Quotas
costs.
Software “My software follows me!” • Active Directory™
Installation Users have the software they need to • Group Policy
and perform their job. Software is self- • Windows Installer
Maintenance repairing, and both the software and Service
features install ‘just-in-time.’ • Add/Remove
Administrators centrally manage this Programs in
feature by policy to minimize support Control Panel
costs. • Enhancements to
the Windows Shell

8
 User Settings “My preferences follow me!” • Active Directory™
Management Users get the same experience from • Group Policy
any desktop. Personal preferences • Offline Folders
and settings for desktops or software • Roaming User
are available whenever the user logs Profiles
on. • Enhancements to
Administrators centrally manage this the Windows Shell
feature by policy to minimize support
costs.
Remote OS Administrators can enable installation • Active Directory
Installation and configuration of the Windows • Dynamic Host
2000 operating system on new or Configuration
replacement computers without Protocol
staging or on-site technical support. • Remote Installation
Server

Change and Configuration Management is the realization of the original goals of

Microsoft’s Zero Administration for Windows (ZAW) initiative that Microsoft
announced in October 1996. The main goals are bulleted below.

Automatic system update and application installation

The operating system will update itself when the computer is booted, without user
intervention, seeking the latest necessary code drivers from a server. The automatic
desktop feature will provide users with all available applications, installing them
automatically when invoked.

• All state kept on servers

User’s data can be automatically “reflected” to servers, ensuring high availability and
allowing mobile users to have access to their information whether they are connected
to a network or not. Additionally, users will be able to roam between PCs while
maintaining full access to their data, applications, and customized environments.

• Central administration and system lockdown

All aspects of client systems will be controllable by a central administrator across the
network. In a few simple steps, the system can be “locked down” to maintain
controlled, consistent, and secure configurations across sets of users.

The goals of ZAW are very aggressive; in fact these goals did not seem achievable in
1996. GPO, along with a few other technologies, has met these goals.

The benefits of a good GPO design are great. Consider the current requirements of fixing
vulnerabilities as reported by the scanning project. Currently, a system manager has to
visit each computer and perform a registry fix. Using Group Policies and the Active
Directory, an administrator fixes the policy once, in the Group Policy Object; the AD will
then push the fix to every computer on the domain.

9
Another case is a hot fix (patch). The hot fix can be pushed out to every computer in the
domain via GPO.

Security policies can be pushed out to every computer and user account within the
domain; these policies are not only enforced, they are also refreshed at a settable interval.

All of the benefits of Group Policy Objects come at a cost. Designing a GPO strategy and
applying GPO is one of the most complicated aspects of Windows 2000 and the Active
Directory. There are over 700 settings that are configurable with GPO, but the vast
number of settings is not the most complex aspect. The architecture and implementations
are more complicated.

There are some other key technologies that are also implemented via GPOs that were not
covered in this introduction. These technologies may be the key to implementing controls
for critical computer systems. The GPOs associated with these technologies are
Domain concepts.

• Encrypted File System

• IP Security (IPSec: Secure extensions to the TCP/IP protocol stack)
• PKI (Certificate Authority and services)
• SMB Signing (protection for Microsoft file shares)

Utilization of the above technologies can be justification for new programmatic domains.

10
2.4 Naming Contexts, Partitioning, and Replication

The Active Directory contains all the network information for the forest. As described
above, each domain is a separate partition of the directory and is also considered a
separate name context.

Domain A

B
A C

Domain B Domain C

Each Domain contains a Partition The "Directory" is the

of LDAP objects sum of the partitions

This partitioning ensures that the directory will scale. Although a single domain can
contain millions of objects, there are various cases for adding a domain to the forest.
Adding a new domain has a minimal effect on the other domain’s contents. The new
domain is another partition containing its own information (objects).

The Active Directory is partitioned into three naming contexts: Domain Naming
Context, Configuration Naming Context, and Schema Naming Context. A domain is its
own naming context and its scope is localized to its domain members. There are two
other naming contexts whose scopes are forest-wide:

1. The schema, which contains the object data definitions, is a separate name
context and is replicated to every domain controller in the forest.
2. The configuration is also a separate naming context that is also replicated to
every domain controller in the forest. The configuration has structural
information, such as the location of sites (see below), the location of domain
controllers, subnets, global catalog servers, and a complete list of all the domains
in the forest. The configuration also has information for each domain that is not in
the forest and has a trust relationship with any domain in the forest.

Each name context must be replicated through its scope. The Domain Naming Context is
replicated to all the domain controllers within the domain. The Schema and
Configuration Contexts are replicated to every domain controller in the forest.

Replication is another major aspect of designing an AD. (Replication design is outside

the scope of this paper).

11
3.0 Microsoft’s Active Directory Design Process

Active Directory design is an enormous task. Many organizations are late deploying AD
due the design complexity. Recognizing the complexity of this task, Microsoft has
provided an Active Directory planning process in the form of an Active Directory
Deployment and Planning Guide (see bibliography). Section 5 (Microsoft’s Design
Process) will explain this process.

The scope of an Active Design can be an entire enterprise and this effort will require a
design team with members from many and various organizations. Generally, the design
processes that were used to design NT4 domains will not work for AD design.

There are many design methodologies for AD or LDAP design. Some of these design
methodologies used by Corporate America are very formal and very rigorous. It is not the
intent of this paper to cover or develop a formal methodology for AD design; the scope of
this paper is merely to provide a road map for developing and tracking such a process.

Microsoft’s Deployment and Planning Guide, which is part of the Windows 2000 Server
Resource Kit, is an excellent starting point for a successful design. This section is a
synopsis of Chapter 9: “Designing the Active Directory Structure,” (note: a manager
responsible for an Active Directory Design effort should master all the concepts in the
Deployment Planning Guide).

The diagram below depicts the Microsoft design process.

15
 START
Create a Create OU Create a site
Create a domain plan plan for each topology plan for
Forest Plan for each domain each forest
forest

Determine the Determine Create OU to Define

number of the number delegate sites and
forests of domains administration
site links

Create a Choose a
change control forest root Create OUs to
policy for each domain hide objects Place servers
forest into sites
Assign a DNS
name to each Create OUs for
domain Group Policy

Plan DNS
server
deployment
END
Optimize
authentication
with shortcut
trusts

Forest Plan Domain Plan OU Plan Site Plan

This paper focuses on the first 7 steps of the design process, the permanent aspects of the
design. These are the most important because incorrectly designing and implementing
them will result in an unusable architecture, requiring a complete wipe of services, and
starting over. A fundamental architectural approach for Active Directory design is to
push the design complexity to the lower level aspects of the architecture down to the
Organizational Units, (see Best Practice #1 in Part III).

The design aspects of OUs require complete knowledge of the mission, personnel, and
operational procedures of the department or project represented by the OU. The
parameters of the OU can be subject to rapid changes such as personnel moves, new
projects, new compliance requirements, to name a few. The justification for pushing
complexity down to the OUs is that the AD technologies will accommodate changes at
the OU level simply by a drag-and-drop procedure.

Changes to the Domain structure or the Forest structure, however, are much more
difficult to accomplish, as Microsoft has yet to provide grafting and pruning tools for
their directory and also, any changes to domains and/or forests will require corresponding
changes to the DNS infrastructure. Therefore, any design mistakes early in the design
process will be difficult to rectify after deployment.

Collectivity the first seven steps shown in the diagram above (white rectangles) will
produce a Domain Name space design. The concept of Domain Name space actually
fuses the Forest and Domain Plans with DNS design.

The Microsoft planning methodology results in four planning documents as shown at the
bottom of each column in the diagram above. These documents are the:

16
 • Forest Plan
• Domain Plan
• Organizational Unit Plan
• Site Plan

The following sections will describe each plan. The Forest and Domain Plans are
explained in much more detail than the OU and Site Plans, as mistakes made in the forest
and domain designs are harder to recover from, as explained above.

1. Forest Plan

A forest is a collection of Active Directory domains. Forests serve two main purposes: to
simplify user interaction with the directory, and to simplify the management of multiple
domains. Forests have the following key characteristics:

• Single Schema
• Single Configuration Container
• Complete Trust
• Single Global Catalog
• Users Search the Global Catalog
• Users log on using User Principal Names

1. Forest Planning Process

The primary steps for creating a forest plan are as follows:

• Determine the number of forests for your network

• Create a forest change control policy
• Understand the impact of changes to the forest after deployment

3.1.2 Determining the Number of Forests

When you begin to plan your forest model, start with a single forest. A single forest is
sufficient in many situations; however, if you decide to create additional forests, ensure
that you have valid, technical justification.

Creating a Single Forest Environment

A single forest environment is simple to create and maintain. All users see a single
directory through the global catalog and do not need to be aware of any directory
structure. When adding a new domain to the forest, no additional trust configuration is
required. Configuration changes only need to be applied once to affect all domains.

Creating a Multiple-Forest Environment

If administration of your network is distributed among many autonomous divisions, it
might be necessary to create more than one forest.

17
Because forests have shared elements, such as schema, it is necessary for all the
participants in a forest to agree on the content and administration of those shared
elements.

It might be necessary to create more than one forest if:

• Network administration is broken into multiple autonomous groups

• The multiple autonomous groups do not trust each other
• Each autonomous group wants individual control over the schema
• The need to limit trust relationships between domains and trees

The consequences of having more than one forest:

• You will have multiple schemas and maintaining consistency between them will
create overhead
• You will have multiple configuration containers. Network topology changes will
have to be replicated manually to each additional forest, thereby creating more
management requirements
• Users will have to explicitly query resources outside their own forest
• Any replication of information between forests will be manual
• You cannot easily move accounts between forests

3. Forest Change Control Policy

Each forest you create should have an associated Forest Change Control Policy as part of
your Forest Plan document. You will use this policy to guide changes that have forest-
wide impact. You do not need to determine the individual processes before continuing,
but understanding their ownership is important. The policy should include information
about each of the shared elements in a forest.

Schema Change Policy

The schema administrators group has full control over the schema for a forest. The
schema change policy should include:

• The name of the team in your organization that controls the schema administrators
group
• The starting membership of the schema administrators group
• Guidelines and a process for requesting and evaluating schema changes

Configuration Change Policy

The enterprise administrators group has full control over the Configuration container that
is replicated throughout the forest. The configuration change policy should include:

• The name of the team in your organization that controls the enterprise
administrators group
• The starting membership of the enterprise administrators group
• Guidelines and a process for creating new domains in the forest

18
 • Guidelines and a process for modifying the forest site topology

3.1.4 Changing the Forest Plan after Deployment

When a domain is created, it can be joined to an existing forest. You can create a domain
by promoting a Windows 2000 server to the Active Directory domain controller role, or
by upgrading NT Primary Domain Controller to Windows 2000.

Individual objects can be moved between forests. However, the current tools for
importing and exporting objects between multiple forests are crude. It is important to
remember that two forests cannot be merged in a one-step operation, nor can you move a
domain between forests as a one-step operation.

Best Practice # 2 (see Part III). It is important that the forest plan requires a minimum
amount of restructuring as your organization evolves.

2. Domain Plan

The domain plan is perhaps the most complicated aspect of the Active Directory design
process. Microsoft has closely integrated Microsoft Domains, LDAP Directory Services,
and DNS. Each of these technologies is complicated; the integration of these technologies
exacerbates complexity.

The planning process described below is divided into three parts:

• Determining the number of domains

• DNS and Domain Names
• Post Deployment Change management

There are a few more steps but bullets 1 and 2 above are the bulk of the planning effort.
Reducing the number of domains in the forest is on everyone’s short list of design goals.
DOE sites may require a few more domains than average corporate America’s
organizations due to organizational structures and the security compliance issues.

The close integration of DNS name space and domain name space (which is actually
LDAP name space) is not only complicated, this aspect of AD is also very intrusive to the
existing DNS infrastructure. DNS options are described in more detail in Appendix A.

3.2.1 Domain Planning Process

“Your domain plan will determine the availability of the directory on the network, the
query traffic characteristics of the clients, and the replication traffic characteristics of the
domain controllers.”

“When creating the Domain Plan for each forest, you will most likely need to consult
with the following groups:

19
 • Current domain administrators who are responsible for user accounts, groups, and
computers
• Teams that manage and monitor the physical networks
• Team that manage DNS
• Security teams”

The steps to creating a domain plan for a forest are:

• Determine the number of domains in each forest

• Choose a forest root domain
• Assign a DNS name to each domain to create a domain hierarchy
• Plan DNS server deployment
• Optimize authentication with short cut trusts
• Understand the impact of changes to the domain plan after deployment

2. Determining the Number of Domains in each Forest

Three possible reasons for creating additional domains are:

1. Preserving existing Windows NT domains

“If you have existing NT domains, you might prefer to keep them instead of
consolidating them into fewer Active Directory Domains”

2. Administrative Partitioning
Administration partitioning may be required to support autonomous
administration, security, and privacy

3. Physical Partitioning
There are very complicated “replication” issues with the Active Directory
Services.” In a nutshell, domains can scale to millions of objects and any domain
controller is capable of providing updates, which in turn causes this information
to be replicated to all the domain controllers. There are cases where a new domain
is justifiable just to control replication traffic.

3. Choose a Forest Root Domain

See Best Practice # 3 in Part III.

4. Assign a DNS name to each domain to create a domain hierarchy

Active Directory domains are named with DNS names that are the locator services for the
Active Directory. Clients query DNS to locate services such as LDAP and Kerberos Key
Distribution Centers. Also, a client uses DNS to determine what site it is in and what site
its domain controller is in. The location service is a complicated mix of DNS and LDAP
queries.

Associated with this task is the planning of the number of trees. The goal of this task is to
minimize the number of trees because each tree requires a separate DNS zone. Additional
trees require maintaining a separate DNS zone per tree.

20
5. Plan the DNS Server Deployment
Microsoft recognizes that most existing DNS infrastructure is based on Berkeley Internet
Domain Daemon (BIND). Bind 8.1.2 does support dynamic updates and also supports
service resource records all in accordance to RFC 2136. BIND servers can support the
Active Directory; however, Microsoft’s strategy of “embrace and extend the standards”
has caused Active Directory DNS to be noncompliant with the current DNS standards.
AD DNS supports Unicode and the use of the underscore character in their resource
records (note, there is a pending DNS RFC that will support Unicode).

1. Background
Windows 2000 Active Directory has integrated DNS name space with their Domain
Name space, (which is actually LDAP name space). Novell Directory Services and
Netscape iPlanet have not integrated DNS names with any structure related to their
LDAP Directory Information Trees.

Microsoft’s utilization of DNS name space has made the deployment of AD into
established networks a confusing and intrusive task. This “requirement” is probably a
reason why industry has been slow to adopt Microsoft’s Active Directory Services.

Appendix A, DNS Options, lists some of the design possibilities that are available to the
Active Directory designers. Note, the author of this paper has reviewed and tested many
other DNS designs (referred to as short cut DNS designs), all with the intent to defeat the
AD DNS requirements. These “clever DNS designs” always create problems in some
other aspect of the design (see Option # 5 in Appendix A).

Here is a brief description on how the name space integration works. This is an excerpt
from the Distributed Services Guide in the Resource Kit. Always keep the information
below in mind, when reviewing a DNS “short-cut” design.

Every Windows 2000 domain has a DNS name (for example, doe.gov), and every
Windows 2000-based computer has a DNS name (for example, talos.doe.gov).
Thus, domains and computers are represented both as objects in Active Directory
and as nodes in DNS.

Because DNS domains and Active Directory domains share identical domain
names, it is easy to confuse their roles. The difference is that the two name
spaces, although sharing an identical domain structure, store different data and,
therefore, manage different objects: DNS stores zones and resource records, and
Active Directory stores domain and domain objects. Both systems use a database
to resolve names.

DNS resolves domain names and computer names to resource records through
requests received by DNS servers as DNS queries to the DNS database. Active
Directory resolves domain object names to object records through requests that

21
 are received by domain controllers, as LDAP search requests or as modify
requests to the Active Directory database.

Thus, the Active Directory domain computer account object is in a different name
space from the DNS host record that represents the same computer in the DNS
zone.

The sentence above, (bold and underlined), is the technical reality that the DNS
designers may try to defeat. Microsoft has designed the AD where the DNS Domain
name and the AD Domain name are identical. Measures to defeat this reality can crop up
during your design process. If so, insist that the DNS designers produce “reference sites”
that are utilizing the proposed design. Also, consider that the entire list of Books in
Appendix B will not describe any designs that defeat this fundamental DNS-to-AD
Domains naming constraint.

This coincidence of the name spaces is cause for confusion as pointed out above. The
complexities are compounded again by the fact that LDAP queries will use DNS to locate
domain controllers and AD services.

The main thought to keep in mind when reading through the examples below in
Appendix A, is that a client’s DNS domain name determines where in the AD a client
searches for its resources. This example should offer clarification; client talos.w2k.local
has w2k.local as the DNS domain portion of its fully qualified name. When this client
conducts an LDAP search, the LDAP query will first search the Global Catalog (GC). If
the information is not found in the GC, the client will then search its partition. The DNS
portion of its fully qualified DNS domain name, which is the same name as its AD
domain (w2k.local) determines its partition.

DNS Option #5 (Appendix A) points out some of the problems of having a client in one
DNS domain and its partition in another DNS domain.

3.3 Organizational Unit Plan

OU design and planning is another very complex aspect of the design. However, changes
to the design after deployment, are relatively easy to accomplish. A well-designed OU
plan will ensure a return on investment for your AD effort.

Executive management should have a support role in this process but they will be more
dependent on their technical resources than in the case for Domain Name space Design.

The decisions on OU design, GPO, security groups, and delegation are critical; however
these aspects of AD are designed to handle the changes to your directory. Therefore,
these design decisions do not represent as great a risk as the more permanent aspects of
the design (Domain Name space)!

22
Best Practice #1 advocates pushing complexity down to the OU. Here are some reasons
why complexity should be handled at the OU level.

• Changing the OU Structure is fairly easy

• OUs are very flexible when used in conjunction with security groups and Group
Policy Objects
• OUs offer a type of security boundary
• GPOs as a parent OU are inherited by a child OU (remember this does not happen
at the domain level: a child domain does not inherit policy from its parent domain
in the domain name space)
• OUs can be delegated administration rights, thus saving the cost of adding a
domain just for administrative reasons
• The initial OU design requirements can be influenced by the down level domain
migration requirements. The OU infrastructure can be redesigned after the
migration

The flexibility of the OU also leads to many complicated design scenarios. As a sub
component of a Domain, it follows that each Domain will have different criterion for its
OU design. (Domains that are migrating from NT 4 will have additional considerations
for its OU design).

Below are some general design guidelines and descriptions of the potential use of the
OU. There is however an important best practice (Best Practice #10, Part III).

“The best approach that you can take with OUs is to create them based on your IT
administrative structure and not on your organization’s management structure (or
any other structure, for that matter).” The above is an excerpt from Microsoft’s
AD technical Reference, but you can find similar statements in most of the works
listed in the bibliography.

There are some other reasons why you might want to create OUs, such as to use
them as Group Policy boundaries. Since OUs can be nested into many levels,
there are a number of reasons why you might create additional (nested) OUs to
make administration of Windows 2000 and Active Directory easier.

The figure below is a fictitious Domain with its associated OU. The narrative description
that follows is a description of each OU (why it was created), which also explains the
types of administrative delegation where applicable, what GPO’s are applied at the OU,
and what security templates are applied to the computers within the OU. (Security
templates are registry settings to the local computer. The templates are applied either as a
local policy on a specific computer or at the domain level by a GPO. Computers that
require different security templates should be placed in separate OUs).

23
 OU Structure

Default
Domain Policy Default DC Default DC
Program Policy
Domain

DIv Division OU
Admins

Workstation
Sec Template Pro X
Admin

Sensitive OU Sensitive
Server Sec Servers Workstations USERS Project X OU
Template

pKICertificate
Template
Admins Engineers

Ledger
Domain
File Share WWW Application
domainDNS2

OU
organizational
Unit3
WWW Sec
Template
GPO
aCSPolicy3

Certificate
pKICertificate
Template2

Security
Group

The diagram above depicts a typical domain with its OU structure. Also noted are the
Group Policy Objects. Starting with the domain you can see two GPOs, the default
domain policy and the default domain controller. All the domain controllers are located in
a separate OU and the GPO is specific to the DCs.

This domain has multiple divisions but only one divisional OU structure is shown. The
entire divisional OU structure inherits the default domain policy. The divisional system
administrators operate independently from the domain administrators; therefore the
domain administrators have delegated “full control rights” to the Div. Administrators
security group.

24
The administrators of the divisional OU have created four OUs directly under their
divisional OU. Below are descriptions of each OU.

• All division servers are located in the servers OU and its child OUs. A separate
GPO is applied at the server OU, to enhance the security and functionality of each
server. The web servers located in the WWW OU has an additional GPO, which
contains the Security Templates specific to the Internet Information Servers and
prevents any other services from running on the IIS servers.
• All workstations are located in the workstation OU. For safe operation of
workstations. The workstation GPO is applied to provide software distribution
and security templates. Settings in response to vulnerabilities (ISS Scans) are
included in the security template and are applied to every workstation in the OU.
• All the division’s users are located in the USER OU structure. The default domain
policy (inherited) is adequate (account policy, account lockout policy, and
Kerberos policy). There are two other groups of users that have special
requirements. The engineering group has special software requirements and also
need extra privileged systems rights to develop their software. The divisional OU
administrators also have a separate OU (this group’s distinction is obvious). Not
shown in the diagram is separate GPO and security templates for each of these
child OUs.
• The project X OU contains the infrastructure necessary for work on this sensitive
project. All user accounts and computers that are associated with the project are
located in the OU. Full control administrative rights have been delegated to the
Proj X security group. This OU may have a hierarchical structure below it but
these OUs are hidden from the Active Directory.
• The last OU is the program’s sensitive OU that can protect “critical computer
systems.”

4. Site Planning Process

An Active Directory site topology is a logical representation of a physical network. Site

topology is defined on a per-forest basis. Active Directory clients and servers use the site
topology of a forest to route query and replication traffic efficiently. A site topology also
helps you to decide where to place domain controllers on your network. Keep the
following definition in mind when designing the site plan.

A site is a set of networks with fast reliable connectivity.

A site is defined as a set of IP sub networks connected by fast reliable connectivity. As a
rule of thumb, networks with LAN speed or better are considered as fast networks.

To create a site topology for a forest, use the following process:

• Define sites and site links using your physical topology as a starting point. (Site
links are connection objects, used to connect two sites, which are normally
connected as a Wide Area Network)
• Place servers into sites

25
 • Understand how changes to your site topology after deployment will impact end
users

When creating the site topology plan, you will most likely need to consult:

• Teams that manage and monitor the TCP/IP networks

• Domain administrators for each domain in the forest

Warning on Applying Group Policy at the Site Level

Group Policy will flow down a hierarchy in the following order:

• Site
• Domain
• OU

The bulleted list above shows that the domain, then the OU, and lastly the local computer
policy, will inherit policy that is applied to a site. Some designers will think it natural to
apply all security policies at the Site. This way all domains within a site will have the
same policy. This practice is not a good idea for the following reasons:

1) Best Practice Number 1, states that complexity should be pushed down the
hierarchy. Multiple sites increase the complexity at the top of the hierarchy
2) An incorrect GPO applied at the site level will break every computer at the site
3) Site Level GPO will make troubleshooting GPO very difficult
4) The Active Directory Domain has a separate OU for domain controllers. A
separate and special GPO is applied to the domain controllers OU. Policy at the
site level will override theses settings

Consider also, the following excerpt from Jennings (Windows 2000 Group Policy, page
11)
“You can apply Group Policy at the site level, but it is more common to establish
a basic set of policies on a domain-wide basis and then establish policies that
apply to individual OUs. The primary use of site-level Group Policies is to specify
different servers to store redirected folders, roaming user profiles, or both,
depending on the client’s site membership.

Another reason to start at the domain level is that domains have a Default Domain
Policy, and sites don’t have a Default Site Policy.”

Security templates and OUs can be deployed for the purpose of associating computers
that require a unique and custom Security Template. Any setting generated by GPO, or
Administrator Templates that change the registry of any computer, should be applied
directly to the OU that houses the computer account (Security Training Guide page 271).

Here is another reason for not applying many policies at the site level. Many policies are
domain concepts. Lowe-Norris lists domain centric policies on page 112.

26
 • Password Policies, such as password length, password expiry interval and so forth
• Account Lockout Policies
• Kerberos policies
• Encrypted file system recovery policies
• IP security policies
• Public Key encryption policies
• Certificate authorities

When designing Group Policy, always test your design on a pilot network. What makes
sense at first glance may be a total disaster!

Replication and Query Traffic

As stated above, site design effects query traffic and replication traffic. The subject of
replication is very complicated (second to name space design). There are hard limits to
the number of domains and sites the Knowledge Consistency Checker can handle.
Trouble shooting replication problems is not easy and increasing the number of sites
makes the replication topology more complicated. Most DOE sites have a high
bandwidth backbone that translates into a very well connected campus. Below are two
excerpts on the subject of breaking up a well-connected collection of well-connected
TCP/IP sub networks.

From Lowe-Norris page 163, “Remember that a site is a well-connected set of

subnets (well-connected tends to mean about 10-MBps LAN speed). A site does not
have to have a server in it; it can be composed entirely of clients. If you have two
buildings, or an entire campus that is connected over 10.100-MBps links, your
entire location is a single site.”

Lowe-Norris continues on page 165. “To summarize, I would suggest that, by default,
you create one site per 10-MBps-or-higher location, unless you have an overriding
reason not to do so.”

From Rand Morimoto (Windows 2000 Design and Migration, page 150) under the
bold section heading:

“Don’t Divide Well-Connected Segments into Multiple Sites”

“It’s not a good idea to create multiple sites on a well-connected network. By
dividing well-connected subnets into multiple sites, you can actually decrease the
performance.”

4.0 Scope of AD Design

Directories are a fundamental change to Information Technology design and

management. The limitations of previous technologies, such as NT4 domains and
UNIX’s NIS and NIS+, would actually dictate organizational operations. Lightweight
Directory Access Protocol (LDAP) directories can actually accommodate organizational

27
processes and even facilitate Business Process Reengineering. The potential rewards and
risks of designing and deploying a directory are enormous.

The promise of LDAP based directories with its inherent ability to consolidate and
disseminate corporate information, is achievable by “General Purpose Directories.”
The design and deployment of a General Purpose LDAP Directory requires cooperation
and buy in from the top executives, divisional management, IT management, and end
users. The development of new “directory aware” applications is central to directory
planning. New LDAP applications are the vehicles that can lead to Business Process
engineering (see Reed).

The formal design process of a general purpose directory involves the business
justification, total cost of ownership issues, return of investment cycles, restructuring of
the IT department, and so forth. The AD design process does not necessarily have to
include these high level functions.

In spite of Microsoft’s marketing efforts, Active Directory (AD) is not considered a

general-purpose directory. Active Directory is a Network Operating System (NOS)
directory. What this means to the scope of an AD design is that the return on investment
(ROI) can be calculated by the savings in the cost of IT management and the cost savings
of security compliance. It is true that future releases (Server.NET) of AD will move
toward a general-purpose directory, but currently there are very few AD aware
applications that could lead to the streamlining of business processes.

Designing a NOS Directory such as AD simplifies the design process, especially at the
corporate application levels. You shouldn’t need to include the consolidation of all
current directories into the Active Directory as part of your design process. Today such
planning is best left to other technologies such as Meta Directories (see Burton Group in
bibliography). However, even omitting directory consolidation from the design, the
design of and the design process of an Active Directory is still a very daunting and
complicated task.

With all of Active Directory’s shortcomings, the benefits of a good AD design are very
valuable to all DOE sites. Security compliance issues have greatly raised the cost of
ownership for all DOE computers. The time required to deploy a fully compliant
Windows 2000 or NT4 workstation has been stated as 45 minutes to a full hour for each
computer. A proper Active Directory design can automate most of these compliance
issues, saving thousands of hours of administrative time per DOE site. As new
vulnerabilities are discovered, “hot fixes” and patches are produced to close these
security holes and an administrator has to visit each and every computer to apply these
fixes. With Active Directory, these “hot-fixes” and patches can be deployed to an
entire DOE site from just a few locations, or even from a single location.

A well-designed and timely deployment of an Active Directory can ease the time effort of
security compliance and the IT staffs can rededicate their efforts of facilitating the
programmatic mission.

28