Free Active Directory Tutorial

Ref : www.Learnthat.com

What is Active Directory?

Like other directory services, such as Novell Directory Services (NDS), Active Directory is a
centralized and standardized system that automates network management of user data,
security and distributed resources and enables interoperation with other directories.

Active Directory is designed especially for distributed networking environments.

AD is functionally a place to store information about people, things (computers,

printers, etc), applications, domains, services, security access permissions, and more.
Applications and services then use the directory to perform a function.

For example, Microsoft Windows uses Active Directory information to allow a user to
login to their computer and provide access to the security rights assigned in Active
Directory. Windows is accessing the directory and then providing rights based on what
it finds. If a user account is disabled in Active Directory, the directory itself is just
setting a flag which Windows uses to disallow a user from logging in.
We mentioned in the introduction that administrators use Active Directory to deploy
software – this is an incomplete description. Administrators can set policies and
information that a certain software application should be deployed to a certain user –
AD itself does not deploy the software, but a Windows service reads the information
from Active Directory and then installs the software.

Introduced in 2000 server and further enhanced for windows server 2003, provides a single
reference, called a directory service, to all the objects in a network, including users, groups,
computers, printers, policies and permissions.

Active Directory (AD) is a technology created by Microsoft to provide network services

including LDAP directory services; Kerberos based authentication, DNS naming, secure
access to resources, and more. Active Directory uses a single Jet database which a variety
of services and applications can use to access and store a variety of information. Active
Directory is used by system administrators to store information about users, assign security
policies, and deploy software. AD is used in many different types and size of environments
from the very small (a dozen users) to hundreds of thousands of users in a global
environment.
In this tutorial, you will learn the basic structure of Active Directory, gain an understanding
of how Active Directory works, learn how to install Active Directory, and learn the
components of AD.
This tutorial is divided into these sections:
Why implement Active Directory?

First and foremost, Microsoft Active Directory is generally considered to be a significant improvement over Windows
NT Server 4.0 domains or even standalone server networks. Active Directory has a centralized administration
mechanism over the entire network. It also provides for redundancy and fault tolerance when two or more domain
controllers are deployed within a domain.

Active Directory automatically manages the communications between domain controllers to ensure the network
remains viable. Users can access all resources on the network for which they are authorized through a single sign-
on. All resources in the network are protected by a robust security mechanism that verifies the identity of users and
the authorizations of resources on each access.

History of Active Directory

Active Directory was introduced to the world in the mid-1990s by Microsoft as a
replacement for Windows NT-style user authentication. Windows NT included a flat and
non-extensible domain model which did not scale well for large corporations. Active
Directory, on the other hand, was created as a true directory service versus a flat user-
management service that NT had. Though it was introduced in the 1990s, it did not
become a part of the Operating System until Windows 2000 Server was released in
2000. Since then, Windows Server 2003 and Server 2008 have been introduced and
Active Directory has gone under some expansion.
This tutorial is based on Windows Server 2003 as it is currently the most widely
installed version of the Windows network Operating System (NOS), though in the future
we will release versions for Windows Server 2008 and future Windows releases as it
becomes necessary. Though this tutorial is not focused on Windows Server 2008, much
of the basic knowledge and instruction relates to either OS.

LDAP

Active Directory and LDAP

Microsoft includes LDAP (Lightweight Directory Access Protocol) as part of Active Directory. LDAP is a software
protocol for enabling anyone to locate organizations, individuals and other resources such as files and devices in a
network, whether on the public Internet or on a corporate intranet.

In a network, a directory tells you where in the network something is located. On TCP/IP networks (including the
Internet), the domain name system (DNS) is the directory system used to relate the domain name to a specific
network address (a unique location on the network). However, you may not know the domain name. LDAP allows you
to search for individuals without knowing where they're located (although additional information will help with the
search).

An LDAP directory is organized in a simple "tree" hierarchy consisting of the following levels:

 The root directory (the starting place or the source of the tree), which branches out to
 Countries, each of which branches out to
 Organizations, which branch out to
 Organizational units (divisions, departments and so forth), which branch out to (include an entry for)
 Individuals (which include people, files and shared resources, such as printers)
An LDAP directory can be distributed among many servers. Each server can have a replicated version of the total
directory that is synchronized periodically.

It is important for every administrator to have an understanding of what LDAP is when searching for information in
Active Directory and to be able to create LDAP queries is especially useful when looking for information stored in your
Active Directory database. For this reason, many admins go to great lengths to master the LDAP search filter.

Active Directory is based loosely on LDAP – Lightweight Directory Access Protocol – an

application protocol for querying and modifying directory services developed at the
University of Michigan in the early 1990s. An LDAP directory tree is a hierarchical
structure of organizations, domains, trees, groups, and individual units.

Example of an LDAP Tree

Active Directory Structure

Unlike Windows NT, Active Directory is designed for you to create a functional and
usable hierarchy for your environment. Not only does this make the environment look
cleaner, but it also allows central system administrators to delegate specific authority
over areas to other administrators, team members, and groups. AD has a very flexible
structure, allowing you to build a hierarchy in whatever way you wish – one big unit,
broken down by geographic location, by department, by astronomical sign, or however
you desire.
Achieving this flexibility in hierarchical design is a defined structure. The structure of
Active Directory starts with forests and domains and goes down to organizational units
and individual objects (such as a user or computer account).
Basic Active Directory Components
It provides the basic building blocks for people to build their own directory. These basic
building blocks of Active Directory include domains, domain controllers, trusts, forests,
organizational units, groups, sites, replication, and the global catalog.

Forests: The collection of every object, its attributes and attribute syntax in the Active
Directory.
Domain: A collection of computers that share a common set of policies, a name and a
database of their members.
Organizational units: Containers in which domains can be grouped. They create a hierarchy
for the domain and create the structure of the Active Directory's company in geographical or
organizational terms.
Sites: Physical groupings independent of the domain and OU structure. Sites distinguish
between locations connected by low- and high-speed connections and are defined by one or
more IP subnets.

Understanding Forests
At the top of the Active Directory structure is a forest. A forest holds all of the objects,
organizational units, domains, and attributes in its hierarchy. Under a forest are one or
more trees which hold domains, OUs, objects, and attributes.

Forests are not limited in geography or network topology. A single forest can contain numerous domains, each
sharing a common schema. Domain members of the same forest need not even have a dedicated LAN or WAN
connection between them. A single network can also be the home of multiple independent forests. However,
additional forests may be desired for testing and research purposes outside of the production forest.
As illustrated in this image, there are two trees in the forest. You might use a structure
like this for organizations with more than one operating company.
You could also design a structure with multiple forests, but these are for very specific
reasons and not common.

Domains
At the heart of the Active Directory structure is the domain. The domain is typically of
the Internet naming variety (e.g. Learnthat.com), but you are not forced to stick with
this structure – you could technically name your domain whatever you wish.

Microsoft recommends using as few domains and possible in building your Active
Directory structure and to rely on Organizational Units for structure. Domains can
contain multiple nested OUs, allowing you to build a pretty robust and specific
structure. Domains serve as containers for security policies and administrative assignments. All objects within a
domain are subject to domain-wide Group Policies by default. Likewise, any domain administrator can manage all
objects within a domain. Furthermore, each domain has its own unique accounts database. Thus, authentication is on
a domain basis. Once a user account is authenticated to a domain, that user account has access to resources within
that domain.

Domain Controllers
In Windows NT, domains used a Primary Domain Controller (PDC) and Backup Domain
Controller (BDC) model. This had one server, the PDC, which was “in charge” while the
other DCs where subservient. If the PDC failed, you had to promote a BDC to become
the PDC and be the server in charge.
In Active Directory, you have multiple Domain Controllers which are equal peers. Each
DC in the Active Directory domain contains a copy of the AD database and synchronizes
changes with all other DCs by multi-master replication. Replication occurs frequently
and on a pull basis instead of a push one. A server requests updates from a fellow
domain controller. If information on one DC changes (e.g. a user changes their
password), it sends signal to the other domain controllers to begin a pull replication of
the data to ensure they are all up to date.
Servers not serving as DCs, but in the Active Directory domain, are called ‘member
servers.’

