Active Directory Domains and Trusts

Active Directory® Domains and Trusts is the Microsoft Management Console (MMC) snap-in that you can use to administer domain trusts, domain and forest functional levels, and user principal name (UPN) suffixes.

  • Managing Domains and Forests

  • Managing Trusts

  • Managing Forest Trusts

  • Troubleshooting Active Directory Domains and Trusts

  • Resources for Active Directory Domains and Trusts

  • User Interface: Active Directory Domains and Trusts


Managing Domains and Forests

You can use Active Directory Domains and Trusts to view and manage domain and forest functional levels and create user principal name (UPN) suffixes.

  • Understanding Domain and Forest Functionality

  • Raise the Domain Functional Level

  • Raise the Forest Functional Level

  • Add User Principal Name Suffixes


Understanding Domain and Forest Functionality

Domain and forest functionality

Domain and forest functionality, which is available in Windows Server® 2008 Active Directory Domain Services (AD DS), provides a way to enable domain-wide features or forest-wide Active Directory features in your network environment. Different levels of domain functionality and forest functionality are available, depending on your network environment.

If all the domain controllers in your domain or forest are running Windows Server 2008 or Microsoft® Windows Server® 2003 and the domain and forest functional level is set to Windows Server 2008 or Windows Server 2003, all domain-wide features and forest-wide features are available. When Microsoft Windows® 2000 domain controllers are included in your domain or forest with domain controllers running Windows Server 2008 or Windows Server 2003, Active Directory features are limited. For more information about how to enable domain-wide features or forest-wide features, see Raise the Domain Functional Level and Raise the Forest Functional Level.

Domain functionality

Domain functionality enables features that affect the entire domain and that domain only. In Windows Server 2008 AD DS, three domain functional levels are available: Windows 2000 native (the default), Windows Server 2003, and Windows Server 2008.

The following table lists the domain functional levels and their corresponding supported domain controllers:

Domain functional level | Domain controllers supported
Windows 2000 native | Windows 2000 Windows Server 2003 Windows Server 2008
Windows Server 2003 | Windows Server 2003 Windows Server 2008
Windows Server 2008 | Windows Server 2008

When you raise the domain functional level, domain controllers running earlier operating systems cannot be introduced into the domain. For example, if you raise the domain functional level to Windows Server 2003, you cannot add domain controllers running Windows 2000 Server to the domain. If you raise the domain functional level to Windows Server 2008, you cannot add domain controllers running Windows Server 2003 to the domain.

The following table describes the domain-wide features that are enabled for the Windows Server 2008 AD DS domain functional levels.

Domain functional level Enabled features

Windows 2000 native

All default Active Directory features and the following features:

  • Universal groups are enabled for both distribution groups and security groups.

  • Group nesting.

  • Group conversion is enabled, which makes conversion possible between security groups and distribution groups.

  • Security identifier (SID) history.

Windows Server 2003

All default Active Directory features, all features from the Windows 2000 native domain functional level, plus the following features:

  • The availability of the domain management tool, Netdom.exe, to prepare for domain controller rename.

  • Update of the logon time stamp. The lastLogonTimestamp attribute is updated with the last logon time of the user or computer. This attribute is replicated within the domain.

  • The ability to set the userPassword attribute as the effective password on the inetOrgPerson object and user objects.

  • The ability to redirect Users and Computers containers. By default, two well-known containers are provided for housing computer and user/group accounts: cn=Computers,<domain root> and cn=Users,<domain root>. This feature makes it possible to define a new well-known location for these accounts.

  • Authorization Manager can store its authorization policies in AD DS.

  • Constrained delegation is included, which makes it possible for applications to take advantage of the secure delegation of user credentials by means of the Kerberos authentication protocol. You can configure delegation to be allowed only to specific destination services.

  • Selective authentication is supported, which makes it possible to specify the users and groups from a trusted forest who are allowed to authenticate to resource servers in a trusting forest.

Windows Server 2008

All default Active Directory features, all features from the Windows Server 2003 domain functional level, plus the following features:

  • Distributed File System Replication support for SYSVOL, which provides more robust and detailed replication of SYSVOL contents.

  • Advanced Encryption Services (AES 128 and 256) support for the Kerberos authentication protocol.

  • Last Interactive Logon Information, which displays the time of the last successful interactive logon for a user, from what workstation, and the number of failed logon attempts since the last logon.

  • Fine-grained password policies, which make it possible for password policies and account lockout policies to be specified for users and global security groups in a domain.

Forest functionality

Forest functionality enables features across all the domains in your forest. Three forest functional levels are available: Windows 2000 (default), Windows Server 2003 interim, and Windows Server 2003. By default, forests operate at the Windows 2000 functional level. You can raise the forest functional level to Windows Server 2003 or Windows Server 2008.

The following table lists the forest functional levels and their corresponding supported domain controllers.

Forest functional level | Domain controllers supported
Windows 2000 (default) | Windows NT® 4.0 Windows 2000 Windows Server 2003 Windows Server 2008
Windows Server 2003 | Windows Server 2003 Windows Server 2008
Windows Server 2008 | Windows Server 2008

When you raise the forest functional level, domain controllers running earlier operating systems cannot be introduced into the forest. For example, if you raise the forest functional level to Windows Server 2003, domain controllers running Windows 2000 Server cannot be added to the forest.

The following table describes the forest-wide features that are enabled for the Windows 2000, Windows Server 2003, and Windows Server 2008 forest functional levels.

Forest functional level Enabled features

Windows 2000

All default Active Directory features.

Windows Server 2003

All default Active Directory features, plus the following features:

  • Forest trust

  • Domain rename

  • Linked-value replication (Changes in group membership store and replicate values for individual members instead of replicating the entire membership as a single unit.) This results in lower network bandwidth and processor usage during replication and eliminates the possibility of lost updates when different members are added or removed concurrently at different domain controllers.

  • The ability to deploy a read-only domain controller (RODC) that runs Windows Server 2008.

  • Improved Knowledge Consistency Checker (KCC) algorithms and scalability. The intersite topology generator (ISTG) uses improved algorithms that scale to support forests with a greater number of sites than can be supported at the Windows 2000 forest functional level.

  • The ability to create instances of the dynamic auxiliary class called dynamicObject in a domain directory partition.

  • The ability to convert an inetOrgPerson object instance into a User object instance, and the reverse.

  • The ability to create instances of the new group types, called application basic groups and Lightweight Directory Access Protocol (LDAP) query groups, to support role-based authorization.

  • Deactivation and redefinition of attributes and classes in the schema.

Windows Server 2008

This functional level provides all of the features that are available at the Windows Server 2003 forest functional level, but no additional features. All domains that are subsequently added to the forest, however, will operate at the Windows Server 2008 domain functional level by default.

Additional references

  • Managing Domains and Forests


Raise the Domain Functional Level

