Active Directory

From Wikipedia, the free encyclopedia

in most Windows Server operating systems as a set ofprocesses and services.[1][2]

An AD domain controller authenticates and authorizes all the users and computers in a Windows domain type
networkassigning and enforcing security policies for all computers and installing or updating software. For
example, when a user logs into a computer that is part of a Windows domain, Active Directory checks the submitted
password and determines whether the user is a system administrator or normal user.[3]

Active Directory makes use of Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Microsoft's version
of Kerberos, and DNS.

Contents
[hide]

1 History

2 Logical Structure

2.1 Objects

2.2 Forests, trees, and domains

2.3 Partitions

3 Physical structure

3.1 Replication

4 Implementation

5 Database

6 Single server operations

7 Trusting

7.1 Terminology

8 Active Directory management solutions

1
History[edit]
Active Directory, like many information-technology efforts, originated out of a democratization of
design using Request for Comments or RFCs. The Internet Engineering Task Force (IETF), which oversees the
RFC process, has accepted numerous RFCs initiated by widespread participants. Active Directory incorporates
decades of communication technologies into the overarching Active Directory concept then makes improvements
upon them.[citation needed]

For example, Lightweight Directory Access Protocol (LDAP), a long-standing directory technology, underpins Active
Directory. Also X.500 directories and the Organizational Unitpreceded the Active Directory concept that makes use
of those methods. The LDAP concept began to emerge even before the founding of Microsoft in April 1975, with
RFCs as early as 1971. RFCs contributing to LDAP include RFC 1823 (on the LDAP API, August 1995),[4] RFC
2307, RFC 3062, and RFC 4533.[citation needed]

Microsoft previewed Active Directory in 1999, released it first with Windows 2000 Server edition, and revised it to
extend functionality and improve administration in Windows Server 2003. Additional improvements came
with Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2. With the release of the last,
Microsoft renamed the domain controller role (see below) as Active Directory Domain Services (AD DS). It is also
included in Windows Server 2012 and Windows Server 2012 R2.

Logical Structure[edit]
As a directory service, an Active Directory instance consists of a database and corresponding executable
code responsible for servicing requests and maintaining the database. The executable part, known as Directory
System Agent, is a collection of Windows services and processes that run on Windows 2000 and later.[1] Objects in
Active Directory databases can be accessed via LDAP, ADSI (a component object model interface), messaging
API and Security Accounts Manager services.[2]

Objects[edit]

A simplified example of a publishing company's internal network. The company has four groups with varying permissions to the
three shared folders on the network.

2
An Active Directory Structure is an arrangement of information about objects. The objects fall into two broad
categories: resources (e.g., printers) and security principals (user or computer accounts and groups). Security
principals are assigned unique security identifiers(SIDs).

Each object represents a single entitywhether a user, a computer, a printer, or a groupand its attributes. Certain
objects can contain other objects. An object is uniquely identified by its name and has a set of attributesthe
characteristics and information that the object represents defined by a schema, which also determines the kinds
of objects that can be stored in Active Directory.

The schema object lets administrators extend or modify the schema when necessary. However, because each
schema object is integral to the definition of Active Directory objects, deactivating or changing these objects can
fundamentally change or disrupt a deployment. Schema changes automatically propagate throughout the system.
Once created, an object can only be deactivatednot deleted. Changing the schema usually requires planning. [5]

Forests, trees, and domains[edit]

The Active Directory framework that holds the objects can be viewed at a number of levels. The forest, tree, and
domain are the logical divisions in an Active Directory network.

Within a deployment, objects are grouped into domains. The objects for a single domain are stored in a single
database (which can be replicated). Domains are identified by theirDNS name structure, the namespace.

A domain is defined as a logical group of network objects (computers, users, devices) that share the same Active
Directory database.

A tree is a collection of one or more domains and domain trees in a contiguous namespace, linked in a transitive
trust hierarchy.

At the top of the structure is the forest. A forest is a collection of trees that share a common global catalog, directory
schema, logical structure, and directory configuration. The forest represents the security boundary within which
users, computers, groups, and other objects are accessible.

Domain-Boston Domain-Dallas

Domain-New Yor OU-Marketing

k

Hewitt
Domain-Philly

Aon
Tree-Southern

Steve
Domain-Atlanta

OU-Sales
Domain-Dallas

3
 Bill

Ralph

Example of the geographical organizing of zones

of interest within trees and domains.

Organizational units[edit]

The objects held within a domain can be grouped into Organizational Units (OUs).[6] OUs can provide hierarchy to a
domain, ease its administration, and can resemble the organization's structure in managerial or geographical terms.
OUs can contain other OUsdomains are containers in this sense. Microsoft recommends using OUs rather than
domains for structure and to simplify the implementation of policies and administration. The OU is the recommended
level at which to apply group policies, which are Active Directory objects formally named Group Policy Objects
(GPOs), although policies can also be applied to domains or sites (see below). The OU is the level at which
administrative powers are commonly delegated, but delegation can be performed on individual objects or attributes
as well.

Organizational units do not each have a separate namespace; e.g. user accounts with an identical username
(sAMAccountName) in separate OUs within a domain are not allowed, such as "fred.staff-ou.domain" and
"fred.student-ou.domain", where "staff-ou" and "student-ou" are the OUs. This is because sAMAccountName, a user
object attribute, must be unique within the domain. [7] However, two users in different OUs can have the same
Common Name (CN), the name under which they are stored in the directory itself.