Organizational Units

Organizational units are much more flexible and easier overall to manage than domains. OUs grant you nearly infinite
flexibility as you can move them, delete them and create new OUs as needed. However, domains are much more
rigid in their existence. Domains can be deleted and new ones created, but this process is more disruptive of an
environment than is the case with OUs and should be avoided whenever possible.
An Organizational Unit (OU) is a container which gives a domain hierarchy and
structure. It is used for ease of administration and to create an AD structure in the
company’s geographic or organizational terms.

Organizational Units
An OU can contain OUs, allowing for the creating of a multi-level structure, as shown in
the image above. There are three primary reasons for creating OUs:
Organizational Structure: First, creating OUs allows a company to build a structure in
Active Directory which matches their firm’s geographic or organizational structure. This
permits ease of administration and a clean structure.
Security Rights: The second reason to create an OU structure is to assign security
rights to certain OUs. This, for example, would allow you to apply Active Directory
Policies to one OU which are different than another. You could setup policies which
install an accounting software application on computers in the Accounting OU.
Delegated Administration: The third reason to create OUs is to delegate
administrative responsibility. AD Architects can design the structure to allow local
administrators certain administrative responsibility for their OU and no other. This
allows for a delegated administration not available in Windows NT networks.
Sites

By definition, sites are collections of IP subnets that have fast and reliable communication links between all hosts.
Another way of putting this is a site contains LAN connections, but not WAN connections, with the general
understanding that WAN connections are significantly slower and less reliable than LAN connections. By using sites,
you can control and reduce the amount of traffic that flows over your slower WAN links. This can result in more
efficient traffic flow for productivity tasks. It can also keep WAN link costs down for pay-by-the-bit services.

An Active Directory site object represents a collection of IP subnets, usually constituting

a physical Local Area Network (LAN). Multiple sites are connected for replication by site
links. Typically, sites are used for:
Physical Location Determination: Enables clients to find local resources such as
printers, shares, or domain controllers.
Replication: You can optimize replication between domain controllers by creating links.

By default, Active Directory uses automatic site coverage, though you can purposefully
setup sites and resources.

Groups
Groups serve two functions in Active Directory: security and distribution.
A security group contains accounts which can be used for security access. For
example, a security group could be assigned rights to a particular directory on a file
server.
A distribution group is used for sending information to users. It cannot be used for
security access.
There are three group scopes:
Global: Global scope security groups contains users only from the domain in which is
created. Global security groups can be members of both Universal and Domain Local
groups.
Universal: Universal scope security groups can contain users, global groups, and
universal groups from any domain. These groups are typically used in a multi-domain
environment if access is required across domains.
Domain Local: Domain Local scope groups are often created in domains to assign
security access to a particular local domain resource. Domain Local scope groups can
contain user accounts, universal groups, and global groups from any domain. Domain
Local scope groups can contain domain local groups in the same domain.

Trust Relationships
Trust Relationships are important in an Active Directory environment so forests and
domains can communicate with one another and pass credentials. Within a single
forest, trusts are created when a domain is created. By default, domains have an
implicit two-way transitive trust created. This means each domain trusts each other for
security access and credentials. A user in domain A can access resources permitted to
him in domain B while a user in domain B can access resources permitted to her in
domain A.
AD allows several different types of trusts to be created, but understanding the two-
way transitive trust is the most important to understanding AD.
Replication

Understanding Active Directory replication

Active Directory replication is key to the health and stability of an Active Directory environment. Without proper and
timely replication, a domain will be unable to function effectively. Replication is the process of sending update
information for data that has changed in the directory to other domain controllers. It is important to have a firm
understanding of replication and how it takes place, both within the domain and in multiple-site environments.

There are three main elements or components that are replicated between domain controllers: the domain partition
replica, the global catalog and the schema.

The domain partition replica is the Active Directory database of a domain. Each domain controller maintains a
duplicate copy of its local domain partition replica. Domain controllers do not maintain copies of replicas from other
domains. When an administrator makes a change to the domain, that change is replicated to all domain controllers
immediately.

Each forest contains only a single global catalog. By default, the first domain controller installed into a forest is the
global catalog server. The global catalog contains a partial replica of every object within each domain of the forest.
The global catalog serves as a master index for the forest, which allows for easy and efficient searching for users,
computers, resources and other objects. Any domain controller can be configured to act as a peer global catalog
server. You should have at least two global catalog servers per domain and at least one per site. As changes are
made to objects within the forest, the global catalog is updated. Once the global catalog is changed on one domain
controller, it is replicated to all other domain controllers in the forest.

Every domain controller in a forest has a copy of the schema. Just as with changes to the Active Directory database
(i.e., domain partition replica), any changes to the Active Directory schema are replicated to all other domain
controllers in the forest. Fortunately, the schema is usually static so there is little replication traffic caused by schema
changes.

Multi-master replication

Within Windows-based Active Directory domains, each domain controller is a peer server. Each domain controller
has equal power and responsibility to support and maintain the Active Directory database. It is this database that is
essential to the well-being and existence of the domain itself. This is such an important task that Microsoft elected to
make it possible to deploy multi-redundant systems to support Active Directory by making each domain controller a
peer.

Whenever a change occurs to any object within an Active Directory domain, that change is replicated automatically to
all domain controllers within the domain. This process is called multi-master replication. Multi-master replication does
not happen instantly across all servers simultaneously. Rather, it is a controlled process where each domain
controller peer is updated and validated in a logically controlled procedure.

As an administrator, you have some control over how multi-master replication occurs. Most of your control is obtained
through the use of sites. A site is a logical designation of domain controllers in a network that are all located within a
defined physical area. In most cases, sites control traffic over high-expense low-bandwidth WAN links. When a
domain exists on two or more sites, normal Active Directory replication between the domain controllers in different
sites is terminated. Instead, a single server within each site, labeled as a bridgehead server, performs all replication
communications. You can configure this bridgehead server for when replication is allowed to occur and how much
traffic it can generate when performing replication.

You can use sites to control replication even if you do not employ WAN links on your network. Sites effectively give
administrators control over how and when AD multi-master replication occurs within their network.
Active Directory replication topology design

One of the secrets to an efficient and error-free Active Directory infrastructure is a well-designed replication topology.
While this can be easy to design in a simple network, a large, complex network presents a challenge. Designing the
AD topology efficiently is to construct it so that it takes advantage of the strengths and minimizes the weaknesses of
the network. In a complex network, you are likely to have a number of different link speeds connecting remote sites.

The best practices for Active Directory replication design include:

1. Design the AD topology to take advantage of the network topology and link speeds.
2. Define lower speed links with higher cost site links. The cost of the links reduces as you
get to faster areas in the topology.
3. Avoid "dead spots" -- all sites must connect to each other eventually. I have seen some
topologies that left certain sites isolated because they didn't design the site links to connect them.
4. Site links should only have two sites per link. The exception to this is the Core site link
which can have more. Defining more than two sites per link can result in unpredictable results when
a DC failure occurs.
5. Diagram the overall flow of replication (like the figures here). You can use sophisticated
features available in tools like HP OpenView (see the example in Figure 3) or Microsoft MOM, or
you can simply draw it in a PowerPoint slide as I did in Figure 2. You'd be surprised at how many
errors you will find by making a drawing of the topology.
6. Don't define scheduling unless you really have a good reason, and then you should test it
thoroughly. Since you can schedule replication over the site link as well as the connection object
itself, and since the resultant replication schedule is a merge of the two, you can end up with a
schedule that prohibits replication. You also define replication frequency, which further complicates
it. For instance, if you schedule the site links to replicate Monday through Friday from 8 a.m. to 6
p.m., and then have some connection objects that only replicate Tuesday and Thursday from 6
p.m. to 10 p.m., those connection objects will never replicate. Unless you have a very slow or
limited network (such as VPN links), you should avoid this level of manual intervention.
7. Run the AD in Windows 2003 Forest mode. This means all DCs are at Windows Server
2003, and all domains are running in Windows 2003 mode. This takes advantage of the new
spanning tree and compression algorithms available in Windows Server 2003, as well as other
features that make replication much more efficient than were available in Windows 2000.
8. Monitor the AD. Once you get it in place, monitor it. One of the easiest ways to monitor it,
outside of using Microsoft or third-party tools, is using the Repadmin tool and its "Replsum"
option: Repadmin /replsum /bydest /bysrc /sort:delta. This will provide a nice, neat table of all DCs
in all domains in the forest, telling you how long it has been for outbound and inbound replication
(i.e. where each DC appears as a source and destination). Watching this over several days will
give you a chance to find any holes in the topology.

