Networking

Get IT Done: Understanding Win2k domain trusts

How to work with Win2K domain trusts


In Windows 2000, Microsoft has modified and extended the domain trust features of Windows NT 4.0. I’m going to explore Windows 2000 domain trusts by explaining what types of trusts exist, examining the protocols that trusts use, and providing some additional resources for further study of domain trusts.

Types of trusts
Windows domain trusts essentially allow users in one domain to access resources in another domain. Windows 2000 trusts exist in four types. The type of trust denotes which way trust and access flow in the relationship. The four types of Windows 2000 domain trusts are:
  • One-way
  • Two-way
  • Transitive
  • Nontransitive

The concepts of “trust” and “access” are important in understanding the flow of domain trust traffic. Exposure to Windows NT 4.0 domain trusts will have you using the terms trusteds and trustings. These terms still exist in Windows 2000, although Active Directory brings in some new properties as well.

Who you trust refers to the domain that is trusted (the accounts therein) to have access to your resources. You are trusting the other domain to access your resources. Therefore, the other domain is happy to be trusted by your domain. Figure A illustrates the flow of the trust relationship.

Figure A


Figure A can be best described as a one-way trust. A two-way trust makes both domains a trusted and trusting domain. Therefore, the resources in each domain are available to authorized users in the other domain.

Comparing transitive and nontransitive trusts
Transitive trusts are new to Windows 2000. In Windows NT 4.0, domain trusts were nontransitive. That means that each domain had to explicitly trust (or be trusted) by each domain that it needed to share access with. Thus, in an infrastructure with multiple NT domains, the issue of trusts would get very complicated very fast, as we’ll see below.

This sort of round-robin trust architecture is not necessary in Windows 2000 with Active Directory. The key thing to remember is that all trusts within the same Windows 2000 forest are transitive in most situations. This means that trust relationships can climb up and down the forest across different domains. Transitive trusts exist only as two-way trusts, meaning both domains trust each other’s accounts to their own resources.

To help compare a transitive and nontransitive trust, imagine an organization involving five domains. Domain 0 will be the headquarters of this organization. The other domains are represented in pairs based on their function and location. Domains 1/2 and 3/4 are similar and share resources that may not go to or through domain 0. Figure B illustrates the organization using nontransitive trusts.

Figure B


This graphic illustrates that domains 0, 1, and 3 have a transitive, round-robin relationship. Domains 2 and 4 have connections only to domains 1 and 3, respectively. From 2 and 4, no resources or access is available beyond those for which they have the explicit trust.

If these same five domains had all trust relationships set up as transitive trusts, the flow of resources and access would be good in all directions. Figure C illustrates such a scenario.

Figure C


Transitive trusts are an easy trust to set up, as they usually address all issues related to trust design by granting flow of resources and access based on the current security in the domains involved. However, when you analyze domain trusts, situations frequently arise where a transitive trust may not be the desired trust relationship.

In Win2K, nontransitive trusts are specifically created in situations where you don't want the transitive property of Windows 2000 domains. Creating nontransitive trusts will prevent the trust relationships from flowing across the Windows 2000 forest. Trusts created from a Windows 2000 domain to a Windows NT 4.0 domain will be nontransitive, as will all Windows NT 4.0 to Windows NT 4.0 trust relationships.

Planning domain trust needs
When considering what types of trusts you plan to implement (or may already have), think about the need for the trusts. Domain trusts provide an opportunity to expose internal security threats, but they also increase your administrative overhead by adding accounts for you to manage. If your domains span multiple sites, do you really need to administer the remote domain? And does the remote domain really need to perform administrative tasks on your local domain? Summing up the planning process, examine the levels of access that are granted and the resources that are involved in your trust relationships and evaluate their necessity.

How is the trust transported?
Domain trusts allow access to resources on different domains, but they don't provide the physical connection between two domains. It seems silly, but at one point, I thought that such relationships could be routed through the network operating system. A network connection—router, hub, or other piece of hardware—is required to transport the trust relationship. Also, if the trusts are outside a Windows 2000 forest, a common DNS, WINS, LMHOSTS, or other domain resolution process needs to be in place.

How are trusts administered?
When creating, planning, and administering domain trusts, have the following information available for your connectivity planning:
  • Windows domain names
  • Windows version information
  • Remote domain account credentials
  • A simple diagram of how your network of domain trusts will interact

In a Windows 2000 Active Directory environment, you administer domain trusts in the Active Directory Domains and Trusts console. This is located in the Administrative Tools program group. From there, you can add Domains Trusted By This Domain (Trusted) or Domains That Trust This Domain (Trusting) relationships.

In Windows NT 4.0, you administer trusts in the Windows NT User Manager. From the User Manager, click on the Policies menu. The Trust Relationships option will allow you to create the necessary trust relationships.

Domain trust protocols
The domain trust protocol is the means by which Windows domains establish their trusts. This is important, as it provides the security to the network connections for your Windows domains. Windows NT 4.0 uses the Windows NT LAN Manager (NTLM) protocol for network authentication. Windows 2000 offers the NTLM protocol to communicate with Windows NT 4.0 networks. For Windows 2000 domain communication, Microsoft has introduced a slightly modified version of the Kerberos authentication protocol to the Windows platform for interdomain communication.

Kerberos is a protocol that encrypts information with secret key cryptography. The secret key is managed by the Key Distribution Center (KDC) of Kerberos. Kerberos manages trusted parties on the network with a secret key and a public key. The data is then verified against the secret key to be successfully decrypted. This approach allows Kerberos to be a secure and efficient authentication protocol.

With Windows 2000 implementing Kerberos into the domain connectivity options, future connectivity options to different types of platforms that use Kerberos exist. The history of Kerberos develops from a history of non-Microsoft systems and institutions that have some optimism about future connectivity using this protocol based on open standards.

Resources
Microsoft provides extensive documentation on domain trusts and the Windows 2000 server platform. An excellent Internet source is Microsoft’s Windows 2000 Advanced Server online help.

MIT provides access to mailing lists, newsgroups, downloads, and other information on the Kerberos protocol.

Bottom line
Domain trusts are a critical tool in connecting accounts to resources when needs reach across domain boundaries, as they almost always do in large organizations. Having a good understanding of the underlying concepts of domain trusts, which we have reviewed here, can make trust relationships much easier to administer.

Have a comment?
We look forward to getting your input and hearing about your experiences regarding this topic. Join the discussion below or send the editor an e-mail.

 

About Rick Vanover

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

Editor's Picks