Auditing Windows Active Directory Trust Relationships

Introduction

The concept of Windows trust relationships have been around for a long time. They started back in the Windows NT era and have continued to be an important aspect of any Windows enterprise network. Trust relationships allow companies to merge domain user accounts fast and efficiently, as well as have different databases for domain users even if they work for the same company. This option is essential for a Windows enterprise environment, so the verification of the trusts that are established is important for the audit and security perspective.

What is a Trust

A trust is a logical relationship between two Windows domains. We will focus on the main Windows domain being an Active Directory domain in our discussion here, as this is what most companies have. In order to understand how the Active Directory domain utilizes the trust, we must first get a core understanding of how the domain is structured and what the domain is used for.

The main purpose of a Windows Active Directory domain is to authenticate user accounts and computer accounts. The domain is responsible for storing the computer and user accounts in a database. For Active Directory this is known as the Active Directory database. The domain will also have a domain name associated with it. The domain name can be any DNS approved domain name, such as microsoft.com, braincore.net, sales.acme.com, etc.

For a simple company with a single Active Directory domain, such as braincore.net, all user and computer accounts are stored in a single database. When a user logs on, there is only one choice for the user to log on, which is braincore.net.

Let’s assume that the company, braincore.net, purchases another company, techsales.com. Both companies have over 10,000 user accounts, so the merging of the two companies into one domain is not efficient. Also, both company names must be maintained for branding purposes.

In this case, a trust can be established between the two domains. This will allow users in either domain or location to log on to either domain, depending on where their user account is stored. So, if Ralph is visiting the TechSales office, logging on to a computer that is associated to the TechSales domain, he can still authenticate back to the BrainCore domain, since there is a trust.

What Trust Types Exist

There are a few types of trusts that you might see when you audit or when you are establishing trusts in Active Directory. These are independent of one another and are established without combining options.

Internal trust – These are trusts established between Active Directory domains that are in the same Active Directory forest. These trusts can be between parent-child domains or between parent top level domains, domains starting new trees in the forest.

External trust to Windows domain – These are trusts that go outside of the Active Directory forest. These trusts can be to either Active Directory domains (2000/2003/2008) or to Windows NT domains.

External trust to Kerberos Realm – These trusts are to a Unix Kerberos Realm. These realms are what Unix use instead of Active Directory. In essence, they are the same type of trust as compared to an external trust to a Windows domain.

Cross-link trust – These trusts are internal to the Active Directory forest. The concept is that a cross-link trust bypasses the traversal up the Active Directory tree, then down the Active Directory tree for domains that are multiple internal trusts away. These trusts are created for efficiency of authentication within the forest when users are accessing resources in a domain that is not near where the user is located.

Forest trust – These trusts were introduced with Windows Server 2003 domains. They provide a top level trust between two Active Directory forests. The goal is that all domains in both forests will be trusted, instead of having to create a trust between every domain to every other domain in the other forest.

How to Audit Trusts

In order to audit the trust relationships, you will need to either get a screen capture or ask for a command line output. There are, of course, other methods, but these might require a purchase of software or to write a script. Not that these options are all that bad, but if there is a way to obtain the information without any cost, I typically try to lead the auditor down that path.

The first option, screen capture, will come from the domain administrator. This screen capture will be of the Trusts tab for each domain that you need to audit. So, if the network administrator has informed you that the company has three domains total, you will need a screen capture from each domain, totaling three screen captures. To obtain the screen capture, the domain administrator will need to use the Active Directory Domains and Trusts administrative tool. This tool is on every domain controller and is one of the tools that is installed with the adminpak.msi (administrative tools for Windows 2000/XP/2003) and the RSAT (remote server administrative tools for Windows Vista/2008/7). To get to the correct screen, the administrator needs to expand the list of domains on the left pane, then right-click on each domain name. When the menu appears, select the Properties option. This will launch the Properties window for the domain. Here, select the Trusts tab to see the list of trusted and trusting domains, as shown in Figure 1.


Figure 1: Active Directory Domains and Trusts allows you to see all domain trusts.

If any trusts are established, they will appear in this list.

If you choose to do the command line option, you will be using the nltest command. This command is built into all server versions, so it will be easy for the administrator to obtain for you. The tool output is not nearly as friendly as the screen capture, but it does get a list of trusts. The syntax for the command will be:

Nltest /DOMAIN_TRUSTS

This will generate a list of domains and all trusts. It will indicate the parameters of the trust, so you are aware of the relationships, type of trust, etc. If you want the output to a file, instead of a screen capture, just use the following syntax and input the filename you prefer:

Nltest /DOMAIN_TRUSTS > c:\filename.txt

What Else You Audit To Secure Trust Relationships

Now that you have the domain trusts listed, you simply verify that these are all “valid” and “known” by the administrators. If there are any listed that are not “valid” or “known”, then those should be written up.

With regard to auditing trusts, this is all that you will need to do. However, this is not all that will be audited with regard to the trusted users or the trusting resource. You will also be auditing security around “who” has access to “what” resource. This is done through various other audit control points. Specifically, you will be auditing user rights per server, the access control list (ACL) per “critical” resource (file, folder, Registry key, etc), and group memberships.

It is on these additional checks that you will be auditing which users and groups from the trusted domain has been granted access to the resources in the trusting domain. You will clearly see the “other” domain, the trusted domain, will have entries in the ACL which include that domains name. For example, you might see BRAINCORE\derek or TECHSALES\Videssa listed on the ACL, which clearly indicates the domain from which the user or group originates.

Summary

The auditing of Windows domain trust relationships is not all that complicated, however is essential for the completeness of your audit. You will need to gather information about trusts for every domain that you audit, as they are not dependent on one another. You will simply verify the trusts listed are known and valid, then move on. The other details around security for your audit will be discovered and audited when you audit user rights, ACLs, and group membership. Once you perform all of these checks, you will have audited all aspects of Windows domain trusts.

About The Author

1 thought on “Auditing Windows Active Directory Trust Relationships”

  1. I want to retire trusts or reduce them to incoming trusts. I need to see if users from domain A.com are authenticating or accessing resources in domain B.com. Which domain will have events in domain controller security logs? Sure I expect the A.com users will have logon events on A.com DCs. That will be success events that may or may not be of interest. (Needle meets haystack). But are ther A\user logon events on B.com DCs? Thanks.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top