How Domain and Forest Trusts Work: Domain and Forest Trusts

How Domain and Forest Trusts Work

Updated: February 2, 2012

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

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

NTLM Protocol (Msv1_0.dll)

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.

Kerberos Protocol (Kerberos.dll)

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.

Net Logon (Netlogon.dll)

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.

Trusted Domain Object

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. A trust has a trusting and a trusted side. On the trusted side, any writable domain controller can be used for the process. On the trusting side, the PDC emulator performs the password change. To change a password, the domain controllers complete the following process:

The 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.
The PDC emulator in the trusting domain sets the OldPassword field of the TDO object to the current NewPassword field.
The PDC emulator 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.
The PDC emulator in the trusting domain makes a remote call to a domain controller in the trusted domain asking it to set the password on the trust account to the new password.
The domain controller in the trusted domain changes the trust password to the new password.
On each side of the trust, the updates are replicated to the other domain controllers in the domain. In the trusting domain, the change triggers an urgent replication of the trusted domain object.

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.

Trust password updates need to replicate to the domain controllers of both sides of the trust within 30 days. If the trust password is changed after 30 days and a domain controller then only has the N-2 password, it cannot use the trust from the trusting side and cannot create a secure channel on the trusted side.

Practical Limitations of Trusts

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.

Trust Path Limits

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.

Trust Search Limits

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:

Windows Server 2003 domains in the same forest.
Windows Server 2003 domains in a different forest.
Windows NT 4.0 domains.
Kerberos V5 realms.

Transitive and Nontransitive Trusts

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.

Default Transitive Trust Relationships

In addition to the default transitive trusts established in a Windows Server 2003 forest, by using the New Trust Wizard you can manually create the following transitive trusts.

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:

A Windows Server 2003 domain and a Windows NT domain
A Windows Server 2003 domain in one forest and a domain in another forest (when not joined by a forest trust)

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

In this example, the following conditions are true:

A two-way transitive tree-root trust exists between corp.tailspintoys.com and corp.wingtiptoys.com.
Parent-child trust relationships exist between parent and child domains in both trees of the forest. Because the two trees trust each other, all domains in Tree 1 and Tree 2 have access to resources in all domains in the forest.
A one-way shortcut trust exists between the rome.europe.corp.tailspintoys.com and usa.corp.wingtiptoys.com domains. This creates an alternate path by which users in the usa.corp.wingtiptoys.com domain can access resources in the rome.europe.corp.tailspintoys.com domain. The shortcut trust shortens the trust path needed to reach the intended domain by cutting the number of hops required for authentication from three (rome.europe.corp.tailspintoys.com to europe.corp.tailspintoys.com to corp.tailspintoys.com to corp.wingtiptoys.com) to one (rome.europe.corp.tailspintoys.com to usa.corp.wingtiptoys.com), which increases the speed of authentication.
Because the shortcut trust is one-way, authentication requests made from the rome.europe.corp.tailspintoys.com domain to the usa.corp.wingtiptoys.com domain still need to travel the longer trust path.

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.

This configuration allows:

Users in the europe.corp.tailspintoys.com domain to access resources in the sales.corp.worldwideimporters.com domain
Users in the sales.corp.worldwideimporters.com domain to access resources in the europe.corp.tailspintoys.com domain
Users in the rome.europe.corp.tailspintoys.com domain to access resources in the sales.corp.worldwideimporters.com domain

It does not allow:

Users in the rome.europe.corp.tailspintoys.com domain or europe.corp.tailspintoys.com domain to access resources in the corp.worldwideimporters.com domain
Users in the sales.corp.worldwideimporters.com domain to access resources in either the corp.tailspintoys.com or rome.europe.corp.tailspintoys.com domain

When a trust is established between a domain in a forest and a domain outside of that forest, security principals from the external domain can access resources in the internal domain. Active Directory creates a foreign security principal object in the internal domain to represent each security principal from the trusted external domain. These foreign security principals can become members of domain local groups in the internal domain. Directory objects for foreign security principals are created by Active Directory and should not be manually modified. You can view foreign security principal objects from Active Directory Users and Computers by enabling advanced features.

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

