To Trust or Not to Trust

Trust relationships offer a powerful way to stop account proliferation and enable single sign-on (SSO) across Active Directory (AD) forests, Windows NT and AD domains, and even non-Windows Kerberos realms. But trust can come with a price. In a forest with trusting domains, malicious administrators have a larger arena in which to cause trouble and domain controllers (DCs) that are physically vulnerable expose the entire forest to compromise. Let's examine the fundamentals of trust relationships and identify the potential risks associated with trust relationships. Then I'll explain how to mitigate those risks when dealing with the different types of trust relationships available today in Windows Server 2003 and Windows 2000.

The Right Degree of Separation
There's more than one way to skin the proverbial cat when it comes to high-level AD design (i.e., divvying up your environment into forests and domains). One of the key requirements of high-level AD design is to provide the right amount of separation between different areas of your organization. Ideally, an organization implements a single forest of one or more domains. As long as AD implementation comprises a single forest, users get a cohesive view of the network and each user can have just one account. At the same time, you can divide the forest into multiple domains to provide the required separation between different teams of administrators or types of users.

Unfortunately, though, an organization often finds itself with multiple forests for a variety of reasons. If a company acquires or merges with another company, the new company often ends up with two forests on the same network. Some organizations determine that domains within a forest fail to provide sufficient separation of administrative authority and therefore opt for multiple forests. Or, depending on the industry an organization is in, laws or regulations might force a multiforest design.

A Simple Matter of Trust
Consider the simplest trust relationship there is: a one-way, nontransitive trust between two domains. Domain A trusts domain B, but domain A doesn't trust any domains that domain B trusts. Figure 1 shows a nontransitive trust, compared with a transitive trust. (For security information about the various types of trust relationships, see the sidebar "Many Types of Trust.") When domain A trusts domain B, what really happens? Who is domain A really trusting? Do users in domain B suddenly gain access to resources in domain A? Do domain B administrators get any access to domain A?

First, what happens in a trust relationship? In this case, the trusting domain is domain A and the trusted domain is domain B. From the standpoint of domain A, the direction of the trust is outgoing. Computers in domain A trust DCs in domain B to authenticate user and computer accounts and specify group memberships. When an administrator in domain A opens the ACL of a file or folder and selects new accounts and groups to add to the ACL, the administrator sees accounts and groups from domain B in addition to domain A. The administrator can also make domain B accounts and groups members of domain A groups and in general can use domain B accounts and groups anywhere he or she can use domain A accounts and groups. Users in domain B can access resources in domain A to which they have the appropriate permissions.

Who is domain A really trusting? Domain B users? Domain B administrators? If you set up a trust in which domain A trusts domain B, you obviously want domain B users to have access to certain resources within domain A. You can accomplish this access by granting the appropriate permissions to domain B groups after setting up the trust. But do the administrators in domain B gain any additional access to domain A? The obvious answer is that domain B administrators gain no more access than other domain B users, except that they can add users to and remove them from domain B groups, which might have access to resources in domain A. In other words, if a domain A administrator grants any access to a domain B group, a domain B administrator can grant or revoke that access for domain B users by simply adjusting the membership of the domain B group. So, on the surface, trust relationships look pretty benign. However, there is a documented way for administrators in domain B to maliciously gain administrative access to domain A, which I describe in the next section.

The Risks of Trust
One of the risks of trusting another domain has to do with how you manage permissions when you need to grant everyone in your domain access to a resource. Using the Everyone or Authenticated Users group when you want everyone in your domain to have access to a resource is quite common. However, the composition of the Authenticated Users group changes when you add a trusted domain. If our domain A trusts no other domains, the Authenticated Users group comprises just the users of domain A and, when evaluating access to objects on member servers and workstations, the local users on those computers. However, if domain A trusts domain B, the Authenticated Users group suddenly expands to include all the users from domain B as well. So, any files or other objects that have ACL entries granting access to Authenticated Users will now extend that access to domain B users too. (If domain A's trust with domain B were transitive, access would also be extended to the users in any domains that domain B trusted.)

Depending on the type of trust relationship, Windows might use Kerberos or NT LAN Manager (NTLM) as the authentication protocol to process logon requests between the two domains. Although it's possible to sniff either protocol's packets and use them to crack a user password, cracking NTLM information is easier and faster. If you upgrade the DCs and workstations in the trusted domain and all the computers in the trusting domain to NTLMv2, you can plug the worst holes in NTLM, but Kerberos is still stronger. For more information about NTLMv2, see Access Denied, "Implementing NTLMv2 on Win2K, NT, and Win9x Machines," December 2001, InstantDoc ID 23068.

These technical risks are pretty easy to control compared with the primary risk of trusting another domain: trusting the domain's administrators. When domain A trusts domain B, domain A is counting on domain B administrators to do their job professionally and honestly. If domain B is compromised, any domain A resources shared with domain B are at risk. For instance, let's say Bob has an account in domain B and has access to an important database in domain A. If an attacker tries to guess Bob's password through repeated logon attempts, it doesn't matter how strict domain A's lockout policy is—only domain B's lockout policy stands between the attacker and the domain A database. Additionally, only domain B administrators are going to notice the logon failures in the DC's Security log. (Although, if the attacker directly attacks one of domain A's computers with Bob's account, the local logon failures will show up in that computer's Security log.) So if domain administrators in a trusted domain fail to keep accounts secure, monitor for intrusions and other security weaknesses, patch their systems, or enforce other security controls, the trusting domain—or at least, the resources in the trusting domain available to users in the trusted domain—is exposed to the same risks as the trusted domain.