Troubleshooting Active Directory replication

Replication should occur automatically. When it doesn't, the best solution isn't just to force Active Directory
replication, but to check out the topology. If the replication topology has become unstable or misconfigured, it needs
to be corrected before initiating a manual replication procedure.

The Knowledge Consistency Checker (KCC) creates the replication topology used for intra-site replication
automatically. Rather than creating a full mesh for replication, the KCC designs a topology where every DC has at
least two replication partners and is no more than three hops away from any other DC. With such a topology, every
DC can be fully updated with as little as three replication cycles.

The REPAdmin tool from the Windows Support Tools and Resource Kit can be used to check the topology. The
command "repadmin /showreps" runs on a domain controller and produces a list of replication partners as designated
by the KCC. To check the topology, verify that every DC lists at least two replication partners and that all named
partners see each other as partners. For example, if Server A lists Server B and C as partners, then both Server B
and C should list Server A in return as a partner. If you discover a problem or inconsistency in the topology, use the
KCC to regenerate the topology.

Once you are sure the topology is correct, then and only then should you force Active Directory replication.
Debugging replication errors

The lion's share of Active Directory problems are to some degree caused by replication failures, and one of the most
notorious replication errors is the Event ID 1311.

The first step in resolving this replication error is to determine the scope of the error. The easiest way to do this is with
the Repadmin/Replsum command. This will give you a complete summary of all the DCs in the forest, including the
relevant event ID if it is in an error state. The general form of the command is this:

Repadmin /Replsum /bysrc /bydest /sort:delta

Here is a sample output of this command. Note that there are four domain controllers failing replication. While the
1311 may not show up in the output of this command, it is common for it to be paired up with the 1722 event (which
basically means no physical connectivity). Obviously, if there is no physical connectivity (which would mean there
was a network failure), replication isn't going to happen. The first thing to do is to check the general health of the
domain using theRepadmin /replsum command just described. You can also ping broken DCs by address and FQDN,
and you can run NetDiag and DCDiag commands from the command line (with the /v switch on each). This will give
you more details about the errors and perhaps related ones.
Note: The network connecting all the sites should be fully routed. Don't create a site link if there is no underlying
network link to get between the sites in the site link.
Logical connectivity is a bit more difficult to diagnose. It means, bottom line, that something in the AD site topology
configuration is wrong, creating a hole in the topology. This could be solved by one of the following actions:
configuring a preferred bridgehead server, making sure all sites are defined in site links and making sure there is a
complete mesh of sites in site links.

DNS also must be taken into account. Since Active Directory replication relies on DNS name resolution to find DCs to
replicate with, if DNS is broken, it could cause the 1311 events to occur. The helpful thing here is that if DNS is the
culprit, the 1311 event will have the phrase "DNS Lookup Failure" included in the description. If you see this phrase,
then you absolutely, positively have a DNS problem that must be fixed.

When debugging 1311 events, you should get a scope of the entire forest to see which DCs are not replicating. You
can do this easily using the Repadmin /Replsum command. Note that the loss of physical connectivity, an incomplete
AD site topology or DNS failure usually cause these events, with an outside chance it will be an orphaned object (an
object that connot be found in the directory tree). Usually, other events will accompany them, such as the 1722 (RPC
Server Unavailable), or the event will contain a descriptive statement such as "DNS Lookup Failure." This is a critical
event that must be resolved in order for Active Directory replication to function properly to all DCs.

Since most Active Directory networks contain multiple domain controllers and users
could theoretically attach to any DC for authentication or information, each of the
servers needs to be kept up to date. Domain Controllers stay up to date by replicating
the database between each other. It performs this using a pull method – a server
requests new information from a different DC frequently. After a change, the DC
initiates a replication after waiting 15 seconds (in Windows 2003) or 5 minutes (in
Windows 2000). Windows Server 2003 uses technology to only replicate changed
information and compressions replication over WAN links.
Windows Server sets up a replication topology to determine where a server updates
from. In a large network, this keeps replication time down as servers replicate in a form
of a ring network.
Active Directory uses multi-master replication. Multimaster replication does not rely on
a single primary domain controller, but instead treats each DC as an authority. When a
change is made on any DC, it is replicated to all other DCs. Although each DC is
replicated alike, all of the DCs aren’t equal. There are several flexible single-master
operation roles which are assigned to one domain controller at a time.
AD uses Remote Procedure Calls (RPC) for replication and can use SMTP for changes to
schema or configuration.

FSMO Roles
All domain controllers are not equal. We know, it’s hard to hear. You’ve spent this
whole time reading this tutorial thinking that all DCs are created equal and now we
have to burst your bubble. Some DCs have more responsibility than others. It’s just
part of life!
There are five roles which are called operations masters, or flexible single-master
operations (FSMOs). Two are forestwide roles and three are domainwide roles.
The forestwide roles are:
Schema master: Controls update to the Active Directory schema.
Domain naming master: Controls the addition and removal of domains from the
forest.
The three domainwide roles are:
RID master: Allocates pools of unique identifier to domain controllers for use when
creating objects. (RID is relative identifier).
Infrastructure master: Synchronizes cross-domain group membership changes. The
infrastructure master cannot run on a global catalog server, unless all of the DCs are
global catalog servers.
PDC Emulator: Provides backward compatibility for NT 4 clients for PDC operations –
such as a password change. The PDC also serves as the master time server.
Global Catalog
As a network gets larger, it can contain multiple domains and many domain controllers.
Each domain only contains records from its own domain in its AD database to keep the
database small and replication manageable. The Active Directory domain relies on
a global catalog database which contains a global listing of all objects in the forest.
The Global Catalog is held on DCs configured as global catalog servers.
The global catalog contains a subset of information – such as a user’s first name and
last name – and the distinguished name of the object so your client can contact the
proper domain controller if you need more information. The distinguished name is the
full address of an object in the directory. For example, a printer in the OU Accounting in
the Learnthat.com domain might have a distinguished name of:
CN=AcctLaser1,OU=Accounting,DC=Learnthat,DC=com
The GC database is only a subset of the entire database called the Partial Attribute Set
(PAS), containing 151 of the 1,070 properties available in Windows Server 2003. You
can define additional properties for replication to the GC by modifying schema.

The Infrastructure Master and Global Catalog

Among the other key components within Active Directory is the Infrastructure Master. The Infrastructure Master (IM)
is a domain-wide FSMO (Flexible Single Master of Operations) role responsible for an unattended process that "fixes-
up" stale references, known as phantoms, within the Active Directory database.

Phantoms are created on DCs that require a database cross-reference between an object within their own database
and an object from another domain within the forest. This occurs, for example, when you add a user from one domain
to a group within another domain in the same forest. Phantoms are deemed stale when they no longer contain up-to-
date data, which occurs because of changes that have been made to the foreign object the phantom represents, e.g.,
when the target object is renamed, moved, migrated between domains or deleted. The Infrastructure Master
is exclusively responsible for locating and fixing stale phantoms. Any changes introduced as a result of the "fix-up"
process must then be replicated to all remaining DCs within the domain.