External Trust Between Domains in a 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.

A non-Windows Kerberos realm trust relationship has the following characteristics:

It is used only by the Kerberos V5 authentication protocol. It is not used by NTLM or other authentication protocols.
It is one-way by default. One-way trust relationships must be established in each direction to create a two-way trust relationship. In Windows Server 2003 you can create both sides of the two-way realm trust at once by using the New Trust Wizard.
It is nontransitive by default, but can be made transitive.
When the direction of trust is from a non-Windows Kerberos realm to a Windows Server 2003 domain, the non-Windows Kerberos realm trusts all security principals in the Windows Server 2003 domain.
When the direction of trust is from a Windows Server 2003 domain to a non-Windows Kerberos realm, account mappings in Active Directory are used to map a foreign Kerberos identity in a trusted non-Windows Kerberos realm to a local account identity in a Windows Server 2003 domain.
The Windows Server 2003 domain uses only the account to which the non-Windows principal is mapped (the proxy account) to evaluate access to domain objects that have security descriptors. This is required because non-Windows Kerberos tickets do not contain all of the authorization data that is needed for Windows Server 2003. All such Windows Server 2003 proxy accounts can be used in groups and on access control lists (ACLs) to control access on behalf of the non-Windows security principal. MIT account mappings are managed through Active Directory Users and Computers.
When the direction of trust is from a non-Windows Kerberos realm to a Windows Server 2003 domain, users in the Windows Server 2003 domain can access resources in the non-Windows Kerberos realm, as is the case for Realm 1 in the following illustration. When the direction of trust is from a Windows Server 2003 domain to a non-Windows Kerberos realm, users in the non-Windows Kerberos realm can access the resources in the Windows Server 2003 domain, as is the case for Realm 1 and Realm 2.

Transitive and Non-Transitive Realm Trusts from a Domain in a Windows Server 2003 Forest

This configuration allows:

Users in Realm 1 and Realm 2 to access resources in the europe.corp.tailspintoys.com domain
Users in the europe.corp.tailspintoys.com domain to access resources in Realm 1

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.

Forest trusts can provide the following benefits:

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.

Two Forest Trusts Between Three Windows Server 2003 Forests

Two Forest Trusts Between Windows Server Forests

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:

Users in Forest 2 to access resources in any domain in either Forest 1 or Forest 3
Users in Forest 3 to access resources in any domain in Forest 2
Users in Forest 1 to access resources in any domain in Forest 2

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.

Trust Processes and Interactions

Many inter-domain and inter-forest transactions depend on domain or forest trusts in order to complete various tasks. This section describes the processes and interactions that occur as resources are accessed across trusts and authentication referrals are evaluated.

Overview of Authentication Referral Processing

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:

Is 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.
Does 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.

NTLM Referral Processing

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:

Does 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.
Does 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.

Other Authentication Protocol Referral Processing

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.

Kerberos-Based Processing of Authentication Requests Over Domain Trusts

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.

Kerberos Authentication Process Over Domain Trusts

User1 logs on to Workstation1 using credentials from the europe.corp.tailspintoys.com domain. As part of this process, the authenticating domain controller issues User1 a ticket-granting ticket (TGT). This ticket is required for User1 to be authenticated to resources. The user then attempts to access a shared resource (\\fileserver1\share) on a file server located in the asia.corp.tailspintoys.com domain.
Workstation1 contacts the Kerberos Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer1 service principal name (SPN).
ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the forest contain this SPN. The global catalog sends the requested information back to ChildDC1.
ChildDC1 sends the referral to Workstation1.
Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ChildDC2) in the Child2 domain. ForestRootDC1 sends the referral to Workstation 1.
Workstation1 contacts the KDC on ChildDC2 and negotiates a ticket for the user to gain access to FileServer1.
Once Workstation1 has a service ticket, it sends the ticket to FileServer1, which reads the user’s security credentials and constructs an access token accordingly.

Each domain has its own set of security policies governing access to resources. These policies do not cross from one domain to another.