Moreover, there's always the possibility of a dishonest administrator in the trusted domain. Administrators can manipulate accounts and groups in many ways, including impersonating a user to whom you've granted access. Of course, all these same risks are present in the trusting domain as well. So, when you're deciding whether to trust another domain, you should ask yourself whether you trust the administrators of the other domain. However, the alternative to not trusting a domain that contains users with whom you need to share resources isn't without risk either. If you don't trust the domain, you'll have to create accounts for its users. If you do so, you'll be confident that these accounts are benefiting from whatever level of security you maintain in your domain, but will you know when these users leave their jobs or have job changes—or would the administrators in the trusted domain have a better chance of disabling accounts or adjusting memberships as a result of job changes?

Another risk stems from the fact that trusted DCs provide group membership information to trusting DCs in addition to authenticating users. Within a forest, a DC trusts all the SIDs that a trusted DC specifies for a user. Therefore, a malicious administrator in domain B, if properly skilled or in possession of a program written by a skilled hacker, could cause a DC in domain B to specify that the domain B administrator belongs to domain A's Administrators group and domain A would grant him or her administrative authority. (See "Facts about Directory Structures and Directory Structure Owners" in "Design Considerations for Delegation of Administration in Active Directory" at http://www.microsoft.com/windows2000/docs/addeladmin.doc.)

When this vulnerability was first discovered, an attacker could exploit it against any type of trust relationship. In response to this risk, Microsoft introduced a new feature to all versions of Windows called SID filtering. With SID filtering turned on, the trusting DC analyzes the SIDs coming back from a trusted DC and filters out any that correspond to accounts or groups outside the trusted domain. However, SID filtering isn't available between domains within the same forest because SID filtering breaks replication.

A domain administrator in the trusting domain must apply SID filtering to the trusted domain. For example, you could use the following Netdom command to filter SIDs from the Jonescorp domain:

C:winnt>netdom /filtersids yes  jonescorp

Trust with Caution
So, how can you mitigate the threat of in-forest SID insertion by trusted rogue administrators? Creating a separate forest for each domain might seem to be the only answer at first blush. Imagine that Acme is a US-based multinational company with offices around the world and administrators in both domestic and foreign offices managing domains in Acme's forest. Acme also does some classified US government work which has tight restrictions on access by foreign nationals. Simply moving all classified resources to a "classified" domain within the Acme forest leaves those resources at risk to foreign nationals who have administrator authority in other domains in the forest. Creating a separate "classified" forest is certainly an option and the simplest from a conceptual standpoint.

However, Acme has another option that would allow it to retain the benefits of having just one forest. In AD domains, not many people really need administrator-level authority. The highly granular AD security model allows you to delegate bits and pieces of administrative authority as needed. If you take the time to identify the various roles within IT and understand how AD delegation works, you can set up your domains so that for day-to-day administration, no one is logged on as a member of the Administrators, Domain Admins, Enterprise Admins, or Schema Admins groups. AD's granular delegation allows you to mitigate the trusted rogue administrator problem by making a policy that only US citizens can be a member of the Administrators, Domain Admins, Enterprise Admins, or Schema Admins group, which would preclude a foreign national IT staffer from exploiting the in-forest SID insertion risk.

However, limiting administrative authority addresses only one of the two ways of exploiting in-forest SID insertion. The other way involves physical access. A person who can gain physical access to a DC can compromise it by tampering with the system files while Windows is down. This physical vulnerability presents a more difficult problem for a company such as Acme because it must maintain DCs in foreign countries to support its global operations. The only way to protect against someone physically exploiting the in-forest SID-insertion vulnerability to gain access to the classified domain is to remove the classified domain from the main forest altogether. To maintain connectivity between users in the classified domain and the rest of the company, Acme can create a cross-forest trust between the main forest and a classified forest or external-trust relationships between specific domains, as Figure 2 shows. To compensate for the lack of a single, unified Global Catalog (GC), Acme can use Microsoft Identity Integration Server (MIIS) to publish users in a forest as contact objects in the other forest.

Domains in Windows 2003 and Windows 2000 aren't the impenetrable boundary of administrative authority they are in NT. The forest assumes the boundary role in AD. Following the least-privilege principle and limiting administrative authority can greatly limit the risk of in-forest SID insertion but not completely limit it. Multiple forests are undesirable from a usability standpoint and create more work for administrators who need to present a unified directory to the user community, but tools like MIIS can help. As you can see, designing forests and domains for an organization is a balance of risk management and usability.