Professional Documents
Culture Documents
Shortcut trusts are necessary when many users in a domain regularly log on to other domains in a forest. For example,
using the following figure as an example, you could form a shortcut trust between domain B and domain D or domain
A and domain 1 and so on.
Art Image
Shortcut trusts effectively shorten the path traveled for authentication's made between domains located in two
separate trees.
For more information about how to create a shortcut trust, see Create a shortcut trust .
In this section
•Trust Architecture
•Trust Processes and Interactions
•Network Ports used by Trusts
Active Directory provides security across multiple domains or forests through domain and forest trust relationships.
Before authentication can occur across trusts, Windows must first determine whether the domain being requested by a
user, computer or service has a trust relationship with the logon domain of the requesting account. To make this
determination, the Windows security system computes a trust path between the domain controller for the server that
receives the request and a domain controller in the domain of the requesting account.
The access control mechanisms provided by Active Directory and the Windows distributed security model provide an
optimal environment for the operation of domain and forest trusts. For these trusts to function properly, every
workstation and server must have a direct trust path to a domain controller in the domain in which it is located. The
trust path is implemented by the Net Logon service through an authenticated remote procedure call (RPC) connection
to the trusted domain authority, which is the domain controller. In addition, a secured channel extends to other Active
Directory domains through interdomain trust relationships. This secured channel is used to obtain and verify security
information, including security identifiers (SIDs) for users and groups.
This section describes the inner workings of trusts, discusses the various types of trusts that can be used, provides a
detailed list of referral and logon processes that involve trusts, and lists the network ports that trusts can use.
Trust Architecture
Applications integrated with Windows Server 2003 and Active Directory use components of the operating system to
establish and maintain trusts. A number of these components help form the trust architecture that provides an effective
communication infrastructure for Active Directory. These include authentication protocols, the Net Logon service, the
Local Security Authority (LSA), and the Trusted Domain Objects (TDOs) stored in Active Directory. These trust
components are shown in the following illustration.
Trust Components
The NTLM authentication protocol is dependent on the Net Logon service on domain controllers for client
authentication and authorization information. This protocol authenticates clients that do not use Kerberos
authentication. NTLM uses trusts to pass authentication requests between domains.
The Kerberos V5 authentication protocol is dependent on the Net Logon service on domain controllers for client
authentication and authorization information. The Kerberos protocol connects to an online Key Distribution Center
(KDC) and the Active Directory account store for session tickets. The Kerberos protocol also uses trusts for cross-
realm ticket-granting services (TGS) and to validate Privilege Attribute Certificates (PACs) across a secured channel.
The Kerberos protocol performs cross-realm authentication only with non-Windows-brand operating system
Kerberos realms such as an MIT Kerberos realm and does not need to interact with the Net Logon service.
The Net Logon service maintains a secured channel from a Windows-based computer to a domain controller. It is also
used in the following trust related processes:
•Trust setup and management – Net Logon helps maintain trust passwords, gathers trust information and verifies
trusts by interacting with the LSA process and the TDO. For Forest trusts, the trust information includes the Forest
Trust Information (FTInfo) record, which includes the set of namespaces that a trusted forest claims to manage,
annotated with a field that indicates whether each claim is actually trusted by the trusting forest.
•Authentication – Supplies user credentials over a secured channel to a domain controller and returns the domain
SIDs and user rights for the user
•Domain controller location – Helps with finding or locating domain controllers in a domain or across domains
•Pass-through validation – Credentials of users in other domains are processed by Net Logon. When a trusting
domain needs to verify the identity of a user, it passes the user’s credentials through Net Logon to the trusted domain
for verification
•Privilege Attribute Certificate (PAC) verification – When a server using the Kerberos protocol for authentication
needs to verify the PAC in a service ticket, it sends the PAC across the secure channel to its domain controller for
verification.
LSA (Lsasrv.dll)
The Local Security Authority (LSA) is a protected subsystem that maintains information about all aspects of local
security on a system (collectively known as local security policy) and provides various services for translation
between names and identifiers. The LSA security subsystem provides services in both kernel mode and user mode for
validating access to objects, checking user privileges, and generating audit messages. LSA is responsible for checking
the validity of all session tickets presented by services in trusted or untrusted domains.
Tools
Administrators can use Active Directory Domains and Trusts, Netdom and Nltest to expose, create, remove or modify
trusts. Active Directory Domains and Trusts is the Microsoft Management Console (MMC) that is used to administer
domain trusts, domain and forest functional levels, and user principal name suffixes. The Netdom and Nltest
command line tools can be used to find, display, create and manage trusts. These tools communicate directly with the
LSA authority on a domain controller.
Active Directory
The Active Directory directory service stores information about objects on a network and makes this information
available to users and network administrators. Trusts can be used to extend the reach of Active Directory domains and
forests to other domains, forests or realms within an organization.
Each domain or forest trust within an organization is represented by a Trusted Domain Object (TDO) stored in the
System container within its domain.
TDO Contents
The information contained in a TDO can vary depending on whether a TDO was created by a domain trust or by a
forest trust. When a domain trust is created, attributes such as the DNS domain name, domain SID, trust type, trust
transitivity, and the reciprocal domain name are represented in the TDO. Forest trust TDOs store additional attributes
to identify all of the trusted namespaces from the partner forest. These attributes include domain tree names, user
principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces.
Because trusts are stored in Active Directory as TDOs, all domains in a Windows Server 2003 forest have knowledge
of the trust relationships that are in place throughout the forest. Similarly, when two or more forests are joined
together through forest trusts, the forest root domains in each forest have knowledge of the trust relationships that are
in place throughout all of the domains in trusted Windows Server 2003 forests. External trusts to a Windows NT 4.0
domain do not create TDOs in Active Directory.
TDO Passwords
Both domains in a trust relationship share a password, which is stored in the TDO object in Active Directory. As part
of the account maintenance process, every thirty days, the trusting domain controller changes the password stored in
the TDO. Because all two-way trusts are actually two one-way trusts going in opposite directions, the process occurs
twice for two-way trusts. To change a password, domain controllers in domains on each side of the trust complete the
following process:
1The primary domain controller (PDC) emulator in the trusting domain creates a new password.
.
A domain controller in the trusted domain never initiates the password change; it is always initiated by the trusting
domain PDC emulator.
2The domain controller in the trusting domain sets the OldPassword field of the TDO object to the previous
. NewPassword field.
3The domain controller in the trusting domain sets the NewPassword field of the TDO object to the new password.
.
Keeping a copy of the previous password makes it possible to revert to the old password if the domain controller in
the trusted domain fails to receive the change, or if the change is not replicated before a request is made that uses
the new trust password.
4The domain controller in the trusting domain makes remote call to a domain controller in the trusted domain asking
. it to set the password on the trust account to the new password.
5The domain controller in the trusted domain changes the trust password to the new password.
.
The password is now changed on both domain controllers. Normal replication distributes the TDO objects to the other
domain controllers in the domain. However, is possible for the domain controller in the trusting domain to change the
password without successfully updating a domain controller in the trusted domain. This might occur because a
secured channel, which is required to process the password change, could not be established. It is also possible that
the domain controller in the trusted domain might be unavailable at some point during the process and might not
receive the updated password.
To deal with situations in which the password change is not successfully communicated, the domain controller in the
trusting domain never changes the new password unless it has successfully authenticated (set up a secured channel)
using the new password. This is why both the old and new passwords are kept in the TDO object of the trusting
domain. Because a password change is not finalized until authentication using the password succeeds, the old, stored
password can be used over the secured channel until the domain controller in the trusted domain receives the new
password, thus enabling uninterrupted service.
If authentication using the new password fails because the password is invalid, the trusting domain controller tries to
authenticate using the old password. If it authenticates successfully with the old password, it resumes the password
change process within 15 minutes.
Most trust passwords propagate to all domain controllers within a day. Trust passwords have a default lifetime of 30
days, by which time all domain controllers will have received the new password.
While Windows Server 2003 can support a large number of trusts between many security authorities, and there are
some limitations to trust functionality. These limitations are associated with the number of TDOs, the length of trust
paths, and the ability of clients to discover available trusts.
Number of TDOs
TDOs are associated with domains, and as the number of TDOs increases, the processing performance of these links
declines. Testing indicates that the time to complete operations related to TDOs, such as authentication across
domains, deteriorates noticeably if the Active Directory implementation in an organization contains more than 2400
TDOs. Few organizations, however, require such a large number of trusts, and Windows Server 2003 places no
absolute limit on the number of trust links that a domain can maintain with other domains or forests.
There is a limit to the number of trust links that can be used effectively in a Windows Server 2003 network. In
Windows Server 2003, Kerberos clients can traverse a maximum of 10 trust links to locate a requested resource in
another domain. If the trust path between the domains exceeds this limit, the attempt to access the domain fails. This
problem can be addressed by creating external trusts to target domains in order to bypass excessively long trust paths.
When a client searches out a trust path, the search is limited to trusts that are established directly with a domain and
those that are transitive within a forest. A child domain, for example, cannot use an external trust between its parent
domain and a domain in another forest. This is because a complete trust path must be constructed before a client can
begin to work its way along the path to a requested resource domain. Windows Server 2003 does not support blind
referrals; if a client cannot identify a trust path, it will not attempt to seek access to a requested resource in another
domain. Child domains cannot identify external trusts or realm trusts to security authorities outside of their forest
because the TDOs that represent those trusts are published only within the domain that shares the trust, not to Global
Catalogs. Clients are therefore unaware of trusts that their domains share with security authorities other than their
parent or child domains, and are thus unable to use them to access resources.
Trust Flow
The flow of secured communications over trusts determines the elasticity of a trust: how you create or configure a
trust determines how far the communication extends within a forest or across forests. The flow of communication
over trusts is determined by the direction of the trust (one-way or two-way) and the transitivity of the trust (transitive
or nontransitive).
One-Way and Two-Way Trusts
Trust relationships that are established to enable access to resources can be either one-way or two-way. A one-way
trust is a unidirectional authentication path created between two domains. In a one-way trust between Domain A and
Domain B, users in Domain A can access resources in Domain B. However, users in Domain B cannot access
resources in Domain A. Some one-way trusts can be either nontransitive or transitive depending on the type of trust
being created.
All domain trusts in an Active Directory forest are two-way, transitive trusts. When a new child domain is created, a
two-way, transitive trust is automatically created between the new child domain and the parent domain. In a two-way
trust, Domain A trusts Domain B and Domain B trusts Domain A. This means that authentication requests can be
passed between the two domains in both directions. Some two-way relationships can be nontransitive or transitive
depending on the type of trust being created. An Active Directory domain can establish a one-way or two-way trust
with:
Transitivity determines whether a trust can be extended outside of the two domains with which it was formed. A
transitive trust can be used to extend trust relationships with other domains; a nontransitive trust can be used to deny
trust relationships with other domains.
Each time you create a new domain in a forest, a two-way, transitive trust relationship is automatically created
between the new domain and its parent domain. If child domains are added to the new domain, the trust path flows
upward through the domain hierarchy extending the initial trust path created between the new domain and its parent
domain. Transitive trust relationships flow upward through a domain tree as it is formed, creating transitive trusts
between all domains in the domain tree.
Authentication requests follow these trust paths, so accounts from any domain in the forest can be authenticated by
any other domain in the forest. With a single logon process, accounts with the proper permissions can access
resources in any domain in the forest. The following figure shows that all domains in Tree 1 and Tree 2 have
transitive trust relationships by default. As a result, users in Tree 1 can access resources in domains in Tree 2 and
users in Tree 1 can access resources in Tree 2, when the proper permissions are assigned at the resource.
•Shortcut trust. A transitive trust between domains in the same domain tree or forest that is used to shorten the trust
path in a large and complex domain tree or forest.
•Forest trust. A transitive trust between one forest root domain and another forest root domain.
•Realm trust. A transitive trust between an Active Directory domain and a Kerberos V5 realm.
A nontransitive trust is restricted to the two domains in the trust relationship and does not flow to any other domains
in the forest. A nontransitive trust can be a two-way trust or a one-way trust.
Nontransitive trusts are one-way by default, although you can also create a two-way relationship by creating two one-
way trusts. Nontransitive domain trusts are the only form of trust relationship possible between:
By using the New Trust Wizard, you can manually create the following nontransitive trusts:
•External trust. A nontransitive trust created between a Windows Server 2003 domain and a Windows NT,
Windows 2000, or Windows Server 2003 domain in another forest. When you upgrade a Windows NT domain to a
Windows Server 2003 domain, all existing Windows NT trusts are preserved intact. All trust relationships between
Windows Server 2003 domains and Windows NT domains are nontransitive.
•Realm trust. A nontransitive trust between an Active Directory domain and a Kerberos V5 realm.
Trust Types
Although all trusts enable authenticated access to resources, trusts can have different characteristics. The types of
domains included in the trust relationship affect the type of trust that is created. For example, a trust between two
child domains in different forests is always an external trust, but trusts between two Windows Server 2003 forest root
domains can be either external trusts or forest trusts.
Two types of trusts are created automatically when you use the Active Directory Installation Wizard. Four other types
of trusts can be manually created by using either the New Trust Wizard or the Netdom command-line tool.
Automatic Trusts
By default, two-way transitive trusts are automatically created when a new domain is added to a domain tree or forest
root domain by using the Active Directory Installation Wizard. The two default trust types are parent-child trusts and
tree-root trusts.
Parent-child trust
A parent-child trust relationship is established whenever a new domain is created in a tree. The Active Directory
installation process automatically creates a trust relationship between the new domain and the domain that
immediately precedes it in the namespace hierarchy (for example, corp.tailspintoys.com is created as the child of
tailspintoys.com). The parent-child trust relationship has the following characteristics:
•It can exist only between two domains in the same tree and namespace.
•The parent domain is always trusted by the child domain.
•It must be transitive and two-way. The bidirectional nature of transitive trust relationships allows the global directory
information in Active Directory to replicate throughout the hierarchy.
Tree-root trust
A tree-root trust is established when you add a new domain tree to a forest. The Active Directory installation process
automatically creates a trust relationship between the domain you are creating (the new tree root) and the forest root
domain. A tree-root trust relationship has the following restrictions:
•It can be established only between the roots of two trees in the same forest.
•It must be transitive and two-way.
Manual Trusts
In Windows Server 2003 there are four trust types that must be created manually: shortcut trusts are used for
optimization between domain trees in the same forest; external, realm, and forest trusts help provide interoperability
with domains outside of the forest, with other forests, or with realms. These trust types must be created by using the
New Trust Wizard or the Netdom command-line tool.
Shortcut Trusts
Shortcut trusts are one-way or two-way transitive trusts that can be used when administrators need to optimize the
authentication process. Authentication requests must initially travel a trust path between domain trees. A trust path is
the series of domain trust relationships that must be traversed in order to pass authentication requests between any
two domains. In a complex forest, the time required to traverse the trust path can impact performance. You can
significantly reduce this time by using shortcut trusts.
Shortcut trusts speed up logon and access times to resources in a domain that is deep within the hierarchy of another
domain tree. The following figure illustrates trust relationships between two trees in a Windows Server 2003 forest.
Trusts within a Single Windows 2000 Server or Windows Server 2003 Forest
When a two-way shortcut trust is established between two domains located in separate domain trees, the time needed
to fulfill authentication requests originating in either domain is reduced. For example, when a two-way trust is
established between the usa.corp.wingtiptoys.com domain and the rome.europe.corp.tailspintoys.com domain,
authentication requests made from either domain to the other can utilize the new, two-way shortcut trust path.
External Trusts
An external trust is a trust relationship that can be created between Active Directory domains that are in different
forests or between an Active Directory domain and a Windows NT 4.0 or earlier domain. An external trust
relationship has the following characteristics:
•It is nontransitive.
•It must be established manually in each direction to create a two-way external trust relationship. In
Windows Server 2003 you can create both sides of the external two-way trust at once by using the New Trust
Wizard.
•It enforces SID filter quarantining by default in Windows Server 2003. External trusts created from the trusting
domain use SID filter quarantining to verify that incoming authentication requests made from security principals in
the trusted domain contain only SIDs of security principals in the trusted domain. SID filter quarantining ensures
that any misuse of the SID history attribute on security principals (including inetOrgPerson) in the trusted forest
cannot pose a threat to the integrity of the trusting forest.
External trusts provide access to resources in a domain outside of the forest that is not already joined by a forest trust.
The following illustration shows how external trusts can be used between a Windows Server 2003 forest and a
Windows 2000 forest.
External trusts between a Windows Server 2003 Forest and a Windows 2000 Forest
In this example, two external trust relationships exist between domains in the Windows Server 2003 forest and the
Windows 2000 forest. The direction of the one-way external trust arrow indicates that the
sales.corp.worldwideimporters.com domain trusts the rome.europe.corp.tailspintoys.com domain, which means that
users in the rome.europe.corp.tailspintoys.com domain can access resources in the
sales.corp.worldwideimporters.com domain.
The direction of the two-way external trust arrow indicates that both the europe.corp.tailspintoys.com domain and the
sales.corp.worldwideimporters.com domain trust each other. This relationship allows for authentication requests to be
passed between the two domains, coming from either direction, to any shared resources in those two domains.
The following figure illustrates a trust configuration that includes an external trust relationship between a domain in a
Windows Server 2003 forest and a Windows NT 4.0 domain.
External Trust Between a Windows NT 4.0 Domain and a Child Domain in a Windows Server 2003 Forest
This configuration allows users in the europe.corp.tailspintoys.com domain to access resources in the
Windows NT 4.0 domain. It does not allow the Windows NT 4.0 domain to access resources in the
europe.corp.tailspintoys.com domain or for any trusted domains that the europe.corp.tailspintoys.com domain trusts.
All forest trusts in Windows Server 2003 Active Directory enforce SID filtering. Applying SID filtering to trusts
helps to prevent malicious users who have domain administrator level access in the trusted domain from granting to
themselves, or other user accounts in their domain, elevated user rights to the trusting domain.
Realm Trusts
A trust relationship can be established between a non-Windows Kerberos realm and a Windows 2000 or Windows
Server 2003 domain. This trust relationship allows cross-platform interoperability with security services based on
other Kerberos V5 implementations.
Transitive and Non-Transitive Realm Trusts from a Domain in a Windows Server 2003 Forest
It does not allow users in the europe.corp.tailspintoys.com domain to access resources in Realm 2.
Note
•In Windows 2000, if you create a non-Windows Kerberos realm trust relationship by using Active Directory
Domains and Trusts, the trust is one-way and nontransitive. To work around this, you can use the Netdom tool
(Netdom.exe) to establish two-way, transitive, non-Windows Kerberos realm trust relationships. In Windows
Server 2003, you can use the New Trust Wizard to create one-way or two-way and transitive or nontransitive realm
trusts.
Realm trusts are not as comprehensive as domain trusts. For instance, user principals from the Kerberos realm do not
have the authorization data that Windows Server 2003-based services need for access control. In order for this
authorization data to be added to the user’s ticket, an account mapping mechanism is used. Selected domain user
accounts are used to provide identity for Kerberos principals in the trusted realm. These mappings are kept on the
SecurityID property on the user account object. They can be managed through Active Directory Users and
Computers.
Forest Trusts
Forest trusts help you to manage a segmented Windows Server 2003 Active Directory infrastructure within your
organization by providing support for accessing resources and other objects across multiple Windows Server 2003
forests. Forest trusts are useful for Application Service Providers, companies undergoing mergers or acquisitions,
collaborative business extranets, and companies seeking a solution for administrative autonomy.
•Simplified management of resources across two Windows Server 2003 forests by reducing the number of external
trusts necessary to share resources.
•Complete two-way trust relationships with every domain in each forest.
•Use of user principal name (UPN) authentication across two forests.
•Use of both the Kerberos V5 and NTLM authentication protocols to improve the trustworthiness of authorization
data transferred between forests.
•Flexibility of administration. Administrative tasks can be unique to each forest.
•Secured data within each forest. Sensitive data can be protected so that only users within that forest can access it.
•Isolated directory replication within each forest. Schema changes, configuration changes, and the addition of new
domains to a forest have forest-wide impact only within that forest, not in a trusting forest.
•Enforcement of SID filtering in Windows Server 2003. SID filtering ensures that any misuse of the SID history
attribute on security principals (including inetOrgPerson) in the trusted forest cannot pose a threat to the integrity of
the trusting forest.
Enforcing SID filtering on forest trusts does not prevent use of SID history in migrations to domains within the same
forest and does not affect your universal group access control strategy.
By using forest trusts you can link two different Windows Server 2003 forests to form a one-way or two-way
transitive trust relationship. A forest trust allows administrators to federate two Active Directory forests with a single
trust relationship to provide a seamless authentication and authorization experience across the forests.
A forest trust can be created only between a forest root domain in one Windows Server 2003 forest and a forest root
domain in another Windows Server 2003 forest. Forest trusts can be created between two forests only and cannot be
implicitly extended to a third forest. This means that if a forest trust is created between Forest 1 and Forest 2, and
another forest trust is created between Forest 2 and Forest 3, Forest 1 does not have an implicit trust with Forest 3.
The following figure shows two separate forest trust relationships between three Windows Server 2003 forests in a
single organization.
In this example, a two-way transitive forest trust exists between the forest root domains in Forest 1 and Forest 2, and
another two-way transitive forest trust exists between the forest root domains in Forest 3 and Forest 2. This
configuration allows:
This configuration does not allow users in Forest 1 to access resources in Forest 3 or vice versa. To allow users in
both Forest 1 and Forest 3 to share resources, a two-way transitive trust must be created between the two forests.
If a one-way forest trust is created between two forests, members of the trusted forest can utilize resources located in
the trusting forest. However, the trust operates in only one direction. For example, when a one-way, forest trust is
created between Forest 1 (the trusted forest) and Forest 2 (the trusting forest), members of Forest 1 can access
resources located in Forest 2, but members of Forest 2 cannot access resources located in Forest 1 using the same
trust.
Consequently, as shown in the example, a two-way forest trust between two forests allows members from either
forest to utilize resources located in the other forest; domains in each respective forest trust domains in the other
forest implicitly.
There are specific requirements that must be met for using forest trusts. Before you can create a forest trust, you need
to verify that all domain controllers in both forests are running Windows Server 2003. You also need to verify that
you have the correct Domain Name System (DNS) infrastructure in place and that you have established the
appropriate functionality level for Active Directory. This means that the forest must be raised to the Windows
Server 2003 functional level and that you cannot install additional Windows 2000 or Windows NT Server 4.0 domain
controllers in the forest.
Forest trusts can only be created when one of the following DNS configurations is in place in your infrastructure:
•A single root DNS server is the root DNS server for both forest DNS namespaces: the root zone contains delegations
for each of the DNS namespaces and the root hints of all DNS servers include the root DNS server.
•Where there is no shared root DNS server, and the root DNS servers for each forest DNS namespace are running a
member of the Windows Server 2003 family, DNS conditional forwarders are configured in each DNS namespace to
route queries for names in the other namespace.
•Where there is no shared root DNS server, and the root DNS servers for each forest DNS namespace are not running
a member of the Windows Server 2003 family, DNS secondary zones are configured in each DNS namespace to
route queries for names in the other namespace.
To create a forest trust, the administrator creating the trust must be a member of the Domain Admins group (in the
forest root domain) or the Enterprise Admins group in Active Directory. Each trust is assigned a password that the
administrators in both forests must know. Members of Enterprise Admins in both forests can create the trusts in both
forests at once and, in this scenario, a password that is cryptographically random is automatically generated and
written for both forests.
Members of the Incoming Forest Trust Builders group can create one-way, incoming forest trusts. For example,
members of this group residing in Forest A can create a one-way, incoming forest trust from Forest B. This one-way,
incoming forest trust allows users in Forest A to access resources located in Forest B. Members of this group are
granted the permission Create Inbound Forest Trust on the forest root domain. This group has no default members.
All Windows NT Server 4.0, Windows 2000, Windows XP clients can use the forest trust for authentication.
However, Windows NT Server 4.0 clients support only NTLM and they do not support user principal names (UPNs)
for logging on to the network. Windows Server 2003 forest trusts cannot be created between a Windows Server 2003
forest and a Windows 2000 forest.
Top of page
When a request for authentication is referred to a domain, the domain controller in that domain must determine
whether a trust relationship exists with the domain from which the request comes, as well as the direction of the trust
and whether the trust is transitive or nontransitive, before it authenticates the user to access resources in the domain.
The authentication process that occurs between trusted domains varies according to the authentication protocol in use.
The Kerberos V5 and NTLM protocols in Windows 2000 Server and Windows Server 2003 process referrals for
authentication to a domain differently, as do the other authentication protocols, such as Digest, and SChannel, that
Windows 2000 Server and Windows Server 2003 support.
Kerberos V5 Referral Processing
If the client uses Kerberos V5 for authentication, it requests a ticket to the server in the target domain from a domain
controller in its account domain. The Kerberos Key Distribution Center (KDC) acts as a trusted intermediary between
the client and server; it provides a session key that enables the two parties to authenticate each other. If the target
domain is different from the current domain, the KDC follows a logical process to determine whether an
authentication request can be referred:
1Is the current domain trusted directly by the domain of the server that is being requested?
.
•If yes, send the client a referral to the requested domain.
•If no, go to the next step.
2Does a transitive trust relationship exist between the current domain and the next domain on the trust path?
.
•If yes, send the client a referral to the next domain on the trust path.
•If no, send the client a logon-denied message.
If the client uses NTLM for authentication, the initial request for authentication goes directly from the client to the
resource server in the target domain. This server creates a challenge to which the client responds. The server then
sends the user’s response to a domain controller in its computer account domain. This domain controller checks the
user account against its security accounts database. If the account does not exist in the database, the domain controller
determines whether to perform pass-through authentication, forward the request, or deny the request by using the
following logic:
1Does the current domain have a direct trust relationship with the user’s domain?
.
•If yes, the domain controller sends the credentials of the client to a domain controller in the user’s domain for pass-
through authentication.
•If no, go to the next step.
2Does the current domain have a transitive trust relationship with the user’s domain?
.
•If yes, pass the authentication request on to the next domain in the trust path. This domain controller repeats the
process by checking the user’s credentials against its own security accounts database.
•If no, send the client a logon-denied message.
Windows 2000 Server and Windows Server 2003 also support both Digest and Schannel authentication across forest
trusts. This enables technologies such as Web servers to complete their tasks in a multiple domain environment. The
Secure Sockets Layer (SSL) protocol and certificate mapping to Active Directory user accounts use Schannel, and
Internet Information Services (IIS) uses Digest. Digest and SChannel authentication between trusted domains might
be required in cases where a firewall between trusting forests or domains allows only HTTP traffic through. Digest
can be carried in HTTP headers.
The Windows 2000 Server and Windows Server 2003 authentication negotiation determines the authentication
protocol that is used over trusts, as long as the generic pass-through mechanism can find the appropriate domain
controller in the target domain. Administrators can also choose to implement a security support provider (SSP) for
another authentication protocol. If the SSP is compatible with the Windows 2000 Server and Windows Server 2003
distributed systems, it will work over trusts across domain boundaries in the same way that standard Windows 2000
Server and Windows Server 2003 SSPs work across domains.
Active Directory domains within the same forest are implicitly connected by two-way, transitive trusts, so that
authentication requests from one domain to another are routed to provide a seamless access to resources across
domains. Domain controllers running Windows 2000 or Windows Server 2003 authenticate users and applications
using one of two authentication protocols: Kerberos V5 or NTLM. Once authenticated in their own domain, users can
attempt to gain access to resources from any domain in the forest using the Active Directory authorization process.
To access a shared resource in another domain by using Kerberos authentication, a user’s computer first requests a
ticket from a domain controller in its account domain to the server in the trusting domain that hosts the requested
resource. This ticket is then issued by an intermediary trusted by both the user’s computer and the server. The user’s
computer presents this trusted ticket to the server in the trusting domain for authentication.
The following illustration and corresponding steps provide a detailed description of the Kerberos authentication
process that is used when a computer running Windows 2000 Professional, Windows 2000 Server, Windows XP
Professional, or a member of the Windows Server 2003 family attempts to access resources from a server located in
another domain.
Each domain has its own set of security policies governing access to resources. These policies do not cross from one
domain to another.
When two Windows Server 2003 forests are connected by a forest trust, authentication requests made using the
Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests.
When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and stores
the information in a TDO. Trusted namespaces include domain tree names, user principal name (UPN) suffixes,
service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. TDO objects are
replicated to the global catalog.
Before authentication protocols can follow the forest trust path, the service principal name (SPN) of the resource
computer must be resolved to a location in the other forest. An SPN can be one of the following: the Domain Name
System (DNS) name of a host, the DNS name of a domain, or the distinguished name of a service connection point
object.
When a workstation in one forest attempts to access data on a resource computer in another forest, the Kerberos
authentication process contacts the domain controller for a service ticket to the SPN of the resource computer. Once
the domain controller queries the global catalog and determines that the SPN is not in the same forest as the domain
controller, the domain controller sends a referral for its parent domain back to the workstation. At that point, the
workstation queries the parent domain for the service ticket and continues to follow the referral chain until it reaches
the domain where the resource is located.
The following illustration and corresponding steps provide a detailed description of the Kerberos authentication
process that is used when computers running Windows 2000 Professional, Windows XP Professional, Windows 2000
Server, or a member of the Windows Server 2003 family attempt to access resources from a computer located in
another forest.
This port is used for trust creation and other access to the LSA policy database.
This port is used for NTLM authentication and secured channel communications.
The following table shows the list of ports that might need to be opened before you establish trusts.
Endpoint resolution —
portmapper (135 TCP)
Net Logon fixed port
Trust validation from the internal LDAP (389 UDP) N/A Internal domain domain
forest domain controller to the controllers–External domain
external forest domain controller Microsoft SMB (445 domain controllers (all
(outgoing trust only) TCP) ports)
Endpoint resolution —
portmapper (135 TCP)
Net Logon fixed port
Use Object picker on the external N/A LDAP (389 UDP and External server–Internal
forest to add objects that are in an TCP) domain PDCs (Kerberos)
internal forest to groups and DACLs
Windows NT Server 4.0 External domain domain
directory service fixed controllers–Internal domain
port domain controllers (Net
Logon)
Net Logon fixed port
Endpoint resolution
portmapper (135 TCP)
Set up trust on the external forest N/A LDAP (389 UDP and External domain domain
from the external forest TCP) controllers–Internal domain
domain controllers (all
Microsoft SMB (445 ports)
TCP)
Endpoint resolution —
portmapper (135 TCP)
Net Logon fixed port
To specify the services that you want to run on a fixed port, you must appropriately configure the registry for that
port.
The information here is provided as a reference for use in troubleshooting or verifying that the required settings are
applied. It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications
to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect
values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other
Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry
directly. If you must edit the registry, use extreme caution.
Settings for the Local Security Authority (LSA) RPC port are stored in the TCP/IP Port entry in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters registry key.
Settings for the Net Logon RPC port are stored in the DCTcpipPort entry in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry key.
Implementation of an Active Directory functional level that supports advanced features of Windows Server 2003
requires more than just the installation of Windows Server 2003 on domain controllers. It requires an understanding
of the advanced features that are provided at each domain and forest functional level and how to use Active Directory
administration tools to raise the functional level.
In this subject