Domain Trust – part I

Aladdin asked princess Jasmine for her trust and she, by the look of his eyes opened her heart to him and trusts him. Unfortunately real life doesn’t work like tales and we can’t trust anyone we don’t know just because they ask for it, even if they look good…
I noticed (on my favorite forums) that this is a repeated subject, not always easy to understand for new administrators and I will try to simplify the subject while keeping the important techie details.

Domain Trust is a sharing concept that aims to ease the management of trust in the Active Directory world (aka the real world). It allows 2 separate groups that trust each other to share resources. It makes life easier for administrators 2 times: first at the point where they can share resources with other groups and second as they reduce the number of logins a user has to deal with (and as a result, reduce the number of helpdesk calls).

Scenario (or, what does it good for):
Companies A & B merged but want to keep the network as is. You have to allow users from both companies to share files and printers. Establishing a trust between the 2 domains (actually forests) will simplify the process from a long tedious permission setup to a 5 minutes trust build up.

How does it work?
In this post I’ll go over some of the basic concepts and later will go over different type of trusts (One-way, Two-way, Transitive, Nontransitive)
A trust relationship is defined by a secret key that is shared by both forests and domains and that gets updated on a regular basis. That said, when you configure a trust all you have to do is have the same password on both ends and let the system do the rest. The rest is based on the NTLM and Kerberos authentication protocols and on Windows-based authorization and access control mechanisms.
Active Directory domain controllers authenticate users and applications by using one of two protocols: either the Kerberos version 5 authentication protocol or the NTLM authentication protocol. When two Active Directory domains or forests are connected by a trust, authentication requests made using these protocols can be routed to provide access to resources in both forests.
Every trust has a secure channel through which trust participants communicate. They use the trust password to secure their communication. If the secure channel between them is broken, you need to reset it/reset the trust password.
Trusts have a user account in Active Directory which can be seen via ADSIEdit. The user account for the Trust is stored in the BuiltIn ”Users” container under the domain root. The most useful and powerful tool to test trusts is Nltest.exe, one of the oldest guys in the area but still kicking!

In part II I'll go over different Trust types
In part III I'll go over some troubleshooting options