When you install Active Directory Domain Services (AD DS) on a server running Windows Server 2008, a set of basic Active Directory features is enabled by default. In addition to the basic Active Directory features on individual domain controllers, there are new domain-wide and forest-wide Active Directory features available when all domain controllers in a domain or forest are running Windows Server 2008.

For the new domain-wide features to be enabled, all domain controllers in the domain must be running Windows Server 2008, and the domain functional level must be raised to Windows Server 2008.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To raise the domain functional level

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click the domain for which you want to raise functional level, and then click Raise Domain Functional Level.

  3. In Select an available domain functional level, do one of the following:

    • To raise the domain functional level to Windows Server 2003, click Windows Server 2003, and then click Raise.

    • To raise the domain functional level to Windows Server 2008, click Windows Server 2008, and then click Raise.
Caution

Do not raise the domain functional level to a later version (such as Windows Server 2003 or Windows Server 2008) if you have or will have any domain controllers running earlier versions of Windows Server. After the domain functional level is raised, it cannot be lowered to its previous functional level.

Additional considerations

  • You can also raise the domain functional level by right-clicking a domain in the Active Directory Users and Computers snap-in, and then clicking Raise Domain Functional Level.

  • The current domain functional level is displayed under Current domain functional level in the Raise domain functional level dialog box.

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or Enterprise Admins group in AD DS, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

Additional references

  • Managing Domains and Forests


Raise the Forest Functional Level

When you install Active Directory Domain Services (AD DS) on a server running Windows Server 2008, a set of basic Active Directory features is enabled by default. In addition to the basic Active Directory features on individual domain controllers, there are new domain-wide and forest-wide Active Directory features available when all domain controllers in a domain or forest are running Windows Server 2008.

To enable new forest-wide features, all domain controllers in the forest must be running Windows Server 2008, and the forest functional level must be raised to Windows Server 2008.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To raise the forest functional level

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click Active Directory Domains and Trusts, and then click Raise Forest Functional Level.

  3. In Select an available forest functional level, do one of the following:

    • To raise the forest functional level to Windows Server 2003, click Windows Server 2003, and then click Raise.

    • To raise the forest functional level to Windows Server 2008, click Windows Server 2008, and then click Raise.
Caution

Do not raise the forest functional level to Windows Server 2008 if you have or will have any domain controllers running Windows Server 2003 or earlier. After the forest functional level is raised to Windows Server 2008, it cannot be changed back to Windows Server 2003.

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or Enterprise Admins group in AD DS, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

  • Windows 2000 native is the minimum domain functional level required for raising the forest functional level to Windows Server 2003. Likewise, Windows Server 2003 is the minimum domain functional level required for raising the forest functional level to Windows Server 2008.

  • Before you raise the forest functional level to Windows Server 2008, verify that all domains in the forest are set to the domain functional level of Windows Server 2003. Note that domains that are set to the domain functional level of Windows Server 2003 will automatically be raised to Windows Server 2008 at the same time that the forest functional level is raised to Windows Server 2008.

  • If you are not able to raise the forest functional level, you can click Save As in the Raise Forest Functional Level dialog box to save a log file that specifies which domain controllers in the forest still need to be upgraded to a later version.

  • The current forest functional level is displayed under Current forest functional level in the Raise Forest Functional Level dialog box.

Additional references

  • Managing Domains and Forests


Add User Principal Name Suffixes

You can use Active Directory Domains and Trusts to add user principal name suffixes for the existing user account. The default user principal name suffix for a user account is the DNS domain name of the domain that contains the user account. You can add alternative UPN suffixes to simplify administration and user logon processes by providing a single user principal name suffix for all users. The UPN suffix is only used within the Active Directory forest, and it is not required to be a valid DNS domain name.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To add user principal name suffixes

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click Active Directory Domains and Trusts, and then click Properties.

  3. On the UPN Suffixes tab, type an alternative user principal name (UPN) suffix for the forest, and then click Add.

  4. Repeat step 3 to add additional alternative UPN suffixes.

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

  • UPN suffixes should conform to Domain Name System (DNS) conventions for valid characters and syntax.

Additional references

  • Managing Domains and Forests


Managing Trusts

You can use Active Directory Domains and Trusts to manage domain trusts.

  • Understanding Trusts

  • Understanding Trust Types

  • Understanding Trust Direction

  • Understanding Trust Transitivity

  • Understanding When to Create an External Trust

  • Understanding When to Create a Shortcut Trust

  • Understanding When to Create a Realm Trust

  • Create a Shortcut Trust

  • Create an External Trust

  • Create a Realm Trust

  • Verify a Trust

  • Remove a Trust

  • Select the Scope of Authentication for Users


Understanding Trusts

Trusts

A trust is a relationship, which you establish between domains, that makes it possible for users in one domain to be authenticated by a domain controller in the other domain.

Trusts in Windows NT

In the Windows NT 4.0 operating system, trusts are limited to two domains, and the trust relationship is nontransitive and one-way. In the following illustration, the nontransitive, one-way trust is shown by the straight arrow pointing to the trusted domain.

Direction of trust path

Trusts in Windows 2000 Server, Windows Server 2003, and Windows Server 2008 operating systems

All trusts in Windows 2000 Server, Windows Server 2003, and Windows Server 2008 forests are transitive, two-way trusts. Therefore, both domains in a trust relationship are trusted. As shown in the following illustration, this means that if Domain A trusts Domain B and Domain B trusts Domain C, users from Domain C can access resources in Domain A (when they are assigned the proper permissions). Only members of the Domain Admins group can manage trust relationships.

Transitive trusts in a domain tree

Trust protocols

A domain controller running Windows Server 2008 authenticates users and applications using one of two protocols: the Kerberos version 5 (V5) protocol or NTLM. The Kerberos V5 protocol is the default protocol for computers running Windows 2000, Windows XP Professional, Windows Server 2003, or Windows Server 2008. If any computer in a transaction does not support the Kerberos V5 protocol, the NTLM protocol is used.