The Infrastructure Master is sometimes confused with the Global Catalog (GC), which maintains a partial, read-only
copy of every domain in a forest and is used for universal group storage and logon processing, among other things.
Since GCs store a partial copy of all objects within the forest, they are able to create cross-domain references without
the need for phantoms.

Group Policy management and Active Directory

It's difficult to discuss Active Directory without mentioning Group Policy. Admins can use Group Policies in Microsoft
Active Directory to define settings for users and computers throughout a network. These setting are configured and
stored in what are called Group Policy Objects (GPOs), which are then associated with Active Directory objects,
including domains and sites. It is the primary mechanism for applying changes to computers and users throughout a
Windows environment.

Through Group Policy management, administrators can globally configure desktop settings on user computers,
restrict/allow access to certain files and folders within a network and more.

It is important to understand how GPOs are used and applied. Group Policy Objects are applied in the following
order: Local machine policies are applied first, followed by site policies, followed by domain policies, followed by
policies applied to individual organizational units. A user or computer object can only belong to a single site and a
single domain at any one time, so they will receive only GPOs that are linked to that site or domain.
GPOs are split into two distinct parts: the Group Policy Template (GPT) and the Group Policy Container (GPC).
The Group Policy Template is responsible for storing the specific settings created within the GPO and is essential to
its success. It stores these settings in a large structure of folders and files. In order for the settings to apply
successfully to all user and computer objects, the GPT must be replicated to all domain controllers within the domain.

The Group Policy Container is the portion of a GPO stored in Active Directory that resides on each domain controller
in the domain. The GPC is responsible for keeping references to Client Side Extensions (CSEs), the path to the GPT,
paths to software installation packages, and other referential aspects of the GPO. The GPC does not contain a
wealth of information related to its corresponding GPO, but it is essential to the functionality of Group Policy. When
software installation policies are configured, the GPC helps keep the links associated within the GPO. The GPC also
keeps other relational links and paths stored within the object attributes. Knowing the structure of the GPC and how
to access the hidden information stored in the attributes will pay off when you need to track down an issue related to
Group Policy.

For Windows Server 2003, Microsoft released a Group Policy management solution as a means of unifying
management of Group Policy in the form of asnap-in known as the Group Policy Management Console (GPMC). The
GPMC provides a GPO-focused management interface, thus making the administration, management and location of
GPOs much simpler. Through GPMC you can create new GPOs, modify and edit GPOs, cut/copy/paste GPOs, back
up GPOs and perform Resultant Set of Policy modeling.

Active Directory and the Domain Name System (DNS)

DNS
Active Directory is integrated with Domain Naming System (DNS) and requires it to be
present to function. DNS is the naming system used for the Internet and on many
Intranets. You can use DNS which is built into Windows 2000 and newer, or use a third
party DNS infrastructure such as BIND if you have it in the environment. It is
recommended you use Window’s DNS service as it is integrated into Windows and
provides the easiest functionality.
AD uses DNS to name domains, computers, servers, and locate services.
A DNS server maps an object’s name to its IP address. For example, on the Internet, it
is used to map a domain name (such as www.learnthat.com) to an IP address (such
as 64.34.165.234). In an Active Directory network, it is used not only to find domain
names, but also objects and their IP address. It also uses service location records (SRV)
to locate services.

What is DNS? One can define the domain name system as the way that Internet domain names are located and
translated into Internet Protocol addresses. A domain name is a meaningful and easy-to-remember "handle" for an
Internet address.

Active Directory relies heavily on DNS to function, but not just any DNS. Active Directory is highly dependent on
the Microsoft DNS service found on Windows 2000 Server or Windows Server 2003 systems or equivalents.
However, though not highly recommended, it is possible integrate a non-Microsoft DNS to use with Active Directory.

Microsoft first introduced a DNS service with Windows NT Server 4.0. However, that early version of DNS from
Microsoft is not capable of supporting Active Directory. Windows NT Server 4.0 DNS lacks three specific features:
Service Resource Records (SRV RR), Dynamic DNS (DDNS) and Incremental Zone Transfers (IXFR). Without these
DNS features, Active Directory cannot function. Therfore, it is essential to understand how DNS works.

DNS is extremely important to all aspects of proper Active Directory operation. Any time a client makes a request for
a domain service, it must find a domain controller to service that request, which is where DNS comes in to play.
There are two types of DNS queries: recursive and iterative. When a DNS client requests DNS information, it uses a
recursive query to do so. (And for the purposes of this discussion, a DNS client is any computer requesting DNS
information, even if that computer happens to be running a server operating system.) In a recursive query, the DNS
client sends its query to the first DNS server that it has been configured for in its TCP/IP configuration. It then sits and
waits for the server to return an answer. If the server returns a positive response, the client will then go to the IP
address returned by the server.

If it's a negative response, the client will return some sort of "Page/Resource not found" error to the user. One thing
that's important to note here is that configuring multiple DNS servers on a client will not cause the client to check with
subsequent servers if the first one returns a negative response. The only time a client will go to its secondary DNS
server is if the first one is unavailable. If the first DNS server queried returns a negative response, the client will not
try any secondary servers and will accept that negative response as final.

Adhering to proper DNS settings and best practices is crucial to Active Directory processes, such as replication.

DNS server configuration

DNS is fairly simple and straightforward. As long as you follow the basic rules of configuration, DNS will give you few
problems. However, there are certain complex configurations that are important to know about and remember
when configuring DNS servers, which can allow administrators to get a better handle on options that can make a
difference in DNS operation, logging and troubleshooting.

One of the first things to figure out when learning DNS in Active Directory is knowing if a property is that of the DNS
server or a zone. Both are exposed in the DNS Management snap-in tool.

Here are a couple of ways to keep them straight:

1. Server properties are general properties that apply to the whole DNS environment, such
as Forwarding, Name Servers, root hints and logging.
2. Zone properties are specific properties that vary with the zone, such as dynamic updates,
zone type (AD, Standard Primary or Secondary) and replication type.

DNS structure and design

DNS architecture design is also very important. When designing the DNS structure, it is important to keep in mind
certain principles and practices that will affect the overall name resolution performance in the network. DNS
structures that are patched together or not well thought out will work, but they have pockets of failure that will affect
Active Directory performance. That is why adherence to best practices in the DNS structure is extremely important in
creating an efficient and productive Active Directory.

One key to designing DNS involves the use of Active Directory integrated zones(ADI). An ADI zone is a writeable
copy of a forward lookup zone that is hosted on a domain controller. This is a requirement since the DNS records are
all held in Active Directory, thus the DNS server needs access to the AD. Since each DC hosts a writeable copy of
the DNS zone, clients (workstations, servers and other DCs) can register their DNS records on a domain controller
hosting an ADI primary zone -- usually the DC that authenticated them -- rather than search the network to find a
single DNS server (primary) that will add the client's host and resource records.

So how is a DNS structure using Active Directory integrated zones designed? ADI zones can only be hosted on DCs.
However, many administrators want to put domain name servers in remote sites to provide better name-resolution
performance and to decrease network traffic. That way, users don't have to go across the WAN to find a DNS server.
However, an administrator may not want to put a DC in that location. Windows 2000 Server and Windows Server
2003 allow admins to put a standard secondary zone (read only) on a member server and use one of the ADI primary
servers as the master.

The rule is that an ADI primary zone can only exist on a DC, but admins can have a standard secondary of that zone
on a member server. Thus, clients can connect to their local DNS server whether it is hosting the ADI primary or the
secondary. When a client (DC, member server or workstation) tries to register, however, it can only register on a DNS
server hosting the ADI primary zone. If the client points to a server hosting a secondary, the client will simply receive
a referral to one of the primaries to be registered.

Protecting DNS

DNS security is a major priority. Many of the functions and features of Active Directory use DNS to locate domain
controllers, systems, services, clients, and other objects. It should be obvious that protecting DNS is almost as
important as protecting Active Directory itself. Basically, if DNS fails, so does Active Directory. This, in turn, means
that if DNS fails, an entire network may be disabled.

