6. Trust Definitions
Trusts to external forests, Windows NT domains, or
Kerberos realms should be defined in the design document. Windows 2000,
supporting only NTLM type external trusts, required individual trusts to
be created between all domains in separate forests because NTLM didn't
provide transitivity. Figure 27
shows two Windows 2000 forests, each with three domains. To get a
“complete trust model,” trusts were required between every two domains,
as shown in Figure 27,
similar to what the trust model in Windows NT 4.0 would look like.
Obviously, this is very confusing and difficult to administer. Creating a
trust across root domains would not provide the same transitivity as if
they were in the same forest.
Note that Windows Server 2003, on the other hand,
supports Kerberos cross forest trusts, which allow a single trust to be
created at the root level and maintain transitivity to child domains. Figure 28
illustrates this. You can administer a multiple forest enterprise very
easily with this type of trust because there is only a single trust (it
can be two-way) to maintain, and the Administrator can choose
authentication options noted in the cross forest trust.
In a Windows Server 2003 forest, you also can create a
trust to an MIT Kerberos v5 realm, allowing realm principals to access
Windows resources and vice-versa. This is accomplished by providing name mapping.
Because the MIT principal has no knowledge of Security Identifiers
(SIDs) and Windows requires them, a user account is created in the
Windows domain and is mapped to the realm principal. Name mapping is an
attribute of the user object. In the Users and Computers Snap-in, turn
on Advanced Features in the View menu, and then right-click the user
account. The Name Mapping dialog box appears as shown in Figure 29.
Identify all such trusts in
the design document. Just like the GPO design affecting the OU
structure, familiarity with the Kerberos trust might influence your
decision on deploying multiple forests.
