Windows Domains

The domain concept establishes the authentication and security administration model for Windows-based networks. However, there are times when scalability or administrative concerns warrant the use of more than a single domain controller.

There are several domain models that are employed in modern Windows networks. They range from the relatively simple single domain, which is best suited to smaller organizations, to the multiple master domain model, which is typically used in large, multinational organizations.

Single domain-A single domain model is best used for small to medium-sized environments with a single administrative scope.

Global domain The global domain model incorporates numerous domains that are administered by different organizations, typically within the same corporation. In this configuration, all domains trust all other domains.

Master domain In the master domain model (see Figure 7.1), all other domains trust a single master domain. This model may be well suited to situations when authentication needs to be centralized but control of resources needs to be administered at the departmental level. The master domain trusts no other domain.

FIGURE 7.1  The master domain model

Multiple master domain The multiple master domain model (see Figure 7.2) is simply a scaled-up version of the master domain model. In this configuration, multiple master domains trust each other, and each individual master domain is responsible for serving as the master domain for its single domains.

FIGURE 7.2  The multiple master domain model

Name Resolution Services

Computers are quite comfortable operating with numerical values of significant length. Humans, on the other hand, typically appreciate text-based information and names. For example, we could certainly address everyone by a unique identification number—a Social Security number in the United States, for example. Thus, people would address me as 123-45-6789, and I would never turn around when someone said “Rob” at a party. Unfortunately, I have a difficult time remembering my own Social Security number, let alone those of my friends, family, and colleagues. (Of course, I sometimes forget names too, but I’d prefer not to dwell on that.)

In the computing environment, this idea holds true. I could certainly ask you to connect to the Web site at 10.62.70.133, but that would be harder to remember and would communicate no information regarding the content of the site. Yet if I were to say, “Connect to www.sybex.com,” you would have an immediate trigger for remembering the site name and likely would associate it with this book.

All that said, a name resolution service provides users with a simple mechanism for names to associate with computer-related identification—typically an address operating at Layer 3 of the OSI model. As detailed in the next sections, the common name resolution services in Windows networking— LMHOSTS, WINS, and DNS—are each unique, though they provide similar functions.

LMHOSTS

The first generation of name resolution services for NetBIOS involved the LMHOSTS file. This file was manually maintained and static, and it resolved host names in the LAN Manager (LM) environment. The file could be maintained on each host and typically listed only a few critical resources, including off-subnet domain controllers.

The LMHOSTS file could also reside on the Primary Domain Controller. In this configuration, the clients would query the PDC for information. Unfortunately, this configuration required a great deal of manual effort, and maintenance of the file was only possible for small networks. Therefore, this configuration is not recommended as a modern solution.

WINS

Designers need to remember that Windows-based networking was originally designed for small, single-network environments. This meant that broadcasts were an acceptable method for registering and locating services. However, in modern routed networks, broadcasts are not permitted to cross Layer 3 boundaries. In addition, addressing of IP resources migrated from static assignments to dynamic ones, which simplified administration at the host and worked to prevent the waste of IP v4 addresses.

It became fairly clear that the LMHOSTS file would not scale to support significant networks. Each machine was tasked with maintaining its own file, and administrators either frequently scheduled downloads to keep the information on each workstation current or they had to maintain an LMHOSTS file on the PDC that was referenced by each workstation in the network.

To provide a dynamic method for registering NetBIOS names and associating them with IP addresses, Microsoft developed the Windows Internet Name Service (WINS). The service provides the following benefits:

•  Clients on different subnets can register with a central repository for name resolution.

•  Dynamic host address assignment (DHCP, or Dynamic Host Configuration Protocol) can be used while preserving name resolution services.

•  Broadcasts can be reduced significantly.

•  NetBIOS names can be mapped to IP addresses.

	Though WINS allows for broadcasts to be reduced significantly, by default the clients will still broadcast name information for compatibility with older systems. Broadcasts should be disabled whenever possible. While beyond the scope of this book, interested readers should consult Microsoft’s documentation regarding B-nodes, P-nodes, and H-nodes.

The WINS mechanism requires that the workstation know the address of the WINS server. This may be manually configured on the client, but it is typically provided in concert with DHCP. With the specific IP address of the WINS server, the client may communicate using unicast packets.

	DHCP is described in greater detail later in this chapter.

The WINS server may also be accessed via a subnet broadcast mechanism, and designers may wish to consider using the WINS Relay function to forward WINS datagrams. This installation effectively proxies the WINS server onto the local subnet but, due to the extra administration and cost factors, is seldom used. Recall that proxies add additional overhead and latency

Finally, there may be multiple WINS servers on the network for redundancy and scalability. These servers interconnect via a replication process. Under this configuration, the client is configured (locally or via DHCP) with multiple WINS server addresses. Upon bootup, the client registers with a WINS server; if a server in the list is unavailable, the client attempts a connection with another in the list. This configuration is particularly common in international networks, as the latency and cost of sending name information across the WAN is quite high (albeit quickly becoming cheaper). However, performance for the end user is substantially greater with a local name resolution resource.