Providing protection for DNS as a means to provide additional protection for AD DCs is an essential part of
establishing a truly secure networking environment. Protecting your DNS servers will require a multi-pronged
approach. First and foremost, establish the same secure design, implementation and deployment procedures for your
DNS servers as I've recommended for your AD DCs.

Next, consider implementing secured communications with DNS servers, monitor all network traffic, and re-evaluate
the open ports on your firewall. By encrypting all communications between DNS servers and all DNS clients (which
includes not just end user clients but also Active Directory DCs and member servers), it will minimize or eliminate the
possibility of traffic interception and manipulation. One of the best ways to implement this is through IPSec, which is
is a framework for a set of protocols for security at the network or packet processing layer of network communication.

Note: While the implementation of IPSec across all systems will likely cause a measurable decrease in the
performance of network communications due to the overhead of encrypting and decrypting communications, many
experts feel the increased security should more than compensate for the slight reduction in throughput.
It is also important to monitor all network traffic and re-evaluate the open ports on your firewall. By monitoring network
traffic, admins should be able to determine when illegitimate or abnormal traffic patterns or content begin to enter
their network.

Even with all recommended precautions in place, however, there is still a possibility of a malicious person gaining
access to a DNS server. If that happens, admins must rely upon internal DNS security precautions, which include:

 Secure dynamic updates

 DNS resource record registration quotas
 Delegate DNS administration
 Use secured routing
 Maintain a split DNS namespace
 Disable recursion

Troubleshooting DNS

DNS troubleshooting is an absolutely vital process in Active Directory. It is important to keep DNS healthy and to
know how to repair it when it breaks.

This article reviews some of the common DNS problems and the tools to use forDNS troubleshooting .

Avoiding Active Directory security breaches

The importance of protecting your Active Directory has already been touched on in reference to DNS security.
However, that is just the tip of the iceberg when it comes to maintaining a secure environment.

As far as Active Directory security best practices go, layered security is the best method to use when planning and
designing a security solution. Layered security or defense in depth is the simple concept of placing your valued
assets at the center of your environment and building or deploying multiple concentric circles or rings of protection
around those assets. Thus, violations to confidentiality, integrity, or availability must overcome numerous security
restrictions, precautions, and protections before being able to affect your assets.
While Microsoft has increased the default security within Active Directory (especially if you have a Windows Server
2003 Active Directory installation), you still need to consider additional security settings after it is installed.

Securing your domain controllers

One of the first steps you should take involves developing a solid domain controller security policy. Protecting your
domain controllers is at the core of protecting your Active Directory investment. Without your domain controllers you
won't have your Active Directory network infrastructure. With exposed and unprotected domain controllers you also
are at risk for attackers to enumerate shared folders and usernames, giving up valuable information that can be used
to further attack the network.

Therefore, it is critical that domain controllers are running and protected in order for the Active Directory environment
to remain functioning and stable. To protect domain controllers, you should consider the following areas of security
protection:physical access (keeping DCs in a secure location that is only accessible by the IT staff) and network
access (protecting DCs from those who might attack your network).

As an administrator, you need to be concerned with making sure internal users have proper access and that potential
intruders are frustrated in their attempts to compromise a DC. One danger is for a person to be physically in the
room and touch a DC even without any rights granted to them. Thus, if a person has physical access, he or she owns
your computer, since physical access grants them control. Keeping DCs in a secure location is a simple way to
ensure Active Direcotry security, but it is often overlooked.

As far as network access is concerned, it is important not to give domain admin privileges to someone who isn't
skilled enough to handle the job or to someone you're not sure you can trust. Anyone with the ability to install/modify
system files, including services/drivers (such as server operators, backup operators or print operators) owns your
computer. There are many ways for this to happen. Naturally, a secure account could be compromised, giving the
intruder the rights to do this, but a valid holder of these rights could cause harm unintentionally by installing an
application without testing it first.

How well you handle Microsoft patch emergencies and updates is also key to the security of your DCs. You should
always deploy the same patches on all domain controllers. DCs should be kept as close to mirror images of each
other as possible, at least in terms of the OS configuration. This will help eliminate incompatibilities, lost or corrupted
data and replication errors.

However, it is important not to patch just because Microsoft offers a patch. Every patch needs to be tested in your
environment for relevance and reliability. If you don't need it, don't install it. Patches can damage your environment if
the install fails to perform perfectly. You don't want to place your DCs at risk if you can avoid it.

Kerberos security with Microsoft

With the inception of Windows 2000, Microsoft adopted Kerberos as an authentication protocol. Not only was it much
more secure and efficient than NTLM (which was used prior), but it also plays nicely with other operating systems
such as Unix.

Before learning how Kerberos works in the world of Windows, it's best to first understand normal Kerberos
authentication and authorization.

Authentication is the process of presenting credentials (username/password) to a service and having that service
validate you. It works like this. When a user enters his or her username/password in a Kerberos environment, that
information is sent to a server running the Authentication Service. The Authentication Service passes that information
to a database called the Key Distribution Center (KDC). If the username/password checks out, the Authentication
Service sends a Ticket Granting Ticket (TGT) to the client, allowing the client to complete the logon process. The
TGT contains a time stamp, the public key and a certificate.

Authorization is the process of granting access to resources on a server that is in the network. Continuing from the
authentication discussion, once the client gets the TGT, the client can then request access to resources. The TGT is
presented to the Ticket Granting Service and requests a session ticket to access a resource on, say, Server 1. If
Server 1 is in the domain, the Ticket Granting Service sees that there is a valid TGT, so credentials check out, and a
session ticket is granted for Server 1. The client then presents the session ticket to Server 1 for access to a resource
such as a printer, file share or document. Server 1 will then check access rights on that resource to see what the user
can do (read, write, etc.).

In a Windows domain, all of the Kerberos-related services just described are held by each domain controller. When a
user presents credentials for authentication in a Windows domain, the same Kerberos authentication process
described above is used -- with one exception. In order to find a domain controller that is also the KDC, a client must
use the DC Locator process, which requires a DNS server to locate an appropriate DC and send that information
back to the client. The client then passes the credentials to the domain controller, which grants the TGT and then a
session ticket if the server to be accessed is in the DC's domain. The access rights are checked by the server and
granted to the client.

Group Policy security settings

One of the most important steps toward Active Directory security involves Group Policy security settings. With almost
1,800 policy settings in a single Group Policy Object (GPO), it is no wonder they provide so much power, control,
security, and management over an Active Directory enterprise.

There are two default GPOs in every Active Directory domain. These default GPOs are there for very distinct reasons
and should be investigated to ensure they are configured properly to provide the best security for your company
network. The first default GPO is the Default Domain Policy. This GPO is responsible for establishing and maintaining
the account policies for the domain user accounts, which are essential for helping secure the domain user account
passwords.

The second default GPO is the Default Domain Controller Policy. This GPO is responsible for establishing the
baseline security for all domain controllers in the domain. The primary security settings that are established in the
GPO are the user rights. Common user rights include:

 Allowing a user to logon using the keyboard attached to the computer (locally)
 Changing the system time
 Backing up files and folders
 Accessing the computer and its resources over a network
However, every network running Active Directory should have more than just the default two GPOs. The reason is
that Group Policy provides an automated, centralized method for configuring and deploying security settings to all
computers and users within the domain. Some common security related settings and areas of configuration include
the ability to restrict which applications can be run on each computer, use IP Security to encrypt data between
computers, restrict anonymous connections to computers and audit policy settings per computer.

Remember that there are several network security attacks that can be easily avoided with Group Policy, including
simple steps for Kerberos configuration, so be sure to take advantage.

Differences in Active Directory for Windows 2000 and Windows 2003

For the new features and improvements that were built into Windows Server 2003's Active Directory, Microsoft
focused on five areas:

1. Integration and productivity

2. Performance and scalability
3. Administration and configuration management
4. Group Policy
5. Security