In general the reason for this lack of allowance for duplicate names through hierarchical directory placement, is that
Microsoft primarily relies on the principles of NetBIOS, which is a flat-file method of network object management that
for Microsoft software, goes all the way back to Windows NT 3.1 and MS-DOS LAN Manager. Allowing for
duplication of object names in the directory, or completely removing the use of NetBIOS names, would prevent
backward compatibility with legacy software and equipment. However, disallowing duplicate object names in this
way is a violation of the LDAP RFCs on which Active Directory is supposedly based.

As the number of users in a domain increases, conventions such as "first initial, middle initial, last name" (Western
order) or the reverse (Eastern order) fail for common family names like Li (), Smith or Garcia. Workarounds
include adding a digit to the end of the username. Alternatives include creating a separate ID system of unique
employee/student id numbers to use as account names in place of actual user's names, and allowing users to
nominate their preferred word sequence within an acceptable use policy.

Because duplicate usernames cannot exist within a domain, account name generation poses a significant challenge
for large organizations that cannot be easily subdivided into separate domains, such as students in a public school
system or university who must be able to use any computer across the network.

4
Shadow groups[edit]

In Active Directory, organizational units cannot be assigned as owners or trustees. Only groups are selectable, and members of
OUs cannot be collectively assigned rights to directory objects.

In Microsoft's Active Directory, OUs do not confer access permissions, and objects placed within OUs are not
automatically assigned access privileges based on their containing OU. This is a design limitation specific to Active
Directory. Other competing directories such as Novell NDS are able to assign access privileges through object
placement within an OU.

Active Directory requires a separate step for an administrator to assign an object in an OU as a member of a group
also within that OU. Relying on OU location alone to determine access permissions is unreliable, because the object
may not have been assigned to the group object for that OU.

A common workaround for an Active Directory administrator is to write a custom PowerShell or Visual Basic script to
automatically create and maintain a user group for each OU in their directory. The scripts are run periodically to
update the group to match the OU's account membership, but are unable to instantly update the security groups
anytime the directory changes, as occurs in competing directories where security is directly implemented into the
directory itself. Such groups are known as Shadow Groups. Once created, these shadow groups are selectable in
place of the OU in the administrative tools.

Microsoft refers to shadow groups in the Server 2008 Reference documentation, but does not explain how to create
them. There are no built-in server methods or console snap-ins for managing shadow groups. [8]

The division of an organization's information infrastructure into a hierarchy of one or more domains and top-level
OUs is a key decision. Common models are by business unit, by geographical location, by IT Service, or by object
type and hybrids of these. OUs should be structured primarily to facilitate administrative delegation, and secondarily,
to facilitate group policy application. Although OUs form an administrative boundary, the only true security boundary
is the forest itself and an administrator of any domain in the forest must be trusted across all domains in the forest. [9]

Partitions[edit]

The Active Directory database is organized in partitions, each holding specific object types and following a specific
replication pattern. Microsoft often refers to these partitions as 'naming contexts'. [10] The 'Schema' partition contains
the definition of object classes and attributes within the Forest. The 'Configuration' partition contains information on
the physical structure and configuration of the forest (such as the site topology). Both replicate to all domains in the
Forest. The 'Domain' partition holds all objects created in that domain and replicates only within its domain.

Physical structure[edit]
Sites are physical (rather than logical) groupings defined by one or more IP subnets.[11] AD also holds the definitions
of connections, distinguishing low-speed (e.g., WAN, VPN) from high-speed (e.g., LAN) links. Site definitions are

5
independent of the domain and OU structure and are common across the forest. Sites are used to control network
traffic generated by replication and also to refer clients to the nearest domain controllers (DCs). Microsoft Exchange
Server 2007 uses the site topology for mail routing. Policies can also be defined at the site level.

Physically, the Active Directory information is held on one or more peer domain controllers, replacing
the NT PDC/BDC model. Each DC has a copy of the Active Directory. Servers joined to Active Directory that are not
domain controllers are called Member Servers.[12] A subset of objects in the domain partition replicate to domain
controllers that are configured as global catalogs. Global catalog (GC) servers provide a global listing of all objects
in the Forest. [13] [14] Global Catalog servers replicate to themselves all objects from all domains and hence, provide a
global listing of objects in the forest. However, to minimize replication traffic and keep the GC's database small, only
selected attributes of each object are replicated. This is called the partial attribute set (PAS). The PAS can be
modified by modifying the schema and marking attributes for replication to the GC. [15]Earlier versions of Windows
used NetBIOS to communicate. Active Directory is fully integrated with DNS and requires TCP/IPDNS. To be fully
functional, the DNS server must support SRV resource records, also known as service records.

Replication[edit]

Active Directory synchronizes changes using multi-master replication.[16] Replication by default is 'pull' rather than
'push', meaning that replicas pull changes from the server where the change was effected. [17] The Knowledge
Consistency Checker (KCC) creates a replication topology of site links using the defined sites to manage traffic.
Intrasite replication is frequent and automatic as a result of change notification, which triggers peers to begin a pull
replication cycle. Intersite replication intervals are typically less frequent and do not use change notification by
default, although this is configurable and can be made identical to intrasite replication.

Each link can have a 'cost' (e.g., DS3, T1, ISDN etc.) and the KCC alters the site link topology accordingly.
Replication may occur transitively through several site links on same-protocol site link bridges, if the cost is low,
although KCC automatically costs a direct site-to-site link lower than transitive connections. Site-to-site replication
can be configured to occur between a bridgehead server in each site, which then replicates the changes to other
DCs within the site. Replication for Active Directory zones is automatically configured when DNS is activated in the
domain based by site.