Kerberos-Based Processing of Authentication Requests Over Forest Trusts

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.

Kerberos Authentication Process Over Forest Trusts

User1 logs on to Workstation1 using credentials from the europe.corp.tailspintoys.com domain. The user then attempts to access a shared resource on FileServer1 located in the usa.corp.wingtiptoys.com forest.
Workstation1 contacts the Kerberos Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer1 SPN.
ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the tailspintoys.com forest contain this SPN. Because a global catalog is limited to its own forest, the SPN is not found. The global catalog then checks its database for information about any forest trusts that are established with its forest, and, if found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match. Once a match is found, the global catalog provides a routing hint back to ChildDC1. Routing hints help direct authentication requests toward the destination forest, and are only used when all traditional authentication channels (local domain controller and then global catalog) fail to locate a SPN.
ChildDC1 sends a referral for its parent domain back to Workstation1.
Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ForestRootDC2) in the forest root domain of the wingtiptoys.com forest.
Workstation1 contacts ForestRootDC2 in the wingtiptoys.com forest for a service ticket to the requested service.
ForestRootDC2 contacts its global catalog to find the SPN, and the global catalog finds a match for the SPN and sends it back to ForestRootDC2.
ForestRootDC2 then sends the referral to usa.corp.wingtiptoys.com back to Workstation1.
Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for User1 to gain access to FileServer1.
Once Workstation1 has a service ticket, it sends the service ticket to FileServer1, which reads User1’s security credentials and constructs an access token accordingly.

Network Ports used by Trusts

Because trusts must be deployed across various network boundaries, they might have to span one or more firewalls. When this is the case, you can either tunnel trust traffic across a firewall or open specific ports in the firewall to allow the traffic to pass through. In Windows Server 2003, this procedure is simplified through configurable remote procedure call (RPC) ports for the main trust services. The two main configurable RPC ports are the Local Security Authority RPC port and the Net Logon RPC port.

The Local Security Authority (LSA) RPC port.

This port is used for trust creation and other access to the LSA policy database.

The Net Logon RPC port.

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.

Ports Required for Trusts

Task	Outbound Ports	Inbound Ports	From–To
Set up trusts on both sides from the internal forest	LDAP (389 UDP and TCP) Microsoft SMB (445 TCP) Kerberos (88 UDP) Endpoint resolution — portmapper (135 TCP) Net Logon fixed port	N/A	Internal domain domain controllers–External domain domain controllers (all ports)
Trust validation from the internal forest domain controller to the external forest domain controller (outgoing trust only)	LDAP (389 UDP) Microsoft SMB (445 TCP) Endpoint resolution — portmapper (135 TCP) Net Logon fixed port	N/A	Internal domain domain controllers–External domain domain controllers (all ports)
Use Object picker on the external forest to add objects that are in an internal forest to groups and DACLs	N/A	LDAP (389 UDP and TCP) Windows NT Server 4.0 directory service fixed port Net Logon fixed port Kerberos (88 UDP) Endpoint resolution portmapper (135 TCP)	External server–Internal domain PDCs (Kerberos) External domain domain controllers–Internal domain domain controllers (Net Logon)
Set up trust on the external forest from the external forest	N/A	LDAP (389 UDP and TCP) Microsoft SMB (445 TCP) Kerberos (88 UDP)	External domain domain controllers–Internal domain domain controllers (all ports)
Use Kerberos authentication (internal forest client to external forest)	Kerberos (88 UDP)	N/A	Internal client–External domain domain controllers (all ports)
Use NTLM authentication (internal forest client to external forest)	N/A	Endpoint resolution – portmapper (135 TCP) Net Logon fixed port	External domain domain controllers–Internal domain domain controllers (all ports)
Join a domain from a computer in the internal network to an external domain	LDAP (389 UDP and TCP) Microsoft SMB (445 TCP) Kerberos (88 UDP) Endpoint resolution — portmapper (135 TCP) Net Logon fixed port Windows NT Server 4.0 directory service fixed port	N/A	Internal client–External domain domain controllers (all ports)

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.