A Matter of Trust

Because NT domains aren’t really a directory service, there must be some way for a user on one NT domain to use the resources of another NT domain. The mechanism that allows users of one domain to use resources of another is called trust. Trust relationships can be a one- or two-way relationship.

Say your boss gives you access to the file cabinet with everybody’s salaries. He has placed trust in you that you’ll not blab everybody’s salaries all over town. Similarly, you trust your boss to pay you on Friday. This is a two-way trust relationship. On the other hand, your small children must trust you to put food on the table. You do not trust the older child at the tender age of 6 years old to stay with his 2-year-old brother; his idea of fun would be to feed his dinner to the dog and to feed the dog food to his brother. This, of course, is a one-way trust relationship.

You make NT domain trust decisions in a similar fashion. If you need for folks in domain A to be able to access resources in domain B, but not vice versa, you establish a trust relationship between domains B and A. You would say that A was trusted by B, and that B trusts A.

If one person in one of your NT domains (domain B) cannot access a resource (a share or a printer) in another one of your NT domains (domain A), you probably want to check the trust relationship. Make sure that the domain providing the resource is trusting, and that the domain that needs the resource is trusted. Take the following steps:

1.  Go to the NT server of the domain with the resources (domain A).

2.  From the Start menu, select Programs|Administrative Tools|User Manager for Domains.

3.  From the Policies menu in the User Manager, select Trust Relationships.

4.  Make sure the other domain (domain B) is listed as trusted.

5.  Go to the NT server of the trusted domain.

6.  Start the User Manager and check the trust relationships again.

7.  Make sure the first domain (domain A) is listed as trusting.

I’ve been in a shop where we needed to establish a two-way trust relationship between two domains via a wide-area link. Even though we established the trust relationship properly, it seemed to fail. The system administrator got the following message when he attempted to administer the remote domain:

There are no logon servers available to service the logon request

The key was in the fact that these were wide-area linked domains, and they relied on TCP/IP as a protocol. They therefore relied on WINS for name services between the domains. WINS was not configured properly; a quick search on TechNet revealed what to do. We ended up reconfiguring WINS between the two domains, ensured that WINS itself worked properly, and the problem went away. (I discuss TCP/IP and WINS in the next section.)

TCP/IP Graffiti

The handwriting on the wall is that more and more Windows functions are going to rely on TCP/IP, particularly over WANs. Accordingly, you’ll want to become very familiar with the various TCP/IP concepts and commands that exist, both under Windows and other operating systems. In this section, we’ll take a look at the server programs that exist to make your life as a troubleshooter and part-time network administrator as easy as possible by automating network configuration. We’ll start out with DHCP, which automatically assigns workstation addresses instead of forcing you to assign them per workstation. Then we’ll move on to Windows networking name resolution.

DHCP

DHCP (Dynamic Host Configuration Protocol) is probably one of the most important TCP/IP technologies that has arisen in the last couple of years. It allows each TCP/IP workstation to broadcast once during each session and automatically obtain an address and other information from the DHCP server. Actually, the way it works is that a workstation that doesn’t know its TCP/IP information must broadcast to the entire segment to obtain a lease on a TCP/IP address from the server. (“Hi everybody! I need an IP address, please.”) When the lease runs out, it must rebroadcast to renew the lease. DHCP lease lengths are configurable at the server, as is the DHCP scope—that is, the range of addresses served to client machines. (For example, one server’s scope on the 192.168.1 network might be 192.168.1.10 through 192.168.1.50 for a 40-user network.)

DHCP is a much easier way to keep track of IP addresses than assigning them per workstation. I’ve found that DHCP seriously reduces the number of duplicate IP addresses on a network, which reduces the number of problems you have to deal with.

---

Because one of DHCP’s good points is that it allows you to quickly change large numbers of workstation IP addresses, you should make your lease length short enough to accommodate weekend reconfigurations—that is, not longer than one or two days.

---

DHCP is actually integral to using TCP/IP in a happy and healthy way for Microsoft file and print. Finally, you have the option to make workstations that use TCP/IP for NetBIOS name resolution and browsing into nonbroadcast nodes. Yippee!

You can configure workstations within a DHCP scope into point-to-point, nonbroadcast workstations (or p-nodes), broadcast nodes (b-nodes), or hybrid nodes (h-nodes—or node type 0x8—as shown in Figure 11.1) that first try to talk directly and then broadcast if they have no other alternative. The kicker here is that you need to invest in Windows NT to get a DHCP server; Microsoft does not supply a DHCP server for workgroups.

Figure 11.1  The DHCP manager can show you all client leases, thus allowing you to easily figure out which users have which IP addresses.

DHCP can potentially distribute many configuration items automatically, one of which is the address of the WINS and/or the DNS server for the network (see the section titled, “TCP/IP Name Resolution,” later in this hour). This is awesome, because it seriously cuts down on fat-finger syndrome. You can be pretty sure that if one workstation has the right DNS and WINS information, they all do (rather than wondering if somebody has fat-fingered a given workstation’s DNS and WINS info). This saves you a lot of time when troubleshooting.

Well, this all sounds wonderful, but what happens if your DHCP server goes down? On a small network where the server is the DHCP server, this doesn’t matter for small periods of time. The concept of DHCP leases means that unless the lease expired right after the server went down, your folks probably still have IP addresses even without the server. (However, they’re probably annoyed nonetheless, because their files are on that server.)