Some changes in the areas of integration and productivity include the abilities to edit multiple Active Directory objects
simultaneously, as well as improved interoperability via inetOrgPerson for Novell and Netscape solutions. Replication
monitoring was also improved for Windows Server 2003. In particular, a replication enhancement called linked-value
replication for objects such as Active Directory group objects was significant, especially for large environments.
Linked-value replication solved problems such as inconsistent replication and delays by replicating multi-valued
attributes separately.
As far as performance and scalability goes, Microsoft eliminated the need to contact a global catalog (GC) server
each time a user logs in. For Windows Server 2003, the GC information is cached at the local domain controller.
Other enhancements include support for clustered virtual servers, DC overload prevention and GC replication tuning
controls.

For better configuration management, Microsoft added automated DNS zone creation, improved inter-site replication
and the ability to rename domains. Better migration and command-line tools were also created for Windows Server
2003 Active Directory. Some of the new command-line tools include:

 dsadd -- Allows you to create objects from the command line

 dsmove -- Moves an object from one OU or container to another within the same domain
 dsrm -- Will delete an object from Active Directory
 dsquery -- Will return an object or list of objects that matches criteria that you specify
 dsget -- Will return one or more attributes of a particular Active Directory object
As for Group Policy, Windows Server 2003 greatly improved the Group Policy management interface, which is able to
interact with both 2003 and 2000 GPOs. Other improvements included GPO results reports, over 150 new GPO
controls and improved client management features. New security features included forest trusts, trusted
namespaces, cross-forest authentication and authorization, and a credential manager.

Other changes to Active Directory for Windows Server 2003 include the "Install from Media" option for promoting new
domain controllers into a domain, and the Users and Computers MMC snap-in which allows admins to move an
object from one location in the directory tree to another more easily.

Active Directory improvements with Windows Server 2003 SP1

Several changes in Windows Server 2003 Service Pack 1 have to do with the way Active Directory
handles "tombstoned" objects. Just like in Windows 2000, when you delete an Active Directory object, it is not
immediately deleted; instead, it's marked as a tombstoned object. This allows the deletion to be replicated properly to
other domain controllers. Once an object has been in this tombstoned state for a certain amount of time, it is finally
deleted outright.

In Windows 2000, the default tombstone lifetime was 60 days. However, in Windows Server 2003, Microsoft changed
it to 180 days, effectively tripling the amount of time that a deletion had to be communicated to all of the domain
controllers in an environment. However, if you have already installed Active Directory using either Windows 2000 or
the original Windows Server 2003 media, the default tombstone lifetime will not automatically change when you
upgrade to Windows Server 2003 SP1. You will only receive the 180-day tombstone lifetime value automatically by
building a pristine 2003 SP1 Active Directory forest.

In addition to modifying the tombstone lifetime for new Active Directory installations, 2003 Service Pack 1 added the
SID History attribute to the list of attributes that are retained when an object is tombstoned. When an Active Directory
object is tombstoned, it is stripped of most of its attributes, so the tombstoned object only takes up a fraction of the
size of the original object within the Active Directory database. Each user, group and computer object within Active
Directory is assigned a numeric security identifier, or SID. SIDs are unique within the domain and do not change,
even if the security principal is renamed or moved to another container within the same domain.

Prior to Windows Server 2003 SP1, one of the attributes that was stripped when an object was tombstoned was this
SID History attribute, which meant that if you restored an object, any previous SIDs that were recorded in its SID
History were lost. Fortunately, Windows Server 2003 SP1 includes SID History among the attributes retained when
an object is deleted.

Service Pack 1 also made changes in the types of Active Directory information that are logged in the Event Viewer on
a domain controller, thus allowing for more proactive monitoring and easier troubleshooting. One such update is
Event ID 2089, which is recorded in the Directory Service event log if any directory partition has not been backed up
for a significant length of time (half of the tombstone lifetime or more). The event is logged whether the partition is the
Schema, Configuration, or domain partitions -- or any application partitions or ADAM partitions that are hosted on the
DC in question.
Ever since SP1, administrators can also now run domain controllers using virtualization technology such as Microsoft
Virtual Server 2005. That allows you to run multiple domains or forests on a single machine or to use virtualization to
reduce the attack footprint of a physical server by separating its roles onto multiple virtual machines.

Changes to Active Directory for Windows Server 2008

Once again, many changes to Active Directory were made with Windows Server 2008. Microsoft has incorporated
two very significant features with Windows Server 2008 that will probably relate to most Active Directory
deployments: the read-only domain controller (RODC) and server roles.