Replication of Active Directory uses Remote Procedure Calls (RPC) over IP (RPC/IP). Between Sites SMTP can be
used for replication, but only for changes in the Schema, Configuration, or Partial Attribute Set (Global Catalog)
GCs. SMTP cannot be used for replicating the default Domain partition.[18]

Implementation[edit]
In general, a network utilizing Active Directory has more than one licensed Windows server computer. Backup and
restore of Active Directory is possible for a network with a single domain controller,[19] but Microsoft recommends
more than one domain controller to provide automatic failover protection of the directory.[20] Domain controllers are
also ideally single-purpose for directory operations only, and should not run any other software or role. [21]

Certain Microsoft products such as SQL Server[22][23] and Exchange[24] can interfere with the operation of a domain
controller, necessitating isolation of these products on additional Windows servers. Combining them can make
configuration or troubleshooting of either the domain controller or the other installed software more difficult. [25] A
business intending to implement Active Directory is therefore recommended to purchase a number of Windows
server licenses, to provide for at least two separate domain controllers, and optionally, additional domain controllers
for performance or redundancy, a separate file server, a separate Exchange server, a separate SQL Server,[26] and
so forth to support the various server roles.

6
Physical hardware costs for the many separate servers can be reduced through the use of virtualization, although
for proper failover protection, Microsoft recommends not running multiple virtualized domain controllers on the same
physical hardware.[27]

