Windows Active Directory Family---Configure trust for AD Domain Services (1)

In a multi-domain ad forest, a two-way trust relationship is automatically generated between AD domains so that there is a trust channel between all AD domains. Trusts that are automatically created in the forest are transitive trusts, which means that if a domain trusts the B domain and the B domain trusts the C domain, a domain trusts the C domain.

Here are a few key trust relationships:

Trust type	Transitivity	Direction	Describe
Parent-Child Trust	Passed	Bidirectional	A parent-child trust relationship is automatically created when a new ad domain is joined to an existing AD domain tree
Root Tree trusts	Passed	Bidirectional	When a new ad domain tree is joined to an existing ad forest, the root tree trust is automatically created
External Trust	Non-transitive	Unidirectional or bidirectional	External trusts can open resource access to an ad domain in a Windows NT 4.0 domain or another forest, and creating an external trust also provides a migration framework for domain migrations
Domain trusts	Transitive or non-transitive	Unidirectional or bidirectional	Realm Trust establishes a trust channel between the Windows AD domain and the Kerberos V5 domain, and the domain of Kerberos V5 uses a directory service that is not Windows ad

How does trust work in a single forest?

Whether you are in the same forest, in a different forest, or in a trust relationship with an external domain, these trust information is saved in the AD domain service, and this information is saved as a trusting domain object.

The trusting domain object holds information related to trusts, such as the transitivity and type of trust. No matter when your trust is created, a trusting domain object is created and saved in the System container of the AD domain service.

How does trust give users access to resources in the forest? When a user in a domain tries to access a resource in another domain in the forest, the user's computer first connects to the DC in the domain to request a session ticket that accesses the resource, but because the resource is not a resource for the domain, the DC needs to confirm that there is a trust relationship between the target domain and the domain.

DCs can use the trusting domain object to verify that the trust exists, but if you want to access the resource, the client computer must be able to communicate with the DC of each domain on the trusting channel. After the client computer's domain-owned DC receives the request, it submits the client computer to the DC of the next domain on the trusted channel, and if the domain is not the domain where the resource resides, the DC of the domain submits the client computer to the DC of the next domain until the client computer is committed to the DC of the domain where the resource resides. At this time the DCs of the domain where the resources are located issue a session ticket to the client to access the resource.

The Trust channel is the shortest path through the trust level. There is only a default trust relationship in a forest environment, and the trust channel stretches upward from the underlying domain tree to the root domain of the forest, then from the root domain down to the other domain tree, and finally from the domain tree to the target domain. If you configure a shortcut trust, only one hop is required on the trusting channel in the domain of the computer that is located in the resource domain.

How does trust work between forests?

If the AD domain service has more than one forest in the environment, you can establish a trust relationship between the root domains of the forest. The trust relationships for these forests can be forest-wide trusts or optional trusts. Forest trust can be either unidirectional or bidirectional, it is also transitive, and you can pass trust relationships to domains in each forest, so that domains between forests also have trust relationships.

A forest trust relationship allows a user who passes the authentication of one domain in the forest to access a resource for a domain in another forest, and a DC in the trusting forest can provide a session ticket for users of any domain in the trusted forest if the forest trust is unidirectional. Forest trust is much simpler and easier to maintain and manage than to make a separate trust relationship between each domain in the forest.

Forest trust can be useful in scenarios such as cross-organization collaboration, mergers and acquisitions, or multiple forests in an organization that require separate ad data and services. Forest trust is also useful for service providers, such as external business collaboration, or a company's own managed solutions.

In general, forest trusts have the following advantages:

1. Simplifies management of resource access between two windows2008 or later forests by reducing the number of trust relationships necessary to access shared resources

2. Make domains in each forest have a two-way trust relationship

3. Cross-forest access through the validation of the UPN

4. Using the Kerberos V5 protocol to increase the credibility of authorization data passed between forests

5. Each forest has unique management tasks that make management more flexible

You can create a forest trust in two AD DS forests, but forest trust does not extend to a third forest. This means that if you establish a forest trust between Forest1 and Forest2, then you establish a forest trust between Forest2 and Forest3, but Forest1 and Forest3 do not trust each other by default, and forest trusts do not pass between multiple forests.

Before you deploy a forest trust, you must specify several requirements for the Forest trust, first your forest functional level must be Windows 2003 or higher, and then DNS between your forests can parse each other.

This article is from the "Dry Sea Sponge" blog, please be sure to keep this source http://thefallenheaven.blog.51cto.com/450907/1583189

Windows Active Directory Family---Configure trust for AD Domain Services (1)