10 things you should know about AD domain trusts | TechRepublic (2024)

This article is also available as a PDF download.

Domain trusts can
be complicated to administer, and it’s important to implement changes correctly
the first time. Here are some key points to keep in mind to help ensure that
your trusts are configured effectively with a minimum of headaches.

#1: Determine what kind of trust you should use

Before deploying a domain trust, you should ensure that the
type(s) used are correct for the tasks at hand. Consider the following
dimensions of a trust:

• Type:
  Identifies the types of domains involved in trust(s).
• Transitivity:
  Determines whether one trust can let a trusted domain pass through to a third
  domain.
• Direction:
  Identifies the direction of access and trust (trusted accounts and trusting
  resources).

#2: Get familiar with the Active Directory Domains
And Trusts Console

Trust relationships
are managed via the Active Directory Domains And Trusts Console. It lets you
perform these basic tasks:

• Raise domain functional level
• Raise forest functional level
• Add UPN suffixes
• Manage domain trust
• Manage forest trust

For details on using this tool, see
“TechRepublic Guided Tour: Active Directory Domains AndTrusts Console.”

#3: Know the tools

As with most other elements of the Windows Server family,
command-line tools can be used to script repetitive tasks or to ensure
consistency in the case of trust creation. Some of the top tools include:

• NETDOM: Used to
  establish or break trust types.
• NETDIAG: The
  output of this tool can give basic status on trust relationships.
• NLTEST: Can be
  used to verify a trust relationship.

You can also use
Windows Explorer to view membership to shared resources as they are assigned from
trusted domains and/or forests. Active Directory Users And Computers can also
provide membership details of Active Directory Objects that have members from
trusted domains and/or forests.

#4: Set up a test environment

Depending on your
environment and usage requirements, a simple mishap in the creation of domain
trusts can have enterprise-wide repercussions. But it’s difficult to set up a
completely similar test environment to replicate multi-domain and forest
issues. Having similar domain scenarios is easier to facilitate, as a means to
reinforce the principles and test basic functionality. Consider also template
Active Directory objects to test on the live domain relationships to ensure
that the desired functionality is obtained but not exceeded before using live
groups, accounts, and other objects.

#5: Review privileges

When trusts are
created, it’s important to ensure that the desired functionality is achieved.
But be sure to review the configured trust to verify that the direction of
access is correct. For example, if domain A needs to access only a limited
amount of resources on domain B; a two-way trust would suffice. However, an
administrator from domain B may be able to assign access to resources on domain
A. Ensuring the desired direction, type, and transititivity
of trusts is critical.

#6: Map out the trusts

Create a map of
trusts with simple arrows and boxes illustrating which domains will be trusting
and trusted and which trusts will be 1-way and 2-way. Then, with the simple
picture(s) in place, map out which domains will trust which–and determine the transititivity as well. This simple chart will make more
sense of the greater task at hand and allow you to determine which domains need
direction of access and in which direction. Some domains will simply act as a
gateway for transitive access to other domains.

#7: Document trust relationships

As organizations
marry (and divorce) in today’s business world, it’s important to have clear
documentation of the trust inventory–and to make sure it’s accessible without
the trust or domain. For example, if you’re in Domain B and your headquarters
in Domain A sells your division and breaks your trust, your concise
documentation saved on a server in Domain A does you little good. Document the
type of trust, transitivity, direction, business need for the trust,
anticipated duration of the trust, credentials, domain/forest principal
information (name, DNS, IP addresses, locations, computer names, etc.), and
contact person(s) for the corresponding domains.

#8: Avoid making
trust relationships too deep

In the interest of
everyone’s time, don’t nest membership more than one deep when using trusts in
multiple domains and forests. Nesting membership can consolidate the number of
manageable Active Directory objects, but determining actual membership
administration is greatly increased.

#9:
Know how to manage different versions of Windows

When running in
Windows 2000 and Windows Server 2003 native mode for Active Directory, full
functionality is maintained for member domains and forests. If any NT domains
or member systems are present in the enterprise, their trust entry
functionality is limited by the inability to recognize the Active Directory
objects. A frequent strategy in this scenario is to have “domain islands” of those
that don’t connect to the more common enterprise infrastructure.

#10: Remove expired or overlapping trusts

Changes in business organization may have left unused trusts in place on
your domain. Clear out any trusts that are not actively being used. You should
also ensure that the trusts you have are set up correctly for the required
access and usage patterns. An audit of your trust inventory can be a strong
supplement to your well-rounded security policy.