Database[edit]
The Active-Directory database, the directory store, in Windows 2000 Server uses the JET Blue-based Extensible
Storage Engine (ESE98) and is limited to 16 terabytes and 2 billion objects (but only 1 billion security principals) in
each domain controller's database. Microsoft has created NTDS databases with more than 2 billion objects.
[28]
(NT4'sSecurity Account Manager could support no more than 40,000 objects). Called NTDS.DIT, it has two main
tables: the data table and the link table. Windows Server 2003 added a third main table for security descriptor single
instancing.[28]

Programs may access the features of Active Directory[29] via the COM interfaces provided by Active Directory
Service Interfaces.[30]

Single server operations[edit]

Flexible Single Master Operations Roles (FSMO, sometimes pronounced "fizz-mo") operations are also known as
operations master roles. Although domain controllers allow simultaneous updates in multiple places, certain
operations are supported only on a single server. These operations are performed using the roles listed below:

Role name Scope Description

Schema
1 per forest Schema modifications
Master

Domain
Naming 1 per forest Addition and removal of domains if present in root domain
Master

Provides backwards compatibility for NT4 clients for PDC operations

(like password changes). The PDC runs domain specific processes
PDC such as the Security Descriptor Propagator (SDP), and is the master
1 per domain
Emulator time server within the domain. It also handles external trusts, the
DFS consistency check, holds current passwords and manages all
GPOs as default server.

Allocates pools of unique identifiers to domain controllers for use

RID Master 1 per domain
when creating objects

Infrastructur 1 per Synchronizes cross-domain group membership changes. The

e Master domain/partiti infrastructure master should not be run on a global catalog server
on (GCS) unless all DCs are also GCs, or the environment consists of a

7
 single domain.

Trusting[edit]
To allow users in one domain to access resources in another, Active Directory uses trusts. [31]

Trusts inside a forest are automatically created when domains are created. The forest sets the default boundaries of
trust, and implicit, transitive trust is automatic for all domains within a forest.

Terminology[edit]
One-way trust
One domain allows access to users on another domain, but the other domain does not allow access to users
on the first domain.
Two-way trust
Two domains allow access to users on both domains.
Trusted domain
The domain that is trusted; whose users have access to the trusting domain.
Transitive trust
A trust that can extend beyond two domains to other trusted domains in the forest.
Intransitive trust
A one way trust that does not extend beyond two domains.
Explicit trust
A trust that an admin creates. It is not transitive and is one way only.
Cross-link trust
An explicit trust between domains in different trees or in the same tree when a descendant/ancestor
(child/parent) relationship does not exist between the two domains.
Shortcut
Joins two domains in different trees, transitive, one- or two-way.
Forest trust
Applies to the entire forest. Transitive, one- or two-way.
Realm
Can be transitive or nontransitive (intransitive), one- or two-way.
External
Connect to other forests or non-AD domains. Nontransitive, one- or two-way.[32]

[33]

Forest trusts[edit]

Windows Server 2003 introduced the forest root trust. This trust can be used to connect Windows Server 2003
forests if they are operating at the 2003 forest functional level. Authentication across this type of trust is Kerberos-
based (as opposed to NTLM).

Forest trusts are transitive for all the domains within the trusted forests. However, forest trusts
are not transitive between forests.

Example: Suppose that a two-way transitive forest trust exists between the forest root domains in Forest A and
Forest B, and another two-way transitive forest trust exists between the forest root domains in Forest B and Forest

8
C. Such a configuration lets users in Forest B access resources in any domain in either Forest A or Forest C, and
users in Forest A or C can access resources in any domain in Forest B. However, it does not let users in Forest A
access resources in Forest C, or vice versa. To let users in Forest A and Forest C share resources, a two-way
transitive trust must exist between both forests.

Active Directory management solutions[edit]

Microsoft Active Directory management tools include:

Active Directory Users and Computers,

Active Directory Domains and Trusts,

Active Directory Sites and Services,

ADSI Edit,

Local Users and Groups,

Active Directory Schema snap-ins for Microsoft Management Console (MMC),

These management tools may not provide enough functionality for efficient workflow in large environments.
Third-party solutions exist which extend the administration and management capabilities. They provide essential
features for a more convenient administration processes, such as automation, reports, integration with other
services, etc.

Administering Active Directory

Domain Services
Updated: October 15, 2008
Applies To: Windows Server 2008, Windows Server 2008 R2
This guide provides information about administering components of Active Directory Domain Services
(AD DS) in Windows Server 2008. The information includes detailed procedures for managing domain
controllers, sites, trusts, and other components of AD DS.
In this guide

Introduction to Administering Active Directory Domain Services

Administering Domain and Forest Trusts

Administering the Windows Time Service

Administering DFS-Replicated SYSVOL

Administering the Global Catalog

9
 Administering Operations Master Roles

Administering Active Directory Backup and Recovery

Administering Intersite Replication

Administering the Active Directory Database

Administering Domain Controllers

Administering Active Directory Domain Rename

Additional Resources

Introduction to Administering
Active Directory Domain
Services
Updated: October 15, 2008

Applies To: Windows Server 2008, Windows Server 2008 R2

This guide explains how to administer Active Directory Domain Services (AD DS) in Windows Server 2008.
These activities are part of the operations phase of the information technology (IT) life cycle. If you are not
familiar with this guide, review the following sections of this introduction.

When to use this guide

Use this guide when:

You want to manage common Active Directory problems that are associated with misconfiguration.

You want to configure AD DS to increase network availability.

This guide assumes a basic understanding of what AD DS is, how it works, and why your organization uses
it to access, manage, and secure shared resources across your network. It also assumes a thorough
understanding of how AD DS is deployed and managed in your organization. This includes an
understanding of the mechanism your organization uses to configure and manage Active Directory
settings.

This guide can be used by organizations that have deployed Windows Server 2008. It includes information
that is relevant to different roles in an IT organization, including IT operations managers, administrators,
and operators. This information includes management-level knowledge about AD DS and administrator-
level information about the IT processes that are required to operate it.

10
This guide contains detailed procedures that are designed for operators (or designated users) who have
varied levels of expertise and experience. Although the procedures provide operator guidance from start to
finish, operators must have a basic proficiency with Microsoft Management Console (MMC) and MMC snap-
ins. Operators must also know how to start administrative programs and access the command line. If
operators are not familiar with AD DS, it might be necessary for IT planners, managers, or administrators
to review the relevant operations in this guide and provide the operators with the parameters or data that
they must enter when they perform the operations.

How to use this guide

This guide includes the following types of topics:

Objectives are high-level goals for administering AD DS. Each objective consists of one or more
high-level tasks that describe how the objective is accomplished. In this guide, "Managing the
Windows Time Service" is an example of an objective.

Tasks contain groups of procedures for achieving the goals of an objective. In this guide,
"Configuring a time source for the forest" is an example of a task.

Procedures provide step-by-step instructions for completing tasks. In this guide, "Configure a
domain controller in the parent domain as a reliable time source" is an example of a procedure
topic.

If you are an IT manager who is delegating tasks to operators in your organization:

Read through the objectives and tasks to determine how to delegate permissions.

Determine whether you need to install tools before operators perform the procedures for each task.
Before you assign tasks to individual operators, ensure that all the tools are installed where
operators can use them.

When necessary, create tear sheets for each task that operators perform in your organization. Cut
and paste the task and its related procedures into a separate document. Then you can either print
this document or store it online.

Administering Domain and

Forest Trusts
Updated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
This guide provides administrators with step-by-step instructions for managing and securing Windows
Server 2008 domain and forest trusts in Active Directory Domain Services (AD DS). The way that you
create or configure trusts plays an important role in operating and securing your network infrastructure.
How you create or configure domain and forest trusts also determines how far network communications
extend within a forest or across forests.
In this guide

11
 Introduction to Administering Domain and Forest Trusts

Best Practices for Administering Domain and Forest Trusts

Managing Domain and Forest Trusts

Securing Domain and Forest Trusts

Appendix: New Trust Wizard Pages

Introduction to Administering
Domain and Forest Trusts
15 out of 20 rated this helpful - Rate this topic

Updated: January 9, 2009

Applies To: Windows Server 2008, Windows Server 2008 R2

By using Windows Server 2008 domain and forest trusts, service administrators can create or extend
collaborative relationships between two or more domains or forests. Windows Server 2008 domains and
forests can also trust Kerberos realms and other Windows Server 2008 forests, as well as
Windows Server 2003 domains, Microsoft Windows 2000 Server domains, and Microsoft
Windows NT Server 4.0 domains.

When a trust exists between two domains, the authentication mechanisms for each domain trust the
authentications coming from the other domain. Trusts help to provide controlled access to shared
resources in a resource domain (the trusting domain) by verifying that incoming authentication requests
come from a trusted authority (the trusted domain). In this way, trusts act as bridges that allow only
validated authentication requests to travel between domains.

How a specific trust passes authentication requests depends on how it is configured. Trust relationships
can be one-way, providing access from the trusted domain to resources in the trusting domain, or two-way,
providing access from each domain to resources in the other domain. Trusts are also either nontransitive,
in which case a trust exists only between the two trust partner domains, or transitive, in which case a trust
automatically extends to any other domains that either of the partners trusts.

In some cases, trust relationships are established automatically when domains are created. In other cases,
administrators must choose a type of trust and explicitly establish the appropriate relationships. The
specific types of trusts that are used and the structure of the resulting trust relationships in a given trust
implementation depend on such factors as how Active Directory Domain Services (AD DS) is organized and
whether different versions of Windows coexist on the network.

12
Best Practices for Administering
Domain and Forest Trusts
6 out of 7 rated this helpful - Rate this topic
Updated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
The following best practices increase availability, ensure trouble-free operations, or ease administration
when you use them to administer domain and forest trusts:

Optimize authentication speed in multidomain forests.

When your forest contains domain trees with many child domains and you observe noticeable user
authentication delays between the child domains, you can optimize the user authentication process
between the child domains by creating shortcut trusts to mid-level domains in the domain tree
hierarchy.

For more information, see "When to create a shortcut trust" in Understanding When to Create a
Shortcut Trust (http://go.microsoft.com/fwlink/?LinkID=107061).

Keep a current list of trust relationships for future reference.

You can use the Nltest.exe tool to display and record a list of these trusts. For more information, see
Nltest Overview (http://go.microsoft.com/fwlink/?LinkID=93567).

Back up domain controllers.

Perform regular backups of domain controllers to preserve all trust relationships within a particular
domain.

Managing Domain and Forest

Trusts
This topic has not yet been rated - Rate this topic

Updated: January 9, 2009

Applies To: Windows Server 2008, Windows Server 2008 R2
It is necessary to manage domain and forest trusts when your organization needs to collaborate with users
or resources that are located in other domains, realms, or forests in your organization and in other
organizations. To set up an environment that takes advantage of trusts, you must first create and configure
the appropriate trusts that will make it possible for your organization to communicate effectively with users
or resources in other locations.
The following objectives are part of managing domain and forest trusts:

13
 Creating Domain and Forest Trusts

Configuring Domain and Forest Trusts

Creating Domain and Forest

Trusts
10 out of 13 rated this helpful - Rate this topic

Updated: January 9, 2009

Applies To: Windows Server 2008, Windows Server 2008 R2
In Windows Server 2008, there are four trust types that must be created manually. External trusts, realm
trusts, and forest trusts help provide interoperability with realms or with domains outside your forest.
Shortcut trusts optimize access to resources and logons that are made between domain trees in the same
forest.
This section includes the following tasks for creating domain and forest trusts:

Creating External Trusts

Creating Shortcut Trusts

Creating Forest Trusts

Creating Realm Trusts

Note

A trust does not inherently allow users in a trusted domain to have access to
resources in a trusting domain. Users have access when they are assigned the
appropriate permissions. In some cases, users in trusted domains may have implicit
access if the resources are assigned to members of the Authenticated Users group.

Before you use the procedures in these tasks, review the issues in Known Issues for Creating Domain and
Forest Trusts.

New Trust Wizard terminology

You create trusts in Windows Server 2008 with the New Trust Wizard. Before you use the New Trust Wizard,
review the following terminology. Each highlighted term represents the exact term as it is used in the
wizard:

14
 This domain: The domain from which you launch the New Trust Wizard. When you start the wizard,
it immediately verifies your administrative credentials in the domain for which you are the
administrator. Therefore, the wizard uses the term this domain to represent the domain that you
are currently logged on to.

Local domain / Local forest: The domain or forest where you start the New Trust Wizard.

Specified domain / Specified forest: The other domain or forest that this local domain or local
forest will trust. Although the New Trust Wizard is aware of the domain context in which it is
running, it does not have knowledge of the other domain that you want to create the relationship
with. After you type the name of the other domain or forest in the Trust Name page, that name is
used whenever the wizard refers to the specified domain or specified forest.

Two-way trust: A trust relationship between two domains in which both domains trust each other.
For example, domain A trusts domain B, and domain B trusts domain A. All parent-child trusts are
two-way trusts.

One-way: incoming trust: A one-way trust relationship between two domains in which the
direction of the trust points toward the domain from which you start the New Trust Wizard (and
which is identified in the wizard as This domain). When the direction of the trust points toward
your domain, users in your domain can access resources in the specified domain. For example, if
you are the domain administrator in domain A and you create a one-way, incoming trust to
domain B, this provides a relationship through which users who are located in domain A can access
resources in domain B. Because this relationship is one way, users in domain B cannot access
resources in domain A.

One-way: outgoing trust: A one-way trust relationship between two domains in which the
direction of the trust points toward the domain that is identified as Specified domain in the New
Trust Wizard. When the direction of trust points toward the specified domain, users in the specified
domain can access resources in your domain. For example, if you are the domain administrator in
domain A and you create a one-way, outgoing trust to domain B, this action provides a relationship
through which users who are located in domain B can access resources in domain A. Because this
relationship is one way, users in domain A cannot access resources in domain B.

Both sides of the trust: When you create external trusts, shortcut trusts, or forest trusts, you
have the option to create each side of the trust separately or both sides of the trust simultaneously.
If you choose to create each side of the trust separately, you must run the New Trust Wizard twice
once for each domain. When you create trusts separately, you must supply the same trust
password for each domain. As a security best practice, all trust passwords should be strong
passwords.

Domain-wide authentication: An authentication setting that permits unrestricted access by any

users in the specified domain to all available shared resources that are located in the local domain.
This is the default authentication setting for external trusts.

Forest-wide authentication: An authentication setting that permits unrestricted access by any

users in the specified forest to all available shared resources that are located in any of the domains
in the local forest. This is the default authentication setting for forest trusts.

Selective authentication: An authentication setting that restricts access over an external trust or
forest trust to only those users in a specified domain or specified forest who have been explicitly

15
 given authentication permissions to computer objects (resource computers) that reside in the local
domain or the local forest. This authentication setting must be enabled manually.

Trust password: An option in which both domains in a trust relationship share a password, which
is stored in the trusted domain object (TDO) object in Active Directory Domain Services (AD DS).
When you choose this option, a strong trust password is generated automatically for you. You must
use the same password when you create a trust relationship in the specified domain. If you choose
to create both sides of the trust simultaneously, you run the New Trust Wizard once.

Creating External Trusts

Updated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
You can create an external trust to form a one-way or two-way, nontransitive trust with domains that are
outside your forest. External trusts are sometimes necessary when users need access to resources that are
located in a Windows NT 4.0 domain or in a domain that is in a separate Active Directory Domain Services
(AD DS) forest that is not joined by a forest trust.
For example, if you have a Windows Server 2008based domain whose users want to gain access to
resources that are stored in a Windows NTbased domain, you must create a trust relationship in which the
Windows NTbased domain trusts the users from the Windows Server 2008based domain. In this case, the
Windows NTbased domain is the trusting domain, and the Windows Server 2008based domain is the
trusted domain.

You can create an external trust between two Windows Server 2003based or Windows
Server 2008based domains, between a Windows Server 2008based domain and a
Windows Server 2003based domain, or between a Windows Server 2003based domain or
Windows Server 2008based domain and a Windows NTbased domain. External trusts cannot be
extended implicitly to a third domain.

To create an external trust successfully, you must set up your Domain Name System (DNS)
environment properly. If there is a root DNS server that you can make the root DNS server for the
DNS namespaces of both forests, make that server the root DNS server by ensuring that the root
zone contains delegations for each of the DNS namespaces. Also, update the root hints of all DNS
servers with the new root DNS server.

If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are
running Windows Server 2003, configure DNS conditional forwarders in each DNS namespace to
route queries for names in the other namespace.

If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are
not running Windows Server 2008 or Windows Server 2003 , configure DNS secondary zones in
each DNS namespace to route queries for names in the other namespace. For more information
about configuring DNS to work with AD DS, see DNS Support for Active Directory Technical
Reference (http://go.microsoft.com/fwlink/?LinkID=106660).

For more information about external trusts, see How Domain and Forest Trusts Work
(http://go.microsoft.com/fwlink/?LinkId=111481).

16
 Note

Trusts that are created between Windows NT 4.0 domains and AD DS domains are one way and nontransitive, and they

Task requirements
You can use either of the following tools to perform the procedures for this task:

Active Directory Domains and Trusts

Netdom.exe

For more information about how to use the Netdom command-line tool to create an external trust, see
Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537).

Creating Forest Trusts

Updated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
You can link two disjoined Active Directory Domain Services (AD DS) forests together to form a one-way or
two-way, transitive trust relationship. You can use a two-way, forest trust to form a transitive trust
relationship between every domain in both forests.
For more information about forest trusts, see How Domain and Forest Trusts Work in
(http://go.microsoft.com/fwlink/?LinkID=111481).
Task requirements
The following are required to create forest trusts successfully:

You can create a forest trust between two Windows Server 2003 forests, between two Windows
Server 2008 forests, between two Windows Server 2008 R2 forests, between a
Windows Server 2003 forest and a Windows Server 2008 forest, between a Windows Server 2003
forest and a Windows Server 2008 R2 forest, or between a Windows Server 2008 forest and a
Windows Server 2008 R2 forest. Forest trusts cannot be extended implicitly to a third forest.

To create a forest trust, the minimum forest functional level for the forests that are involved in the
trust relationship is Windows Server 2003. For more information about functional levels, see the
Active Directory Functional Levels Technical Reference (http://go.microsoft.com/fwlink/?
LinkID=111466).

To create a forest trust successfully, you must set up your Domain Name System (DNS)
environment properly. If there is a root DNS server that you can make the root DNS server for the
DNS namespaces of both forests, make it the root DNS server by ensuring that the root zone
contains delegations for each of the DNS namespaces. Also, update the root hints of all DNS servers
with the new root DNS server.

17
 If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are
running Windows Server 2003, configure DNS conditional forwarders in each DNS namespace to
route queries for names in the other namespace.

If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are
not running Windows Server 2008 or Windows Server 2003, configure DNS secondary zones in each
DNS namespace to route queries for names in the other namespace. For more information about
configuring DNS to work with Active Directory Domain Services (AD DS), see the DNS Support for
Active Directory Technical Reference (http://go.microsoft.com/fwlink/?LinkID=106660).

You can use the following tool to perform the procedures for this task:

Active Directory Domains and Trusts

Note

If you have the appropriate administrative credentials for each forest, you can create both sides of a forest trust at the sa
forest trust, follow the appropriate procedure below that contains the words for both sides of the trust in the title. For
one-way, incoming, forest trust for both sides of the trust explains how to configure both sides of the trust. For more in
of the trust option works, see "Sides of Trust" inAppendix: New Trust Wizard Pages.

18
 Configuring DNS forwarders to
support Windows Server 2003
forest trusts
There are several critical prerequisites in the process of configuring
a forest level trust in Active Directory. When it comes to Domain
Name Server (DNS) configurations, there are two choices when
working with forest trusts: configuring a DNS server that is
authoritative for both the root domains involved in the forest trust,
and adding more hardware. The simpler, more economic choice is
configuring a DNS server -- here's how.
By Derek Schauland | in Windows and Office, August 13, 2007, 5:00 PM PST

RSS

Forest trusts allow organizations to share resources without requiring additional login
credentials or work-to-access resources on Windows Server 2003 systems in other
forests.

There are several critical prerequisites in the process of configuring a forest level trust in
Active Directory. When it comes to Domain Name Server (DNS) configurations, there are
two choices when working with forest trusts:

Configuring a DNS server that is authoritative for both root domains involved
in the forest trust. This requires the creation of a new DNS server to provide
authoritative DNS resources for both partnering domains.

Adding more hardware. This requires deciding where the server will go and
dealing with the cost. It works, but the simpler, more economic choice is the first one.

Remember that DNS forwarders are not dependent on forest level trusts, but forest level
trusts are dependent on DNS forwarders because the systems in one forest need access

19
to resources in other forests. They pass requests onto DNS servers within their
forest/domain and that server can then point them to the trusted forest.

How to configure a DNS forwarder

DNS forwarders are necessary to get forest level trust relationships working properly.
Users can forward DNS between the two forests in the trust relationship in order to speed
up lookups between the organizations and to allow them to act as one. This way, any
domain on one side of the trust may access any resource on the other. A DNS forwarder is
a server that receives requests for lookup from another server. For example, your
company's DNS server may have no idea who www.google.com actually is because it is
not on your network. The request is sent to a forwarder on the Internet to resolve the
name.

Follow these steps to configure a DNS forwarder:

1. Open the DNS snap-in on the DNS server for your forest (go to Start | Administrative
Tools | DNS). In this example, let's call the DNS server at the fictitious company
Spacely Sprockets.

2. In the console tree pane, open the Properties sheet for the DNS server you want to
configure by right-clicking the server name and selecting Properties.

3. Click the Forwarders tab.

4. Specify the domain names that require queries to be forwarded by clicking the New
button and entering the DNS name for the domain. In this case, enter the domain for
the fictitious partner company Cogswell Cogs.

5. Enter the IP address(es) of the DNS server(s) you wish to forward requests to.

6. Click Add.

7. Click OK to close the Forwarders tab.

You will need to configure both root DNS servers to forward requests for the domain on
the other end of the trust. For example, the Spacely Sprockets DNS server would forward
requests for all things Cogswell Cogs, and the DNS server at Cogswell Cogs would do the
same for resources at Spacely Sprockets.

20
Now that the DNS configuration is complete, all you need to do is create the forest trust
between Spacely Sprockets and Cogswell Cogs. Next week, I'll take a look at the steps
needed to get this relationship off the ground.

DNS and NetBIOS Name

Resolution to Create External,
Realm and Forest Trusts
7 out of 14 rated this helpful - Rate this topic

Published: July 23, 2009

Updated: July 24, 2009

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows
Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

Before you create a domain or forest trust, there are name resolution requirements that must be met so
that you can establish the trust successfully. These requirements ensure that the forest or domain can
resolve the address of the domain controllers in the target forest or domain to support the creation and
ongoing operation of the trust.

For all trusts except trusts across forests, the New Trust Wizard and its command-line equivalents allow you
to refer to domains that participate in a trust by their Domain Name System (DNS) or NetBIOS domain
names. For trusts across forests, you must use a DNS name.

Although Windows Internet Name Service (WINS) has been used to support trusts in the past, the focus of
this topic is configuring DNS to create and operate a trust.

DNS Name Resolution

You can use DNS to resolve names for a forest or domain for which you are attempting to establish a trust.
Most DNS names are fully qualified, which means that there is a dot (.) in the name between the forest root
domain and a top-level domain, such as .com, .gov, and .local. There are rare instances in which
Active Directory domains are created with a single-label DNS domain name, such as contoso. When you
type in the name of a remote domain in the New Trust wizard that you are expecting to be resolved by
DNS, then you should enter the DNS name of the remote domain (not its NetBIOS or WINS name).

The DNS servers that the domain controllers in one forest use may not be able to resolve the DNS names
for domain controllers in another forest, and the other way around. If the DNS names for trusting domains
are not registered with an Internet Register, then the DNS Servers used by DCs in the trusted domain
cannot use forwarders to resolve the DNS queries needed to support the trust. There are two common DNS
configurations that you can choose from when you establish DNS name resolution between domains and
forests:

21
 Conditional forwarders

Secondary zones with zone transfers enabled

Note

Stub zones can be used to resolve DNS names, but are less commonly used than secondary zone
therefore, they are not covered in this document.

Using Conditional Forwarders vs. Using Secondary Zones

There are several conditions you should take into account when choosing between conditional forwarders
or secondary zones with zone transfers (to resolve DNS names that your DNS Servers are not authoritative
for). When you decide whether to use conditional forwarders or secondary zones with zone transfers
enabled, there are several considerations you should take into account before choosing either
configuration.

The benefit of using a conditional forwarder is that it is much easier to configure and troubleshoot than a
zone transfer. The process of configuring a conditional forwarder is straightforward: all you need to know is
the DNS domain name of the domain that houses the DNS server that you are configuring to forward
requests and the IP address of the target DNS server.

However, a conditional forwarder is not an efficient way to keep a DNS server that hosts a parent zone
aware of the authoritative DNS servers for a child zone. If you use a conditional forwarder, whenever the
authoritative DNS servers for the child zone change, the conditional forwarder setting on the DNS server
that hosts the parent zone must be configured manually with the IP address for each new authoritative
DNS server for the child zone.

Using a secondary zone with zone transfers enabled is beneficial because this configuration maintains a
list of all the authoritative DNS servers for the secondary copy of the zone, and the list is updated as DNS
servers are added and removed from the target forest or domain. Secondary zones also host a full copy of
the DNS zone.

The drawbacks to using secondary zones with zone transfers enabled are that this configuration is much
more complicated to configure and maintain and you do not have the direct, point-to-point contact with a
DNS server in the target forest or domain as you do with a conditional forwarder. In addition, with
secondary zones you expose hosts to IP address mappings for all hosts in the zone. This can expose the
domain or forest to security risks due to unauthorized access.

Conditional Forwarders

You can use conditional forwarders to route queries between the domains or forests for which you are
establishing a forest or domain trust. Conditional forwarders route names to a specified DNS server in the
target domain or forest for queries that the conditional forwarders cannot resolve.

22
For example, if you establish a two-way, forest trust between the fabrikam.com and contoso.com forests,
you configure a conditional forwarder in the fabrikam.com forest to route queries that it cannot resolve to a
name server in the contoso.com forest. You then configure a conditional forwarder in the contoso.com
forest to route names that it cannot resolve to the fabrikam.com forest.

For more information about conditional forwarders, see the following:

Using forwarders (http://go.microsoft.com/fwlink/?LinkId=157391)

How to Configure Conditional Forwarders in Windows Server 2008 (http://go.microsoft.com/fwlink/?

LinkId=157393). This post not only explains how to configure a conditional forwarder in
Windows Server 2008, it also explains how to configure a conditional forwarder in
Windows Server 2003.

The following flowchart explains how to troubleshoot instances in which conditional forwarders are not
correctly performing name resolution to the target forest or domain. The flowchart shows a one-way,
transitive, outgoing, forest trust between forest A (trusting) and forest B (trusted). Simply put, users in
forest B have access to specified resources in forest A. To complete the steps in the following flowchart,
use the credentials of a member of the Domain Admins group. Review details about using the appropriate
accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?
LinkId=83477).

23
Secondary Zones with Zone Transfers Enabled

Zone transfers replicate DNS databases across a set of DNS servers. If you want to establish a trust
between two forests, you can configure the DNS server in the trusting domain or forest to host a secondary
zone of the trusted forest, with zone transfers enabled.

For example, if you want to establish a two-way trust between the fabrikam.com and contoso.com forests,
you configure the DNS server in the fabrikam.com forest to host a secondary zone of the contoso.com
forests namespace, and the reverse. After you configure the secondary zones in each forest, you then
allow zone transfers between the two forests. For more information about secondary zones or zone
transfers, see the following:

Adding a Secondary DNS Server to a Zone (http://go.microsoft.com/fwlink/?LinkId=157397)

Understanding zones and zone transfers (http://go.microsoft.com/fwlink/?LinkId=157398)

Understanding Zone Types (http://go.microsoft.com/fwlink/?LinkId=157399)

24
DNS Resource Records That Are Required for Secondary Zones

There are two DNS resource records that must be registered properly on the DNS server that hosts the
secondary copy of the trusted domain or forest:

Service (SRV) resource record (_ldap._tcp.dc._msdcs.<computer account domain>)

Host (A) resource record

These records must be in place and registered properly before you establish a domain or forest trust.

The following flowchart explains how to troubleshoot instances in which secondary zones with zone
transfers enabled are not correctly performing name resolution to the target domain or forest. The
flowchart shows a one-way, transitive, outgoing, forest trust between forest A (trusting) and forest B
(trusted). Simply put, users in forest B have access to specified resources in forest A. To complete the steps
in the following flowchart, use the credentials of a member of the Domain Admins group. Review details
about using the appropriate accounts and group memberships at Local and Domain Default
Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

25
Esta pgina web no est disponible
ERR_NAME_NOT_RESOLVED

Cargar de nuevo

Ocultar detalles

26
No es posible encontrar el servidor de d9zeig.bn1301.livefilestore.com porque se ha
producido un error en la bsqueda de DNS. DNS es el servicio de red que traduce el nombre
de un sitio web en su direccin de Internet. Este error suele ocurrir porque la conexin a
Internet no est disponible o porque la red no est configurada correctamente. Tambin se
puede producir porque el servidor de DNS no responda o porque un firewall no permita
que Google Chrome acceda a la red.

Comprueba tu conexin a Internet

Comprueba los cables y reinicia los routers, los mdems y otros dispositivos de red que ests
utilizando.

Comprueba tu configuracin de DNS

Si tienes alguna duda, ponte en contacto con el administrador de red.

Prueba a inhabilitar la prediccin de red

Accede al men de Chrome > Configuracin > Mostrar configuracin avanzada... y desactiva
la opcin "Cargar recursos previamente para que las pginas se carguen de forma ms
rpida". Si esto no soluciona el problema, te recomendamos que vuelvas a seleccionar esta
opcin para conseguir un mejor rendimiento.

Configura tu cortafuegos o tu antivirus para permitir el acceso de Chrome a la red.

Si ya est incluido como programa autorizado para acceder a la red, prueba a eliminarlo de
la lista y volver a aadirlo.

Si utilizas un servidor proxy...

Comprueba la configuracin de proxy o ponte en contacto con el administrador de red para

asegurarte de que el servidor proxy funcione correctamente. Si crees que no debes utilizar
un servidor proxy, sigue estos pasos: Accede al men de Chrome, haz clic
enConfiguracin > Mostrar configuracin avanzada... > Cambiar la configuracin de
proxy...> Configuracin de LAN y desactiva la opcin Usar un servidor proxy para la LAN.

27