The read-only domain controller is perhaps the marquee feature for Active Directory in Windows Server 2008. The
RODC hosts a read-only copy of the Active Directory database. That is, you can't make any changes to the Active
Directory database from a read-only domain controller. You can connect to an RODC to read any information you like
(with a few exceptions, which we'll get to in a moment), but you will not be able to perform any write operations
without connecting to or being referred to a writeable domain controller.

Also with RODC, the administrator can determine which accounts will be replicated to the domain controller, and
replication is unidirectional. RODC doesnot perform any outbound replication. This is a fundamental change from the
typical multi-master replication model that many have become familiar with in Active Directory. In Windows 2000
Server and Windows Server 2003, an administrator can connect to any domain controller to make a change, and that
change will be replicated out to the rest of Active Directory via outbound replication from the DC that the change
originated from.

This is not so with the RODC. The read-only domain controller will receive inbound replication from other writeable
Windows Server 2008 DCs, but it will not replicate any information whatsoever out to other DCs. This solves a lot of
security issues at remote sites since it will minimize accounts exposed at the site (presumably not any admin
accounts), and anything compromised at the site will not make it out of the site. Combined with the new BitLocker
technology, RODC will allow deployment of DCs at smaller sites where it was not feasible before.

Server Core was also developed for Windows Server 2008 as a response to customer requests to provide a lean
server operating system that would permit specific server functions to run without all the overhead of the GUI. It has
been referred to by Microsoft as a bare bones installation of Windows Server 2008.

With Server Core, after logon, a user will be presented with a desktop with no start menu, taskbar or icons, and two
command windows. Installation of roles such as Dynamic Host Configuration Protocol (DHCP), DNS, file services and
print server will be done completely from the command line. However, this environment will still allow users to open
applications such as Event Viewer, notepad and others. In addition to making the server better defined for
administrative purposes and reducing the hardware resources required, Server Core also permits better security at
remote sites, allowing a smaller footprint of exposure.

Other changes include the Restartable Active Directory, which allows AD to be restarted without rebooting the server.
You can accomplish this via the command line and MMC Snap-ins. It is designed to save admins time on offline
operations (like an offline defrag of Active Directory) without taking the server offline and shutting down other services
and applications.

The basics of Active Directory planning

When you are performing an Active Directory migration, you basically have two options: domain upgrading or domain
restructuring. Domain upgrading is little more than upgrading each existing Windows domain controller to a more
current Windows domain controller. The upgrade process starts by upgrading the PDCs in each domain, followed by
the BDCs. Domain restructuring involves creating an Active Directory network from scratch. In a restructure, you will
move systems and reroute connections to comply with a new infrastructure and layout design. Often restructuring will
result in fewer but larger domains.

So the question becomes, "Should you upgrade or restructure?"

Deciding which path to take, or which process to perform first, all depends on your specific situation. But there are a
few guidelines that can help you make the choice.
First, if your current domain structure is supporting your work tasks and doesn't seem to involve an inordinate amount
of extraneous administration, then upgrading may be preferable. However, if the current domain structure is not
adequate and is the primary motivation for the migration, restructuring is likely the way to go. Secondly, if you must
support the production environment throughout the migration process, upgrading will retain overall network
functionality and therefore is preferable. But if you can afford to lose productivity during the migration, restructuring is
better. However, restructuring can be performed on a staggered schedule so no significant loss of productivity is
noticed.

Rememeber that while upgrading will cause the least downtime in terms of getting the domain back into working
order, it often is an insufficient migration. Many of the benefits of Windows 2000 and Windows 2003-based Active
Directory domains cannot be fully realized without reconfiguring the design of your network. Restructuring will require
significant work to implement, but it makes reaping the benefits of Active Directory easier to exploit for your
organization.

Developing an Active Directory migration strategy

When taking on an Active Directory migration project, like with all large projects, it's best to have a strategy in place. It
is key to create an Active Directory migration checklist, with steps such as collecting diagrams and configuration of
the current DNS and network structure (bandwidth, remote locations, stability, etc.), determining the rights, objects
and policies that will need to be migrated, and creating fall back procedures in case of failure.

Another part of developing your migration strategy, is being aware of the key things you should and should not do
when performing an Active Directory migration.

For starters , it's important to make sure that your support staff is brought up to speed before you begin migrating any
production system. Depending on the size and structure of your organization, you should have a help desk staff
taking support calls. For a complex project like Active Directory, it's a good idea to make a couple of network
engineers available as well. Be sure to train all members of the support staff involved in the process. Otherwise, you'll
have IT staff fielding questions that they don't know how to answer, and frustration will abound on all sides.

You should also establish a test bed that mimics your production environment as closely as possible in terms of
hardware specifications and network speed. Leave nothing to chance in the testing phase. Speaking of testing, be
sure to test name resolution and replication before deploying Active Directory in production. Unlike replication under
NT4, Active Directory replication is possibly the single most important item required for AD to function correctly.
Second only to file replication for a solid Active Directory implementation is name resolution. Whether you are
deploying WINS or DNS, ensure that all systems that need to can effectively talk to one another.

Designing Active Directory simply

Active Directory is very flexible. So flexible that you can design an Active Directory forest that is complex beyond
imagination. Both Windows 2000 Server and Windows Server 2003 support the Active Directory containers of forest,
domain, site, and organizational unit (OU). With the only real restriction of one forest per namespace, you can deploy
as many domains, sites, and OUs as you deem necessary.

However, don't be so fast to rush off and design an Active Directory network that includes a domain for every
department in your enterprise. The key to Active Directory design is simplicity. As a general rule, you want to keep
the number of domains to a minimum whenever possible. If you really need department level divisions on your
network that reflect the organization of your business, then use OUs instead. OUs are much more flexible and easier
overall to manage than domains.

If you are migrating from a Windows NT 4.0 network to a Windows 2000 Server or Windows Server 2003 Active
Directory network, compare the number of domains from your existing legacy system and compare that with the
number of domains in your new AD-based design. If your new Active Directory network has more domains than your
legacy network, you may need to re-think your design. Yes, it is possible to use as many domains as you wish, but
you'll likely regret that decision down the line. If you need lots of groupings and divisions, it is best to rely upon OUs.

Active Directory domain design

When you are designing your Active Directory network, it is important to use the four divisions (forests, domains,
organizational units, and sites) to their maximum potential. This is especially true for Active Directory domain design.

Domain divisions are most often used as logical containers. However, Microsoft recommends that you employ
domains also as physical containers. In other words, create domains whose members are all geographically close
rather than distant. This is an important design aspect since the level of traffic within a domain is considerably higher
than that between one domain and another. In general, a domain with limited physical size is less likely to include
expensive WAN links or pay-per-bit connections. When slow links must be included in a network design, it is often
beneficial to create multiple domains connected by the slower connections.

Remember that it is not necessary to create separate domains to divide administrative privileges. Within Active
Directory, it is possible to delegate administrative privileges based on organizational units.

Designing groups and organizational units

With the proper preparation and advance knowledge of their use, a functionalorganizational unit (OU) and group
design can do wonders to simplify your Active Directory environment. It can also go a long way toward helping you
gain control and reduce overhead.

Often, OUs are indiscriminately used without reason, and group structure is ineffectual and confusing. Without some
form of logical organization of users within your network environment, chaos reigns and administration grinds to a
halt. Some best practices when designing OUs include:

 Keep the OU structure as simple as possible

 Do not nest OUs more than 10 layers deep
 Keep the number of OUs to a minimum
 Apply Group Policy to groups through Group Policy filtering
 Don't utilize local groups for permissions in a domain environment
 Use domain local groups to control access to resources, and use global groups to organize similar groups of
users.
You also have the option of hiding your OUs. The primary purpose of hidden OUs is to prevent an administrator from
one OU from being able to view, access, or alter another OU. Hidden OUs are often used in environments that offer
network application services to internal departments or external customers. It allows for a solid separation of duties
without requiring separate domains or forests.

Design rules for Active Directory sites

Sites are an extremely useful design element for Active Directory domains. Sites are limited to any computer object
within a forest. Thus, they can cross domains and organizational units (OUs) with indifference. An object's
membership in a domain or OU does not exclude simultaneous membership in a site. Sites are used to impose
physical network divisions for the purpose of traffic flow.

By using sites, you can control and reduce the amount of traffic that flows over your slower WAN links. This can result
in more efficient traffic flow for productivity tasks. It can also serve to keep WAN link costs down on the pay-by-the-bit
services.

In general, when designing sites, keep the following in mind:

 Sites should generally reflect the physical or geographic topology of the network.
 Each site should contain at least one local DC.
 Sites should not contain slow links of any type.
 Remote-access clients do not need a dedicated site.
 Sites should be used whenever control over replication traffic is needed or desired.
 Sites can be added, removed, changed, and moved easily without affecting any other AD container configuration.
Active Directory Hierarchies
Now that you understand the building blocks of Active Directory, you can start to
understand how to build a hierarchy in Active Directory. One of the foundations of
design for AD has been a flexibility to allow companies to build a structure which fits
into their organization. This flexibility allows organizations of all sizes to use Active
Directory to meet their needs.

Domains and OUs

The most basic design of an Active Directory is a single forest, single domain, no
Organizational Unit design.

Basic AD Installation
For a small organization, this might be adequate, but almost every organization can
benefit from some structure.
Creating multiple domains is not always the best design solution, so Microsoft
created organizational units in Active Directory which can be nested to provide
hierarchical control of your AD environment. It is a great idea to think about and map
out your OU design before committing it into Active Directory.

Typically, companies design their OU trees based on either geographic separation (e.g.
Americas, EMEA, PacificRim) or based on organizational design (e.g. Accounting,
Marketing, Technology, Sales). There is no incorrect way to design your AD
environment, however, consistency should be key. You shouldn’t mix the two design
methods and have a top level Americas OU and a top level Sales OU. Doing so makes
administration difficult as you won’t know where a particular salesperson’s account is.
Also, remember that OUs allow enterprise administrators to delegate administration
responsibility to local teams. Building an effective OU design will allow you to properly
delegate authority.
The other reason OUs are used is to apply policies. Policies are rules for security,
access, and functionality which can apply to several different containers in Active
Directory. Frequently, policies are applied by OU – so though you might separated
geographically (and therefore want to set up your structure based solely on
geography), it might make more sense to setup your AD by organizational divisions.
Why? Because if all of your marketing employees need the same software and settings,
you will setup policies based on the department instead of the physical location of the
employees.
Domain Trees
Once an organization becomes large and you cannot have the entire AD database
replicated everywhere, it might make sense to move to a domain tree. A domain tree
allows an organization to become more decentralized as it is more independent than
using an OU tree.
Domain-wide policies can be changed per domain in a domain tree which is not possible
with only an OU structure. Policies such as minimum and maximum password age,
minimum password length, and account lockout are domain-wide policies and cannot be
changed on a per-OU basis. By creating multiple domains, administrators can set these
policies for each domain.

Domain Tree
In the illustration above, learnthat.com has a domain tree in the Active Directory
domain.

Forest of Domain Trees

In more complex environments, a company may use multiple domain trees in a single
forest. This might be a large operating company with multiple subsidiaries – each
requiring their own domain, for example, ThatNetwork.com is the parent company and
subsidiaries might include Learnthat.com, Romancetips.com, Exampractice.com. This
structure makes sense if you have different administrative staff for each domain, along
with different policies and different security requirements.
You can still setup trusts between the domains to allow users to authenticate for
resources in either domain.

Multiple Forests
The last possibility is using multiple forests. This is the less frequent design choice, but
can be used with you want an absolute separation for one reason or another. This
structure is most often found when companies merge or in the case of acquisitions. In
Windows 2003, you can setup forest trusts between forests to allow some access.

Active Directory Installation

Some larger organizations take months (and in some cases, over a year) to plan a
proper Active Directory design and get input from a global organization of technology
leaders. It is extremely important to give a lot of thought to your AD design to ensure it
meets your organization’s needs.

Choosing Your AD Layout

As we mentioned earlier, there are many ways you can structure your Active Directory.
From a top level down perspective, most companies either start with a geographic
separation or a organizational structure separation, for example Americas, EMEA,
PacificRIM for geographic or Accounting, Marketing, Technology, Sales for
organizational structure. It does not matter which you select: either will provide a fine
starting point for your domain structure, but you need to ensure you pick one direction
and be consistent with your choices.
Many organizations start with geography at the top level, then break down into
business units or departments underneath that top level. It is important to write
naming conventions and standards down so a team in Europe does not call an OU
“SalesMarketing” while a team in North America calls an OU “Sales.” Consistency
provides for an efficient and manageable Active Directory layout.
There are many different combinations you could choose when designing your AD
structure.
Installation Requirements
In this section, we will look at the installation requirements of Active Directory.
Installing AD isn’t a complex process, but the design and configuration can be.
Here are the requirements for installing Active Directory on Windows Server 2003:
• An NTFS partition with enough free space
• An Administrator's username and password
• NIC with Network Connection
• Properly configured TCP/IP (IP address, subnet mask and - optional -
default gateway)
• An operational DNS server (which can be installed on the DC itself)
• A Domain name that you want to use
• Windows Server 2003 CD media or the i386 Folder
Functional Levels
In Windows 2000, you chose from two levels: mixed mode or native mode. When
Windows 2000 Server was introduced, NT 4 was still a popular server option. To ensure
backward compatibility with these servers and clients, Windows 2000 defaulted to
mixed mode where you could add Windows NT 4 servers to the Windows 2000 Active
Directory domain.
Windows Server 2003 introduced functional levels - a set level of backward
compatibility for previous operating systems. If you are in an environment with NT 4
servers and Windows 2000 servers which are still accessed, you can set a functional
level to ensure backwards compatibility.
Windows 2003 expands from those two modes to one of many domain functional levels
including Windows 2000 Mixed, Windows 2000 Native, Windows Server 2003 Interim,
and Windows Server 2003. Also, in Windows Server 2003, you have three forest
functional levels available: Windows 2000, Windows Server 2003 Interim, or Windows
server 2003. Each functional level brings new features available and lose compatibility
with some set of servers or clients.
By default, Windows Server 2003 starts at Windows 2000 Mixed functional level. Not all
of the features of 2003 are available in this mode, so if you are designing a new
Windows 2003 AD environment, you will want to take advantage of the new features
added in Windows Server 2003.
In Windows 2000, we referred to this change as “changing the mode,” but in Windows
2003, we now raise the functional level with either Active Directory Users and
Computers or Domains and Trusts.

This change cannot be reversed – once you make a decision to raise the functional
level, you cannot go back to a lower functional level.

Installing Active Directory

Please note: these installation instructions are for a brand new domain – not for adding
a server as a member server or domain controller in an existing domain. Following
these instructions in a production network is not recommended.
We are going to review the AD installation process from a clean install of Windows
Server 2003. You may have already set some of these settings, so look through the
steps and perform any tasks you have failed to do.
Set Network Settings
1. This server will be both a domain controller and a DNS server, so we are going
to set a static IP address.
2. Click Start, Control Panel, Network Connections and select your network
connection.
3. Click Properties.

4. Click Internet Protocol (TCP/IP) and click Properties.

5. Enter in your static IP address information and preferred DNS servers. Notice
one of the DNS servers I listed is the server itself – this will be a DNS server in a
minute.
6. Click OK.
7. Click Close.
8. Click Close.
9. Click Start. Right-click on My Computer and select Properties.
10. Click on the Computer Name tab.
11. Click on the More button.
12. Enter in the domain name you are going to be using for your AD domain in
the Primary DNS suffix of this computer text field.
13. Click OK.
14. Click OK. Acknowledge that you have to reboot and click OK.
15. Click Yes to the prompt asking you if you want to reboot.
Install the DNS Service

16. On the Manage Your Server window, select Add or remove a role. (Don’t see
this window at startup? Find it at Start > All Programs > Administrative Tools >
Manage Server)
17. Click Next.

18. Click DNS Server and click Next.

19. Click Next.
20. Insert your Windows Server 2003 setup cd and click OK.
21. Navigate to where the i386 folder is and click OK.
22. Click Next to start the DNS wizard.

23. Click Next to create a forward lookup zone.

24. Click Next that this server retains a the zone.
25. Name your zone with your domain name. Click Next.
26. Accept the default filename and click Next.
27. Click Allow both nonsecure and secure dynamic updates. Click Next.
28. Select whether or not this DNS server should forward queries. If you use an ISP
for DNS resolution for Internet sites, enter in your ISP’s DNS servers in the first option.
If this DNS server will resolve all queries, select the second option. Click Next.
29. Click Finish.
30. Click Finish.
31. Congratulations! You have setup a DNS server!

Setting Up Active Directory

32. On the Manage Your Server window, click Add or remove a role.
33. Click Next.
34. Select Domain Controller (Active Directory) and click Next.
35. Click Next.
36. Click Next when the Active Directory wizard opens.
37. Click Next.

38. Click Next.

39. Click Next.

40. Enter in your domain name and click Next.

41. Enter in a NetBIOS name or accept the default and click Next.
42. Click Next to accept the default locations for the database and log, or select a
location for these files.
43. Enter a location for the Shared System Volume and click Next.
44. Click Next.

45. Click Next.

46. Enter in a password and click Next.

47. Click Next.
48. The wizard will configure Active Directory.
49. Click Finish to complete the wizard.
50. Click Restart Now.
Congratulations, you have now completed the Active Directory wizard and AD is
installed.

Creating Organizational Units (OUs)

Creating Organizational Units
As we discussed earlier, Organizational Units provide a mechanism to design a
hierarchical structure within your Active Directory environment. Once you have
designed your AD structure, you are ready to create the OUs in the environment.
1. Click Start > Administrative Tools > Active Directory Users and
Computers.
2. Double-click the domain name to open it up.
3. You will see a default structure with no Organizational Units. Right-click on the
domain nameand select New > Organizational Unit.

4. Enter the name of the OU you want to create and click OK.
5. You will now see the OU you just created. Continue the process and build out the
top level OUs.
6. You now have a structure from which to build your organizational structure. For
a small organization, we would create a Users and Computers organizational unit under
each of the top level OUs.
7. Right-click on Accounting and select New > Organizational Unit and enter
in Computers. Click OK. Repeat this process for the Users OU.
8. Now repeat the process for each department and you will have a structure of
OUs created.

Post Active Directory Installation

There are several steps you should do after the Active Directory installation to ensure
installation went correctly and make sure AD operates properly in your environment.
Verify Installation
First, you can ensure the AD tools are installed. Click on Start and
click Administrative Tools. You should have these tools installed:
Next, open Active Directory Sites and Services. You should have a Default-First-
Site-Name listed and when you open it up, you should find your domain controller listed
as a server.
Finally, open up DNS management. Open up the DNS server name, the Forward Lookup
Zones, the domain name, and _tcp. It should look like this with four SRV records:

Once you’ve performed these tasks, you’ve confirmed that your AD environment is
installed.
Management Utilities
There are several management utilities you use to manage the Active Directory
environment. As you saw after installation, you have these utilities (which are MMC
snap-ins):
Active Directory Domains and Trusts: Manage domains and trusts between domains
using this tool.
Active Directory Sites and Services: Setup and manage sites (physical networks).
Active Directory Users and Computers: Create and manage users, computers, other
objects, OUs.
In later Active Directory tutorials, you will learn more about these tools and how to use
them.