Tip

Best Practices for Active Directory forest trusts

The more domains you manage, the more you rely on forest trusts. Follow these tips to manage your AD infrastructure – and maintain your sanity.

When your Active Directory forest just contains a couple of domains, life is pretty good for you as the administrator—there’s not a lot to go wrong, clients receive fast responses, and in general, things work as they should.

But as more and more domains come online and, in particular, as you expand into different forests to further delineate security boundaries, the situation requires more management, especially as you come to expect trusts to hold everything together seamlessly. Here are some best practices on managing trusts to make authentication available and management of your AD infrastructure much easier.

Use shortcut trusts to eliminate delays. Delays creep up when your Active Directory forest has lots of trees in it containing multiple child domains. When you find that clients are taking a long time to authenticate, especially between those child domains, a best practice is to create shortcut trusts to mid-level domains within each tree hierarchy where possible. These shortcut trusts are essentially bidirectional transitive trusts that effectively lessen the length of the path traveled for authentications to take place between domains located in two separate trees.

To create these shortcut trusts:

  1. Open Active Directory Domains and Trusts, and in the left pane, right-click the domain node for the domain you want to establish a shortcut trust with, and then click Properties.
  2. On the Trusts tab, click New Trust, and then click Next.
  3. On the Trust Name page, type the DNS name (or NetBIOS name) of the domain, and then click Next.
  4. On the Direction of Trust page, choose to create either a two-way, shortcut trust (click Two-way) or choose one of the various one-way options if for some reason you need to limit reciprocity.
  5. Continue on with the wizard to completion.

Keep a current list of all trust relationships in your forest. This way, during administrative tasks, you don’t have to puzzle out why some authentications are working and others aren’t, or what domain trusts another domain one way but not the other, and so on. This is a common problem in large forests, or organizations with multiple forests, with many administrators that may be creating trusts without adequately documenting their actions. There’s a tool from Microsoft called NLTest that, among other useful things, queries the trust status for all domains and shows the other domains that a given domain trusts.

For example, to view the established trust relationships for your domain, use nltest /domain_trusts. You’ll get a result that looks like this:

List of domain trusts:
    0: testdomain.com testdomain.com (NT 5) (Forest Tree Root) (Primary Domain)
The command completed successfully

Perform a good backup and always test to ensure you have restore capability as well. Trusts are complicated to architect correctly and difficult to recreate exactly as they were in the event they’re lost. To protect yourself, ensure that all domain controllers in every domain in all of your forests have a current and tested system state backup. The system state backup contains the Active Directory trust data stored at any given point of time in the system. During a restore, the domain controller is put into a special mode that allows it to return to replication—including replicating the appropriate trust information—among all of the other online domain controllers without generating or encountering integrity errors. The built-in Windows Server Backup product contains the appropriate tooling to conduct these system state backups, but other third-party products that may already be protecting your data centers also have this capability as well.

ABOUT THE AUTHOR
Jonathan Hassell is an author, consultant, and speaker on a variety of IT topics. His published works include RADIUS, Hardening Windows, Using Microsoft Windows Small Business Server 2003and Learning Windows Server 2003.

Dig Deeper on Microsoft identity and access management

Cloud Computing
Enterprise Desktop
Virtual Desktop
Close