Trouble creating Forest Trust between Windows Forest and Windows Forest
Before we look at the intricacies of Windows and interforest trusts, Some characteristics of trust relationships in Windows NT follow: Windows Server makes it easier to configure interforest trust relationships. Because Windows uses NTLM to secure trusts between domains that are in separate forests, a trust relationship between a Windows Server domain. Trusts have changed significantly on Windows Server , including the concept of forest trusts. Here's a authentication, which restricts access within a trust relationship. In a Windows forest, no domain is an island.
If I want to assign resource access in every domain in forest A to any user with an account in any domain in forest B, I can do so. In addition to a trust wizard there is new nomenclature. An incoming trust from A to B means that users and groups in B can be assigned access to resources in A. A and B can represent domains joined in an external trust or forests in a forest trust. An outgoing trust, one from A to B, means that users and groups in A can be assigned access to resources in B.
Figure 1 illustrates an incoming trust from forest B to forest A. Note that users John and Mary, who have accounts in domains in forest B, are given access to folders on servers in two different domains in forest A. An incoming trust into forest A means users in forest B can be granted access to forest A resources. The complete nature of this trust brings problems.
Trust Relationship in Windows 2008 R2
While the Everyone group is more restricted, anonymous access is curtailed and the anonymous SID is no longer part of Everyone, Windows still provides, by default, more access than some would like. Certainly there is exposure. Completing a forest trust does mean added risk. Fortunately, there is a solution which can help mitigate that risk. Functional Levels in Windows Server Functional level is both a statement of fact about the operating system level of domain controllers, and a Windows mode set by an administrator.
There are two types of functional levels. A domain functional level indicates which operating systems DCs in the domain may have, and a forest functional level indicates the functional level of all domains in the forest. Click Finish to return to the Trusts tab of the domain's Properties dialog box refer to Figure 3.
If you have created only one side of the trust, an administrator in the other domain needs to repeat this procedure to create the trust from her end.
She will need to enter the trust password you specified in this procedure. Realizing that the research necessary to complete this project successfully required a high level of security, management asked the senior network administrator to set up a separate forest in the organization's Windows Server Active Directory design.
For the project to succeed, researchers needed access to certain data stored in the organization's existing forest. Their user accounts would be in the new forest. Users in the existing forest did not need to access data in the research forest. The administrator had to choose a trust model that would enable the appropriate levels of access. With these needs in mind, the administrator decided to implement a one-way external trust relationship in which the existing forest trusted the research forest.
It was then possible to place the researchers who needed access into a group that could be granted access to the appropriate resources in the existing forest.
Active Directory Services and Windows 2000 or Windows Server 2003 Domains (Part 1)
Because the trust relationship was one-way, no access in the opposite direction was possible. We take a further look at the use of groups to grant crossforest access in Chapter 6, "Implementing User, Computer, and Group Strategies.
Validate trust relationships This option enables you to verify that a trust has been properly created and that the forests can communicate with each other. Change the authentication scope This option enables you to change the selection of domainwide authentication or selective authentication that you made during creation of the trust, should you need to modify access control to the trusting forest's resources.
Configure name suffix routing This option provides a mechanism that you can use to specify how authentication requests are routed across Windows Server forests. It is available only when forest trusts are used. Validating Trust Relationships To access the trust's Properties dialog box and validate a trust relationship, follow Step by Step 3. On the Trusts tab of the domain's Properties dialog box, select the name of the other domain or forest and click Properties.
This action displays the trust's Properties dialog box, as shown in Figure 3. To validate the trust relationship, click Validate. If the trust is in place and active, you receive a confirmation message box, as shown in Figure 3.
Otherwise, you receive an error message, such as the one in Figure 3. Configuring Name Suffix Routing When you initially create a forest trust, all unique name suffixes are routed by default. For example, the DNS forest name quepublishing. Consequently, name suffixes in one forest do not exist in another forest.Trust Relationship - Active Directory
Name suffix routing is a mechanism that can manage the routing of authentication requests across Windows Server forests that are connected by forest trust relationships. It enables name suffixes that do not exist in one forest to be used to route authentication requests to another forest.
This includes child name suffixes. As a result, when you view name suffixes in the Name Suffix Routing tab of the domain's Properties dialog box, as shown in Figure 3.
If you add new child domains to either forest, they automatically inherit the name suffix routing properties of other domains in the forest. After you add a new name suffix and validate the trust, it appears on the Name Suffixes tab with a status shown on the Routing column of Disabled. The Status column indicates New for a newly created name suffix. You may need to disable name suffix routing to prevent certain authentication requests from flowing across the forest trust.
You may also need to enable name suffix routing for additional name suffixes you have created or to exclude a child name suffix from routing.
The routing status in the Routing column changes. In the case of enabling a new name suffix routing, the New entry disappears from the Status column. To exclude a child name suffix from routing, select the parent suffix and click Edit to display the Edit domain name dialog box see Figure 3. To exclude the name suffix, click Add. The excluded name suffix appears on the Edit domain name dialog box.
News, Tips, and Advice for Technology Professionals - TechRepublic
In such situations, the Status column on the Name Suffix Routing tab lists the conflict in the indicated domain. You cannot enable this suffix for name routing until you have removed the conflicting name suffix for the indicated domain.
Removing a Crossforest Trust Relationship Sometimes you might need to remove a trust relationship between two forests. For example, a contract may have completed or been terminated, an acquisition of one company by another may have fallen through, and so on. You may need to remove and re-create a trust relationship if you have incorrectly specified properties such as an incorrect trust type or direction. On the Trusts tab of the domain's Properties dialog box, select the trust to be removed and click Remove.
You are asked whether you want to remove the trust from the local domain only or from the local domain and the other domain see Figure 3. If you want to remove the trust from both domains, select Yes, Remove the Trust from Both the Local Domain and the Other Domain, type the username and password for an account with administrative privileges in the other domain, and then click OK. Click Yes on the next dialog box to confirm removing the trust.
You are returned to the Trust tab of the domain's Properties dialog box. Notice that the name of the other domain has been removed. Understanding Trust Relationships Following are points to remember regarding trust relationships: In a one-way trust relationship, the trusting domain makes its resources available to users in the trusted domain.
A two-way trust relationship consists of two one-way trusts in opposite directions. By default in Active Directory, all domains in a forest trust each other with two-way transitive trust relationships. You can also create shortcut trusts between child domains to facilitate rapid authentication and resource access. You need to explicitly set up all trust relationships between different forests. A one-way incoming trust allows users in your trusted domain to be authenticated in the other trusting domain, whereas a one-way outgoing trust allows users in the other trusted domain to be authenticated in your trusting domain.
Two authentication scopes are available: Domainwide authentication allows users from the trusted domain to access all resources in the local domain. Selective authentication does not create any default authentication; you must grant access to each server that users need to access. You can change the authentication scope after trusts are set up, if necessary. You can enable name suffix routing that simplifies authentication requests being routed to another forest. New child domains added to either forest automatically inherit these name suffix routing properties; however, you can disable name suffix routing when required or exclude a child name suffix from routing.
WARNING Removing the Trust If you remove the trust from the local domain only, it still appears from the other domain but generates an error if you attempt to validate it. In addition to the default transitive trusts that are established in a Windows Server or Windows Server R2 forest, by using the New Trust Wizard you can manually create the following transitive trusts: 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.
A transitive trust between a forest root domain and a second forest root domain. A transitive trust between an Active Directory domain and a Kerberos V5 realm 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.
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 or a Windows Server R2 domain and a Windows NT domain A Windows Server or a Windows Server R2 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: A nontransitive trust between an Active Directory domain and a Kerberos version 5 V5 realm.
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. 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. 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. 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.
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. When to create a realm trust: 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. Creating a Forest trust between two different Forests: When to create a forest trust You can create a forest trust between forest root domains if the forest functional level is Windows Server or higher. Creating a forest trust between two root domains with a forest functional level of Windows Server or higher provides a one-way or two-way, transitive trust relationship between every domain in 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. 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.