With the Kerberos V5 protocol, the client requests a ticket from a domain controller in its account domain to the server in the trusting domain. This ticket is issued by an intermediary that is trusted by the client and the server. The client presents this trusted ticket to the server in the trusting domain for authentication. For more information, see Kerberos V5 authentication (http://go.microsoft.com/fwlink/?LinkId=81795).

When a client tries to access resources on a server in another domain using NTLM authentication, the server that contains the resource must contact a domain controller in the client account domain to verify the account credentials.

Trusted domain objects

Trusted domain objects (TDOs) are objects that represent each trust relationship within a particular domain. Each time that a trust is established, a unique TDO is created and stored in its domain (in the System container). Attributes such as trust transitivity, type, and the reciprocal domain names are represented in the TDO.

Forest trust TDOs store additional attributes to identify all the trusted namespaces from its partner forest. These attributes include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security identifier (SID) namespaces.

For more information about domain trusts, see Trust Technologies (http://go.microsoft.com/fwlink/?LinkId=92695). For more information about trust relationships, see Designing a Resource Authorization Strategy (http://go.microsoft.com/fwlink/?LinkId=92696).

Additional references

  • Managing Trusts


Understanding Trust Types

Trust Types

You can use the New Trust Wizard or the Netdom command-line tool to create four types of trusts: external trusts, realm trusts, forest trusts, and shortcut trusts. The following table describes these trust types.

Trust type | Transitivity | Direction | Description
External | Nontransitive | One-way or two-way | Use external trusts to provide access to resources that are located on a Windows NT 4.0 domain or a domain that is located in a separate forest that is not joined by a forest trust. For more information, see Understanding When to Create an External Trust.
Realm | Transitive or nontransitive | One-way or two-way | Use realm trusts to form a trust relationship between a non-Windows Kerberos realm and a Windows Server 2008 domain. For more information, see Understanding When to Create a Realm Trust.
Forest | Transitive | One-way or two-way | Use forest trusts to share resources between forests. If a forest trust is a two-way trust, authentication requests that are made in either forest can reach the other forest. For more information, see Understanding When to Create a Forest Trust.
Shortcut | Transitive | One-way or two-way | Use shortcut trusts to improve user logon times between two domains within a Windows Server 2008 forest. This is useful when two domains are separated by two domain trees. For more information, see Understanding When to Create a Shortcut Trust.

When you create external trusts, shortcut trusts, realm trusts, or forest trusts, you have the option to create each side of the trust separately or both sides of a trust simultaneously.

If you choose to create each side of the trust separately, you must run the New Trust Wizard twice—once for each domain. When you create trusts using the method, you must supply the same trust password for each domain. As a security best practice, all trust passwords should be strong passwords. For more information, see Strong passwords (http://go.microsoft.com/fwlink/?LinkId=92697).

If you choose to create both sides of the trust simultaneously, you run the New Trust Wizard once. When you choose this option, a strong trust password is automatically generated for you. You must have the appropriate administrative credentials for the domains between which you are creating the trust.

For more information about trusts, see Understanding Trust Transitivity and Understanding Trust Direction.

Additional references

  • Managing Trusts


Understanding Trust Direction

Trust Direction

The trust type and its assigned direction affect the trust path that is used for authentication. A trust path is a series of trust relationships that authentication requests must follow between domains. Before a user can access a resource in another domain, the security system on domain controllers running Windows Server 2008 must determine whether the trusting domain (the domain that contains the resource that the user is trying to access) has a trust relationship with the trusted domain (the user's logon domain). To determine this, the security system computes the trust path between a domain controller in the trusting domain and a domain controller in the trusted domain. In the following illustration, the trust path is indicated by an arrow that shows the direction of the trust.

Direction of trust path

All domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain.

One-way trust

A one-way trust is a unidirectional authentication path that is created between two domains. This means that 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 a nontransitive trust or a transitive trust, depending on the type of trust that is created. For more information about trust types, see Understanding Trust Types.

Two-way trust

All domain trusts in a Windows Server 2008 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 either nontransitive or transitive, depending on the type of trust that is created. For more information, see Understanding Trust Types.

A Windows Server 2008 domain can establish one-way or two-way trusts with the following domains and realms:

  • Windows Server 2008 domains in the same forest

  • Windows Server 2008 domains in a different forest

  • Windows Server 2003 domains in the same forest

  • Windows Server 2003 domains in a different forest

  • Windows NT 4.0 domains

  • Kerberos version 5 (V5) realms

For more information about the Kerberos V5 protocol, see Kerberos V5 authentication (http://go.microsoft.com/fwlink/?LinkId=92699).

Additional references

  • Managing Trusts


Understanding Trust Transitivity

Trust transitivity

Transitivity determines whether a trust can be extended outside the two domains between which the trust was formed. You can use a transitive trust to extend trust relationships with other domains. You can use a nontransitive trust to deny trust relationships with other domains.

Transitive trust

Each time that 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 that is 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. Therefore, accounts from any domain in the forest can be authenticated at 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.

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

  • Shortcut trust: A transitive trust between a domain in the same domain tree or forest that shortens the trust path in a large and complex domain tree or forest.

  • Forest trust: A transitive trust between a forest root domain and a second forest root domain.

  • Realm trust: A transitive trust between an Active Directory domain and a Kerberos V5 realm. For more information about Kerberos V5 realms, see Kerberos V5 authentication (http://go.microsoft.com/fwlink/?LinkId=92699).

The following illustration shows a two-way, transitive trust relationship between the Domain A tree and the Domain 1 tree. All domains in the Domain A tree and all domains in the Domain 1 tree have transitive trust relationships by default. As a result, users in the Domain A tree can access resources in domains in the Domain 1 tree, and users in the Domain 1 tree can access resources in the Domain A tree when the proper permissions are assigned at the resource.

A two-way, transitive trust path connects domains

For more information about trust types, see Understanding Trust Types.

Nontransitive trust

A nontransitive trust is restricted by the two domains in the trust relationship. It 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.

In summary, nontransitive domain trusts are the only form of trust relationship that is possible between the following:

  • A Windows Server 2008 domain and a Windows NT domain

  • A Windows Server 2008 domain in one forest and a domain in another forest (when the forests are not joined by a forest trust)

You can use the New Trust Wizard to manually create the following nontransitive trusts:

  • External trust: A nontransitive trust between a Windows Server 2008 domain and a Windows NT domain or a Windows 2000 domain, Windows Server 2003 domain, or Windows Server 2008 domain in another forest.

  • Realm trust: A nontransitive trust between an Active Directory domain and a Kerberos version 5 (V5) realm. For more information about Kerberos V5 realms, see Kerberos V5 authentication (http://go.microsoft.com/fwlink/?LinkId=92699).

For more information about trust types, see Understanding Trust Types.

Additional references

  • Managing Trusts


Understanding When to Create an External Trust

When to create an external trust

You can create an external trust to form a one-way or two-way, nontransitive trust with domains that are outside your forest. External trusts are sometimes necessary when users need access to resources in a Windows NT 4.0 domain or in a domain that is located in a separate forest that is not joined by a forest trust, as shown in the following illustration.

When you establish a trust between a domain in a particular forest and a domain outside that forest, security principals from the external domain can access resources in the internal domain. Active Directory Domain Services (AD DS) 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. Domain local groups can have members from domains outside the forest.

Directory objects for foreign security principals are created by AD DS, and they should not be modified manually. You can view foreign security principal objects in the Active Directory Users and Computers snap-in by enabling advanced features. (On the View menu, click Advanced Features.)

For more information about how to create an external trust, see Create an External Trust.

Additional references

  • Managing Trusts


Understanding When to Create a Shortcut Trust

When to create a shortcut trust

Shortcut trusts are one-way or two-way, transitive trusts that administrators can use to optimize the authentication process.

Authentication requests must first travel a trust path between domain trees. In a complex forest this can take time, which you can reduce with shortcut trusts. A trust path is the series of domain trust relationships that authentication requests must traverse between any two domains. Shortcut trusts effectively shorten the path that authentication requests travel between domains that are located in two separate domain trees. For more information about trust paths, see Understanding Trust Direction.

Shortcut trusts are necessary when many users in a domain regularly log on to other domains in a forest. Using the following illustration as an example, you can form a shortcut trust between domain B and domain D, between domain A and domain 1, and so on.

Shortcut trusts in a forest

For more information about how to create a shortcut trust, see Create a Shortcut Trust.

Using one-way trusts

A one-way, shortcut trust that is established between two domains in separate domain trees can reduce the time that is necessary to fulfill authentication requests—but in only one direction. For example, when a one-way, shortcut trust is established between domain A and domain B, authentication requests that are made in domain A to domain B can use the new one-way trust path. However, authentication requests that are made in domain B to domain A must still travel the longer trust path.

Using two-way trusts

A two-way, shortcut trust that is established between two domains in separate domain trees reduces the time that is necessary to fulfill authentication requests that originate in either domain. For example, when a two-way trust is established between domain A and domain B, authentication requests that are made from either domain to the other domain can use the new, two-way trust path.

Additional references

  • Managing Trusts


Understanding When to Create a Realm Trust

When to create a realm trust

You can establish a realm trust between any non-Windows Kerberos version 5 (V5) realm and a Windows Server 2008 domain. This trust relationship allows cross-platform interoperability with security services that are based on other versions of the Kerberos V5 protocol, for example, UNIX and MIT implementations. Realm trusts can switch from nontransitive to transitive and back. Realm trusts can also be either one-way or two-way.

For information about how to create a realm trust, see Create a Realm Trust.

Additional references

  • Managing Trusts


Create a Shortcut Trust

You can use Active Directory Domains and Trusts to create shortcut trusts.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Creating a shortcut trust

  • Using the Windows interface

  • Using a command line

To create a shortcut trust using the Windows interface

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click the domain node for the domain that you want to establish a shortcut trust with, and then click Properties.

  3. On the Trusts tab, click New Trust, and then click Next.

  4. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of the domain, and then click Next.

  5. On the Direction of Trust page, do one of the following:

    • To create a two-way shortcut trust, click Two-way.

      Users in this domain and users in the specified domain will be able to use this trust path.

    • To create a one-way incoming shortcut trust, click One-way:incoming.

      Users in the specified domain will not be able to use this trust path.

    • To create a one-way outgoing shortcut trust, click One-way:outgoing.

      Users in this domain will not be able to use this trust path.

  6. Continue to follow the instructions in the wizard.

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

  • If you have the appropriate administrative credentials for each domain, you can create both sides of a shortcut trust at the same time by clicking Both this domain and the specified domain on the Sides of Trust page.

Additional references

  • Managing Trusts

To create a shortcut trust using a command line

  1. Open a command prompt. To open a command prompt, click Start, click Run, type cmd, and then click OK.

  2. Type the following command, and then press ENTER:

    netdom trust <TrustingDomainName> /d:<TrustedDomainName> /add

Parameter | Description
netdom trust | Manages or verifies the trust relationship between domains.
<TrustingDomainName> | Specifies the DNS name (or NetBIOS name) of the trusting domain in the trust that is being created.
/d: | Specifies that the DNS domain name that follows is a trusted domain.
<TrustedDomainName> | Specifies the DNS name (or NetBIOS name) of the domain that will be trusted in the trust being created.
/add | Specifies that a trust be created.

To view the complete syntax for this command, and for information about entering user account information, at a command prompt, type the following command, and then press ENTER:

netdom trust | more

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or Enterprise Admins group in AD DS, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support. You can verify shortcut trusts, external trusts, and forest trusts, but not realm trusts.

  • You can use other parameters to assign a password or determine the direction of the trust. For example, to make the trust in this procedure a two-way, transitive trust, use the following syntax:

    netdom trust <TrustingDomainName> /d: <TrustedDomainName> /add /twoway

Additional references

  • Managing Trusts


Create an External Trust

You can use Active Directory Domains and Trusts to create external trusts.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Creating an external trust

  • Using the Windows interface

  • Using a command line

To create an external trust using the Windows interface

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties.

  3. On the Trusts tab, click the New Trust, and then click Next.

  4. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of the domain, and then click Next.

  5. On the Trust Type page, click External trust, and then click Next.

  6. On the Direction of trust page, do one of the following:

    • To create a two-way, external trust, click Two-way.

      Users in this domain and users in the specified domain will be able to access resources in either domain.

    • To create a one-way, incoming external trust, click One-way:incoming.

      Users in the specified domain will not be able to access any resources in this domain.

    • To create a one-way, outgoing external trust, click One-way:outgoing.

      Users in this domain will not be able to access any resources in the specified domain.

  7. Continue to follow the instructions in the wizard.

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or the Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

  • If you have the appropriate administrative credentials for each domain, you can create both sides of an external trust at the same time by clicking Both this domain and the specified domain on the Sides of Trust page.

  • If you want to allow users from the specified domain to obtain access to all the resources in this domain, click Allow authentication for all resources on the Outgoing Trust Properties page. Use this option when both domains belong to the same organization.

  • If you want to restrict users in the specified domain from obtaining access to any of the resources in this domain, click Allow authentication only for selected resources in the local domain on the Outgoing Trust Properties page. Use this option when each domain belongs to a separate organization.

Additional references

  • Managing Trusts

To create an external trust using a command line

  1. Open a command prompt. To open a command prompt, click Start, click Run, type cmd, and then click OK.

  2. Type the following command, and then press ENTER:

    netdom trust <TrustingDomainName> /d:<TrustedDomainName> /add

Parameter | Description
netdom trust | Manages or verifies the trust relationship between domains.
<TrustingDomainName> | Specifies the DNS name (or NetBIOS name) of the trusting domain in the trust that is being created.
/d: | Specifies that the DNS domain name that follows is a trusted domain.
<TrustedDomainName> | Specifies the DNS name (or NetBIOS name) of the domain that will be trusted in the trust that is being created.
/add | Specifies that a trust be created.

To view the complete syntax for this command, and for information about entering user account information, at a command prompt, type the following command, and then press ENTER:

netdom trust | more

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or the Enterprise Admins group in AD DS, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support. You can verify trusts for shortcut, external, and forest trusts but not realm trusts.

  • You can use other parameters to assign a password or determine the direction of the trust. For example, to make a two-way, transitive trust, use the following syntax:

    netdom trust <TrustingDomainName> /d:<TrustedDomainName> /add /twoway

Additional references

  • Managing Trusts


Create a Realm Trust

You can use Active Directory Domains and Trusts to create realm trusts.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Creating a realm trust

  • Using the Windows interface

  • Using a command line

To create a realm trust using the Windows interface

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click the domain that you want to administer, and then click Properties.

  3. On the Trusts tab, click New trust, and then click Next.

  4. On the Trust Name page, type the realm name for the target realm, and then click Next.

  5. On the Trust Type page, select the Realm trust option, and then click Next.

  6. On the Transitivity of Trust page, do one of the following:

    • To form a trust relationship with the domain and the specified realm, click Nontransitive, and then click Next.

    • To form a trust relationship with the domain and the specified realm and all trusted realms, click Transitive, and then click Next.

  7. On the Direction of Trust page, do one of the following:

    • To create a two-way, realm trust, click Two-way.

      Users in this domain and users in the specified realm will be able to access resources in either domain or realm.

    • To create a one-way, incoming realm trust, click One-way:incoming.

      Users in the specified realm will not be able to access any resources in this domain.

    • To create a one-way, outgoing realm trust, click One-way:outgoing.

      Users in this domain will not be able to access any resources in the specified realm.

  8. Continue to follow the instructions in the wizard.

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

Additional references

  • Managing Trusts

To create a realm trust using a command line

  1. Open a command prompt. To open a command prompt, click Start, click Run, type cmd, and click OK.

  2. Type the following command, and then press ENTER:

    netdom trust <TrustingDomainName> /d:<TrustedDomainName> /add /realm /PasswordT:<NewRealmTrustPassword>

Parameter | Description
netdom trust | Manages or verifies trust relationships between domains.
<TrustingDomainName> | Specifies the Domain Name System (DNS) name of the trusting domain in the new realm trust.
/d: | Specifies that the DNS domain name that follows is a trusted domain.
<TrustedDomainName> | Specifies the DNS name of the domain that will be trusted in the new realm trust.
/add | Specifies that a trust be created.
/realm | Indicates that the trust is to be created to a non-Windows Kerberos realm.
/PasswordT: | Specifies the new trust password. This parameter is valid only if one of the domains specified is a non-Windows Kerberos realm.
<NewRealmTrustPassword> | Specifies the trust password for the new realm trust. This password must match the password that is used in the Kerberos realm.

To view the complete syntax for this command, and for information about entering user account information, at a command prompt, type the following command, and then press ENTER:

netdom trust | more

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or Enterprise Admins group in AD DS, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support. You can verify shortcut trusts, external trusts, and forest trusts but not realm trusts.

  • You can use other parameters to assign a password or determine the direction of the trust. For example, to make the previous trust a two-way, transitive trust, use the following syntax:

    netdom trust <TrustingDomainName> /d:<TrustedDomainName> /add /realm /twoway

Additional references

  • Managing Trusts


Verify a Trust

You can use Active Directory Domains and Trusts to verify whether the newly added shortcut, external, and forest trusts were created successfully.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Verifying a trust

  • Using the Windows interface

  • Using a command line

To verify a trust using the Windows interface

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click the domain that contains the trust that you want to verify, and then click Properties.

  3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the trust to be verified, and then click Properties.

  4. Click Validate.

  5. Do one of the following, and then click OK:

    • Click No, do not validate the incoming trust.

      If you select this option, we recommend that you repeat this procedure for the reciprocal domain.

    • Click Yes, validate the incoming trust.

      If you select this option, you must type a user account and password with administrative credentials for the reciprocal domain.

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or the Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

  • You can verify trusts for shortcut trusts, external trusts, and forest trusts, but not realm trusts.

Additional references

  • Managing Trusts

To verify a trust using a command line

  1. Open a command prompt. To open a command prompt, click Start, click Run, type cmd, and then click OK.

  2. Type the following command, and then press ENTER:

    netdom trust <TrustingDomainName> /d:<TrustedDomainName> /verify

Parameter | Description
netdom trust | Managers or verifies the trust relationship between domains.
<TrustingDomainName> | Specifies the Domain Name System (DNS) name of the trusting domain in the trust that is being verified.
/d: | Specifies that the DNS domain name that follows is the trusted domain.
<TrustedDomainName> | Specifies the DNS name of the domain that is trusted in the trust that is being verified.
/verify | Verifies that the trust is operating properly.

To view the complete syntax for this command, and for information about entering user account information, at a command prompt, type the following command, and then press ENTER:

netdom trust | more

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or the Enterprise Admins group in AD DS, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

  • You can verify trusts for shortcut, external, and forest trusts but not realm trusts.

Additional references

  • Managing Trusts


Remove a Trust

You can use Active Directory Domains and Trust to remove trusts.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Removing a trust

  • Using the Windows interface

  • Using a command line

To remove a trust using the Windows interface

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click the domain that contains the trust that you want to remove, and then click Properties.

  3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the trust to be removed, and then click Remove.

  4. Do one of the following, and then click OK:

    • Click No, remove the trust from the local domain only.

      If you select this option, we recommend that you repeat this procedure for the reciprocal domain.

    • Click Yes, remove the trust from both the local domain and the other domain.

      If you select this option, you must type a user account and password with administrative credentials for the reciprocal domain.

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or the Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

  • It is not possible to revoke the default two-way, transitive trusts between domains in a forest. It is possible to delete explicitly created shortcut trusts.

Additional references

  • Managing Trusts

To remove a trust using a command line

  1. Open a command prompt. To open a command prompt, click Start, click Run, type cmd, and then click OK.

  2. Type the following command, and then press ENTER:

    netdom trust <TrustingDomainName> /d:<TrustedDomainName> /remove /UserD:<User> /PasswordD:*<Password>

Parameter | Description
netdom trust | Manages or verifies trust relationships between domains.
<TrustingDomainName> | Specifies the Domain Name System (DNS) name of the trusting domain in the trust that is being removed.
/d: | Specifies that the DNS domain name that follows is a trusted domain.
<TrustedDomainName> | Specifies the DNS name of the domain that is trusted in the trust that is being removed.
/remove | Specifies that a trust be removed.
<User> | Specifies the user account with administrative credentials for the reciprocal domain.
/UserD: | Specifies the user account that is used to make the connection with the trusted domain.
/PasswordD:* | The password of the user account that is specified by /UserD.
<Password> | Specifies the password for the user account with administrative credentials for the reciprocal domain.

To view the complete syntax for this command, and for information about entering user account information, at a command prompt, type the following command, and then press ENTER:

netdom trust | more

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or the Enterprise Admins group in AD DS, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support. You can verify trusts for shortcut trusts, external trusts, and forest trusts but not realm trusts.

Additional references

  • Managing Trusts


Select the Scope of Authentication for Users

You can use Active Directory Domains and Trusts to specify the scope of authentication for users that are authenticating through external trusts or forest trusts.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To select the scope of authentication using the Windows interface

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click the domain node for the domain that you want to administer, and then click Properties.

  3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), do one of the following:

    • To select the scope of authentication for users that are authenticating through an external trust, click the external trust that you want to administer, and then click Properties. On the Authentication tab, click either Domain-wide authentication or Selective authentication.

    • To select the scope of authentication for users that are authenticating through a forest trust, click the forest trust that you want to administer, and then click Properties. On the Authentication tab, click either Forest-wide authentication or Selective authentication.

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

  • For an external trust, if you select Selective authentication, you must enable permissions manually on the local domain and on the resource to which you want users in the external domain to have access.

  • For a forest trust, if you select Selective authentication, you must enable permissions manually on each domain and resource in the local forest to which you want users in the second forest to have access.

  • You can use selective authentication only on external trusts and forest trusts.

Additional references

  • Managing Trusts


Managing Forest Trusts

You can use Active Directory Domains and Trusts to administer forest trusts.

  • Understanding When to Create a Forest Trust

  • Checklist: Create a Forest Trust

  • Create a Forest Trust

  • Change the Routing Status of a Name Suffix

  • Enable or Disable an Existing Name Suffix from Routing

  • Exclude Name Suffixes from Routing to a Local Forest


Understanding When to Create a Forest Trust

When to create a forest trust

You can create a forest trust only between a forest root domain in one Windows Server 2008 forest and a forest root domain in another Windows Server 2008 forest. Creating a forest trust between two Windows Server 2008 forests provides a one-way or two-way, transitive trust relationship between every domain that resides within each forest. Forest trusts are useful for application service providers, organizations undergoing mergers or acquisitions, collaborative business extranets, and organizations seeking a solution for administrative autonomy.

For more information about creating forest trusts, see Create a Forest Trust.

Using one-way, forest trusts

A one-way, forest trust between two forests allows members of the trusted forest to use resources that are 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 A (the trusted forest) and forest B (the trusting forest), members of forest A can access resources that are located in forest B, but members of forest B cannot access resources that are located in forest A, using the same trust.

Using two-way, forest trusts

A two-way, forest trust between two forests allows members from either forest to use resources that are located in the other forest, and domains in each respective forest trust domains in the other forest implicitly. For example, when a two-way, forest trust is established between forest A and forest B, members of forest A can access resources that are located in forest B, and members of forest B can access resources in forest A, using the same trust.

Additional references

  • Managing Trusts


Checklist: Create a Forest Trust

Before you create forest trusts between domains, it is important to verify that the Domain Name System (DNS) server in your environment is properly set up and configured to accept future trust relationships. Complete the tasks in this checklist in order. When a reference link takes you to a conceptual topic, return to this topic after you review the conceptual topic so that you can proceed with the remaining tasks in this checklist.

Task Reference
  • Ensure that DNS is set up properly.
  • Verify a zone delegation using the nslookup command (http://go.microsoft.com/fwlink/?LinkId=92715).
  • If there is a root DNS server that can be the root DNS server for both of the forest DNS namespaces, make it the root server by ensuring that the root zone contains delegations for each of the DNS namespaces. Also, update the root hints of all DNS servers with the new root DNS server.
  • Update root hints on the DNS server (http://go.microsoft.com/fwlink/?LinkId=92717).
  • If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are running a Windows Server 2008 operating system, configure DNS conditional forwarders in each DNS namespace to route queries for names in the other namespace.
  • Configure DNS server forwarders (http://go.microsoft.com/fwlink/?LinkId=92718).
  • If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are not running a Windows Server 2008 operating system, configure DNS secondary zones in each DNS namespace to route queries for names in the other namespace.
  • Add a secondary server for an existing zone (http://go.microsoft.com/fwlink/?LinkId=92719).
  • Create the forest trust.
  • Create a Forest Trust.


Create a Forest Trust

You can use Active Directory Domains and Trusts to create trust relationships between domains.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To create a forest trust

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click the domain that you want to administer, and then click Properties.

  3. On the Trusts tab, click New trust, and then click Next.

  4. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of the domain, and then click Next.

  5. On the Trust Type page, click Forest trust, and then click Next.

  6. On the Direction of Trust page, do one of the following:

    • To create a two-way, forest trust, click Two-way.

      Users in this forest and users in the specified forest will be able to access resources in either forest.

    • To create a one-way, incoming forest trust, click One-way:incoming.

      Users in the specified forest will not be able to access any resources in this forest.

    • To create a one-way, outgoing forest trust, click One-way:outgoing.

      Users in this forest will not be able to access any resources in the specified forest.

  7. Continue to follow the instructions in the wizard.

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

  • If you have the appropriate administrative credentials for each forest, you can create both sides of a forest trust at the same time by clicking Both this domain and the specified domain on the Sides of Trust page.

  • If you want users from the specified forest to have access to all computers in the local forest, on the Outgoing Trust Properties page, click Forest-wide authentication. This option is preferred when both forests belong to the same organization.

  • If you want to selectively limit authentication to particular users and groups from the specified forest, on the Outgoing Trust Properties page, click Selective authentication. This option is preferred if the specified forest belongs to a separate organization.

  • In addition to creating new trusts, you can modify existing trusts by clicking the Trust tab.

Additional references

  • Managing Trusts

  • Checklist: Create a Forest Trust


Change the Routing Status of a Name Suffix

You can use Active Directory Domains and Trusts to view and modify the routing status of name suffixes.

Name suffix routing is a mechanism that you can use to manage how authentication requests are routed across Windows Server 2008 forests that are joined by forest trusts. To simplify the administration of authentication requests, when you create a forest trust all unique name suffixes are routed by default. A unique name suffix is a name suffix within a forest, such as a user principal name (UPN) suffix, service principal name (SPN) suffix, or Domain Name System (DNS) forest or domain tree name, that is not subordinate to any other name suffix.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To change the routing status of a name suffix

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click the domain node for the domain that you want to administer, and then click Properties.

  3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the forest trust that you want to administer, and then click Properties.

  4. On the Name Suffix Routing tab, under Name suffixes in the x.x forest, click the suffix for which you want to modify the routing status, and then click Edit.

  5. In Existing name suffixes in x.x, click the suffix that you want to modify, and then click Enable or Disable.

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

  • You cannot enable a name suffix that is in conflict. If the conflict is with a local UPN name suffix, you must remove the local UPN name suffix before you can enable the routing name. If the conflict is with a name that is claimed by another trust partner, you must disable the name in the other trust before it can be enabled for this trust.

  • To view a log of name suffixes, DNS names, NetBIOS names, and the status that is associated with this trust, click Save As. This log can assist you in troubleshooting authentication problems.

Additional references

  • Managing Trusts


Enable or Disable an Existing Name Suffix from Routing

You can use Active Directory Domains and Trusts to modify the routing of the existing name suffixes.

Name suffix routing is a mechanism that you can use to manage how authentication requests are routed across Windows Server 2008 forests that are joined by forest trusts. To simplify the administration of authentication requests, when you create a forest trust all unique name suffixes are routed by default. A unique name suffix is a name suffix within a forest, such as a user principal name (UPN) suffix, service principal name (SPN) suffix, or Domain Name System (DNS) forest or domain tree name that is not subordinate to any other name suffix.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To enable or disable an existing name suffix from routing

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click the domain node for the domain that you want to administer, and then click Properties.

  3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the forest trust that you want to administer, and then click Properties.

  4. Click the Name Suffix Routing tab, and under Name suffixes in the x.x. forest, do one of the following:

    • To enable a name suffix, click the suffix that you want to enable, and then click Enable. If the Enable button appears dimmed, the name suffix is already enabled.

    • To disable a name suffix, click the suffix that you want to disable, and then click Disable. If the Disable button appears dimmed, the name suffix is already disabled.

Additional considerations

  • To perform this procedure, you must be a member of theAccount Operators group, Domain Admins group, or Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

  • When you disable a name suffix, all children of that DNS name will also be disabled.

  • You cannot enable a name suffix that is in conflict. If the conflict is with a local UPN name suffix, you must remove the local UPN name suffix before you can enable the routing name. If the conflict is with a name that is claimed by another trust partner, you must disable the name in the other trust before it can be enabled for this trust.

Additional references

  • Managing Trusts


Exclude Name Suffixes from Routing to a Local Forest

You can use Active Directory Domains and Trusts to exclude name suffixes from routing to a local forest.

Name suffix routing is a mechanism that you can use to manage how authentication requests are routed across Windows Server 2008 forests that are joined by forest trusts. To simplify the administration of authentication requests, when you create a forest trust all unique name suffixes are routed by default. A unique name suffix is a name suffix within a forest, such as a user principal name (UPN) suffix, service principal name (SPN) suffix, or Domain Name System (DNS) forest or domain tree name that is not subordinate to any other name suffix.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To exclude name suffixes from routing to a local forest

  1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

  2. In the console tree, right-click the domain node for the domain that you want to administer, and then click Properties.

  3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the forest trust that you want to administer, and then click Properties.

  4. Click the Name Suffix Routing tab. Under Name suffixes in the x.x. forest, click the unique name suffix for which you want to exclude the routing status, and then click Edit.

  5. In Name suffixes to exclude from routing to x.x, click Add, type a DNS name suffix that is subordinate to the unique name suffix, and then click OK.

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for "using run as" in Help and Support.

  • When you exclude a name suffix, all children of that DNS name will also be excluded.

  • To view a log of name suffixes, DNS names, NetBIOS names, and the status that is associated with this trust, click Save As. This log can assist you in troubleshooting authentication problems.

Additional references

  • Managing Trusts


Troubleshooting Active Directory Domains and Trusts

This section describes a few issues that you might encounter when you use Active Directory Domains and Trusts to manage domains and trusts.

What problem are you having?

  • Clients are not able to access resources in a domain outside the forest.

  • There are trust errors between servers and workstations.

  • There are trust errors between Windows NT 4.0 domains and Active Directory domains.

Clients are not able to access resources in a domain outside the forest.

Cause: A failure occurred on the external trust between the domains.

Solution: Reset and verify the trust between the domains. For a trust to be reset successfully, the domain controller that holds the primary domain controller (PDC) emulator operations master role (also known as flexible single master operations or FSMO) must be available.

There are trust errors between servers and workstations.

Cause: There is incorrect time synchronization between domain controllers or workstations, the server might be down, or the trust relationship might be broken.

Solution: Run the command-line tool Netdom to verify, reset, or establish the trust between computers. This command-line tool performs batch management of trusts, verifies trusts, and secures channels between computers. It can also join computers to domains. For more information, see Verify a Trust.

There are trust errors between Windows NT 4.0 domains and Active Directory domains.

Cause: Automatic trust password resets for the trust may not reach the PDC emulator master role holder.

Solution: Run Netdom to verify, reset, or establish trust between computers. This command-line tool performs batch management of trusts, verifies trusts, and secures channels between computers. It can also join computers to domains. If this does not help solve the issue, see article Q317178 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=4441).


Resources for Active Directory Domains and Trusts

For more information about objects that you manage with Active Directory Domains and Trusts, see the following resources on the Microsoft Web site:

  • For information about read-only domain controllers, see Step-by-Step Guide for Read-Only Domain Controller in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=92728).

  • For more information about the Kerberos protocol, see Kerberos Explained (http://go.microsoft.com/fwlink/?LinkId=85494).

  • For more information about strong passwords, see Strong passwords: How to create and use them (http://go.microsoft.com/fwlink/?LinkID=58293).

  • For more information about zone properties, see Configure Zone Properties (http://go.microsoft.com/fwlink/?LinkId=92779).

  • For more information about updating root hints on the DNS server, see Update root hints on the DNS server (http://go.microsoft.com/fwlink/?LinkId=92717).

  • For more information about DNS server forwarders, see Configure DNS server forwarders (http://go.microsoft.com/fwlink/?LinkId=92718).

  • For more information about adding a secondary server to an existing zone, see Add a secondary server for an existing zone (http://go.microsoft.com/fwlink/?LinkId=92719).


User Interface: Active Directory Domains and Trusts

  • Raise Forest Functional Level Dialog Box

  • Change Forest Dialog Box

  • Active Directory Domains and Trusts - UPN Suffixes Tab

  • Domain Properties - Trusts Tab

  • Trusts Properties - General Tab

  • Trust Properties - Name Suffix Routing Tab

  • SID Filtering Dialog Box - Securing External Trusts


Raise Forest Functional Level Dialog Box

Item Details

Forest name

Specifies the name of the selected forest.

Current forest functional level

Specifies the current setting of the forest functional level.

After you set the forest functional level to a certain value, it cannot be rolled back or lowered. For example, if the forest functional level is set to Windows Server 2008, it cannot be rolled back to Windows Server 2003 or Windows 2000. Consequently, if the forest functional level is set to Windows Server 2003, it cannot be rolled back to Windows 2000.

The functional level of a domain or forest only defines the set of Windows operating systems that can run on domain controllers. It does not define the client operating systems that are supported in the forest.


Change Forest Dialog Box

Item | Details
Root domain | Displays the fully qualified domain name (FQDN) of the forest root domain that is the current focus of the Active Directory Domains and Trusts snap-in. To change the focus of the snap-in to another forest root domain, type the full Domain Name System (DNS) name of the other forest root domain here.
Save this domain setting for the current console | Specifies whether to save the current domain focus for the given snap-in. If you select this option, the next time that you open the snap-in, it will focus on the domain that is listed here.


Active Directory Domains and Trusts - UPN Suffixes Tab

Item | Details
Alternative UPN Suffixes | Provides a space for you to type the name of the alternative user principal name (UPN) suffix.
Add | Click to add the alternative UPN suffix.
Remove | Click to remove the selected alternative UPN suffix.


Domain Properties - Trusts Tab

Item Details

Domains trusted by this domain (outgoing trusts)

  • Domain Name: Lists all the domains that are trusted by the selected domain.

  • Trust Type: Specifies the type of trust between the selected domain and the domain that it trusts.

  • Transitive: Specifies whether the trust between the selected domain and the domain it trusts is transitive.

  • Properties: Click to view the properties of the selected trusted domain.

  • Remove: Click to remove the selected trusted domain name from the list of trusted domains.

Domains that trust this domain (incoming trusts)

  • Domain Name: Lists all the domains that trust the selected domain.

  • Trust Type: Specifies the type of trust between the selected domain and the domain that trusts it.

  • Transitive: Specifies whether the trust between the selected domain and the domain that trusts it is transitive.

  • Properties: Click to view the properties of the domain that trusts the selected domain.

  • Remove: Click to remove the domain name from the list of domains that trust the selected domain.

New Trust

Click to start the New Trust Wizard.


Trusts Properties - General Tab

Item Details

This Doman:

  • Displays the fully qualified domain name (FQDN) of the domain that is the current focus of the Active Directory Domains and Trusts snap-in.

Other Domain:

Displays the FQDN of the other domain in the selected trust relationship.

Trust type

Specifies the type of the selected trust relationship.

The other domain supports Kerberos AES Encryption

Specifies whether the other domain in the selected trust relationship supports Kerberos AES Encryption.

Note

Advanced Encryption Standard (AES) is a new encryption algorithm that has been standardized by NIST and is expected to be widely used in the next several years. For more information about Kerberos authentication, see Kerberos Explained (http://go.microsoft.com/fwlink/?LinkId=85494).

Direction of trust

Specifies the direction of the selected trust relationship.

Transitivity of trust

Specifies whether the selected trust relationship is transitive.

Validate

Click to confirm or reset the selected trust relationship.

Save As

Click to save a file with the details about the status of the names that is associated with the selected trust relationship.


Trust Properties - Name Suffix Routing Tab

Item Details

Name suffixes in the <DNS name> forest:

  • Suffix: A list of name suffixes in the local forest.

  • Routing: Specifies the routing status of the corresponding name suffix.

  • Status: Specifies the status (conflicts, whether the name suffix is newly created, and so on) of the corresponding name suffix.

Enable

Click to set the routing status of the selected name suffix to Enabled.

Disable

Click to set the routing status of the selected name suffix to Disabled.

Refresh

Click to refresh the list of name suffixes in the local forest.

Edit

Click to exclude name suffixes from routing to the local forest.


SID Filtering Dialog Box - Securing External Trusts

To improve the security of Active Directory forests, by default domain controllers running Windows Server 2008 enable security identifier (SID) filtering on all new, outgoing, external trusts. When SID filtering is applied to outgoing external trusts, malicious users who have domain-administrator-level access in the trusted domain are more likely to be prevented from granting—to themselves or to other user accounts in their domain—elevated user rights to the trusting domain.

Understanding the threat

When SID filtering is not enabled on outgoing external trusts, a malicious user with administrative credentials in the trusted domain may be able to "sniff" network authentication requests from the trusting domain to obtain the SID information of a user, such as a domain administrator, who has full access to resources in the trusting domain.

After obtaining the domain administrator's SID from the trusting domain, a malicious user with administrative credentials can add that SID to a user account's SIDHistory attribute in the trusted domain and attempt to gain full access to the trusting domain and the resources in that domain. In this scenario, a malicious user who has domain administrator credentials in the trusted domain is a threat to the entire trusting forest.

SID filtering helps neutralize the threat of malicious users in the trusted domain using the SIDHistory attribute to gain elevated privileges.

How SID filtering works

When security principals are created in a domain, the domain SID is included in the security principal's SID to identify the domain in which the security principal was created. The domain SID is an important characteristic of a security principal because the Windows security subsystem uses it to verify the security principal's authenticity.

In a similar fashion, outgoing external trusts that are created from the trusting domain use SID filtering to verify that incoming authentication requests from security principals in the trusted domain contain only the SIDs of security principals in the trusted domain. This is accomplished through a comparison of the SIDs of the incoming security principal to the domain SID of the trusted domain. If any of the security principal SIDs includes a domain SID other than the SID from the trusted domain, the trust removes the offending SID.

SID filtering helps ensure that any misuse of the SIDHistory attribute on security principals (including inetOrgPerson) in the trusted forest cannot pose a threat to the integrity of the trusting forest.

The SIDHistory attribute can be useful to domain administrators when they migrate user accounts and group accounts from one domain to another. Domain administrators can add SIDs from an old user account or group account to the SIDHistory attribute of the new, migrated account. By doing this, domain administrators give the new account the same level of access to resources as the old account.

If domain administrators cannot use the SIDHistory attribute in this way, they have to track down and reapply permissions for the new account on each network resource that the old account had access to.

Impact of SID filtering

SID filtering on external trusts can affect your existing Active Directory infrastructure in the following two areas:

  • SID history data that contains SIDs from any domain other than the trusted domain is removed from authentication requests that are made from the trusted domain. This results in access being denied to resources that have the user's old SID.

  • Your strategy for universal group access control between forests will require changes.

When you enable SID filtering, users who use SID history data for authorization to resources in the trusting domain no longer have access to those resources.

If you typically assign universal groups from a trusted forest to access control lists (ACLs) on shared resources in the trusting domain, SID filtering has a major impact on your access control strategy. Because universal groups must adhere to the same SID filtering guidelines as other security principal objects (that is, the universal group object SID must also contain the domain SID), verify that any universal groups that are assigned to shared resources in the trusting domain were created in the trusted domain. If the universal group in the trusted forest was not created in the trusted domain—even though it may contain users from the trusted domain as members—authentication requests from members of that universal group will be filtered and discarded. Therefore, before you assign access to resources in the trusting domain for users in the trusted domain, confirm that the universal group that contains the trusted domain users was created in the trusted domain.

Additional considerations

  • External trusts that are created from domain controllers running Windows 2000 Service Pack 3 (SP3) or earlier do not enforce SID filtering by default. To further secure your forest, consider enabling SID filtering on all existing external trusts that were created by domain controllers running Windows 2000 SP3 or earlier. You can do this by using Netdom.exe to enable SID filtering on existing external trusts or by recreating these external trusts from a domain controller running Windows Server 2008.

  • You cannot turn off the default behavior that enables SID filtering for newly created external trusts.

  • For more information about configuring SID filtering settings (disabling or reapplying them), see Configuring SID Filtering Settings (http://go.microsoft.com/fwlink/?LinkId=92778).