|Previous||Table of Contents||Next|
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.
FIGURE 7.1 The master domain model
FIGURE 7.2 The multiple master domain model
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 numbera 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 Id 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 identificationtypically 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 DNSare each unique, though they provide similar functions.
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.
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:
|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 Microsofts 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.
|Previous||Table of Contents||Next|