To perform their jobs, these administrators each need administrator authority on their local BDCs. Obviously, though, none of the administrators should have administrator authority on the other BDCs. But because only one Administrators group exists in the PDC's SAM, you end up with several administrators having inappropriate authority to BDCs. Harry, the outside contractor, has full authority to the domain SAM, company email, HR information, and even the company's financials—as do the other application-server administrators. Although being a member of the local Administrators group doesn't give you direct administrative authority over member servers and workstations, you can use your authority to add yourself to any Domain Administrators group, which in turn gives you administrator authority over every computer in the domain. The fact that BDC4 is a public Web server presents the greatest risk. If an intruder compromises that server and obtains administrative access, he or she can then access the entire domain.
Whom Can You Trust?
Account management is simple in a single-domain network: You can grant a user access to any domain resource through the user's domain account. Things get a little more complicated when your network comprises multiple domains. Suppose a user, Fred, has a domain account in Domain A. Fred can use this account to access resources in Domain A. But if Fred needs access to resources in both Domain A and Domain B, he needs two user accounts—one for each domain. However, creating multiple user accounts for one person is generally a bad idea from a security standpoint (as I discussed in "NT Security Fundamentals").
To solve Fred's problem without creating multiple user accounts, you can create a trust relationship that links Domain A and Domain B. Figure 2 shows such a relationship. Domain A is the trusted domain and Domain B is the trusting domain. When a user with a user account in a trusted domain requests access to a resource in a trusting domain, the trusting domain's DCs rely on the trusted domain's DCs to vouch for that user account's authenticity.
You can use the trust relationship between Domain A and Domain B to grant Fred's user account (in Domain A) access to resources in both domains. When Fred maps a drive to a member server in Domain B, his workstation sends his Domain A user credentials to the member server. That server forwards the credentials to a DC in Domain B. That DC recognizes that the credentials come from a trusted domain and forwards them to a DC in Domain A. That DC checks the credentials against the domain SAM and returns the result to Domain B's DC, which relays the result to the member server.
The trust relationship that Figure 2 shows grants Domain A users access to resources in Domain B but doesn't grant Domain B users access to resources in Domain A. To permit that type of access, you need to create another trust relationship that flows in the opposite direction.
To manage trust relationships, open User Manager for Domains and select Policy, Trust Relationships. The resulting Trust Relationships dialog box lists both trusted and trusting domains for the named domain.
Creating a trust relationship is a two-step process that involves administrators in both domains. Typically, an administrator in the domain that wants to be trusted initiates the trust. To do so, she first creates her half of the trust in her domain. In the example that Figure 2 shows, an administrator in Domain A would open the Trust Relationships dialog box and click Add, to the right of the Trusting Domains list. NT then prompts the administrator to enter the name of the domain (i.e., Domain B) to add to Domain A's Trusting list and to enter a password. This password has nothing to do with the administrator's user account; it's a separate password for authenticating the trust's initial creation.
After Domain A's administrator completes these steps, she notifies Domain B's administrator that she has completed her part of the trust relationship and gives Domain B's administrator the password to authenticate the relationship. Domain B's administrator opens the Trust Relationships dialog box and clicks Add, to the right of the Trusted Domains list. NT then prompts Domain B's administrator to enter the name of the domain (i.e., Domain A) to add to Domain B's Trusted list and to enter a password. Domain B's administrator needs to enter the same password that Domain A's administrator used. If the passwords match, NT completes the trust relationship and reports success.
The creation of a trust relationship doesn't automatically open all the resources in the trusting domain to access by users in the trusted domain. Administrators in the trusting domain must still explicitly grant user or group access to specific resources. And administrators in one domain don't have administrator access in other domains even when trust relationships link the domains. However, when you grant access to the Everyone group, you actually grant access to all users in any trusted domains as well as all users in your domain. Therefore, you're trusting more than the trusted domain's DCs—you're trusting that domain's administrators. You're relying on those administrators to manage their user accounts securely and honestly. For example, if the trusted domain's administrators don't require difficult-to-guess passwords or establish a strong lockout policy, attackers might be able to invade accounts in that domain and thus access resources in your domain. Also, unscrupulous administrators in a trusted domain can impersonate any user in their domain and thereby access your resources. If another domain administrator's security standards don't meet or exceed your own, perhaps you shouldn't trust that domain.
When you're comfortable with the logistics of trust relationships, you can arrange them to create a domain model that fits your network's security needs and risks. In my next article, I'll explain that process.