When you’re building a multi-site domain that’s routed across several subnets, you may assume that putting a backup domain controller in a remote site will ensure that the clients at that site will be validated locally. The purpose, of course, is twofold: to reduce the traffic that will go outside the LAN over an expensive link and to ensure that client logons are not delayed by the speed (or lack of it) of the WAN connection. Installing a local domain controller may indeed work, but will that success be by design or by accident?
Unfortunately, there’s no way to specify the domain controller that will validate a given client, whether that client is running Windows NT Server, Windows NT Workstation, or Windows 9x. Previous versions of Windows will work in the same way, provided that they’re using the 32-bit TCP/IP stack or a 16-bit WINS-aware TCP/IP stack.
In this Daily Drill Down, we’ll give you an overview of the processes that are involved. We’ll also explain why a domain controller that’s sited in another country on a slow modem link may be the one chosen by a client machine to service its logon request.
Background
For those of you who aren’t familiar with the concept of Windows NT domains, here’s a quick refresher: An NT domain is a collection of network-enabled servers and other computers that share common security and account information. The domain provides for centralized user, computer, and network administration. The security information is held in a central database on a server that’s designated and configured as the primary domain controller (PDC) and is replicated to other special servers, which are designated and configured as backup domain controllers (BDC). Only one server can be the PDC at any one time, but this special role can be transferred to any BDC as required. When a client who’s running TCP/IP attempts to log on to this NT domain, the logon request is processed by any of the network’s domain controllers that belong to the same domain.
WINS
WINS servers maintain a list of all WINS-enabled clients on the network. WINS servers also maintain a list of domain controllers that are identified as type <1C>. For reasons known only to them, the designers of WINS decided that there should be a limit of 25 entries in the <1C> list, which means that subsequent domain controllers will not appear on this list. Clients are provided with this list when they attempt to find a domain controller to service their logon request.
The order in which the domain controllers appear on the list follows this logic:
- Domain controller entries registered with the WINS server, in the order of most recently refreshed to least recently refreshed
- Domain controller entries obtained from replication with other WINS servers
- The first entry is always the PDC
Nodes
When configuring TCP/IP on a client, one of the options that you may see (depending on the installation) is the node type. The node type refers to how the client finds a domain controller to service its logon requests.
There are four node types in TCP/IP:
- B-node (broadcast node): When a client needs to find a domain controller, it will perform a broadcast. The first domain controller to respond will be handed the job of servicing the logon request.
- P-node (point-to-point node): In this environment, name queries go directly to the WINS server.
- M-node (multi-homed node): An m-node environment uses b-node first and then—if necessary—p-node to resolve names.
- H-node (hybrid node): An h-node environment uses p-node first and then b-node if the name service is unavailable.
Let’s examine each node type more fully.
B-node
The b-node mode uses broadcast messages for name registration and resolution. For example, if a computer named NT_PC1 wants to communicate with a computer named NT_PC2, NT_PC1 sends a broadcast message that it is looking for NT_PC2. It then waits a specified time for NT_PC2 to respond.
B-node has two major problems:
- In a large environment, it loads the network with broadcast messages.
- Typically, routers do not forward broadcast messages, so computers on opposite sides of a router never hear the requests.
Examples of computers on the network that might be b-node clients include computers running MS-DOS, Windows 3.1, or Windows for Workgroups that do not have WINS client software installed. Possible servers include Server Message Block (SMB)-based network servers, such as IBM LAN Server, DEC PATHWORKS, AT&T StarLAN, and LAN Manager for OS/2 or UNIX systems.
P-node
The p-node mode addresses the issues that b-node does not solve. In a p-node environment, computers neither create nor respond to broadcast messages. All computers register themselves with the WINS server, which is responsible for knowing computer names and addresses and for ensuring that no duplicate names exist on the network.
In this environment, when NT_PC1 wants to communicate with NT_PC2, it queries the WINS server for the address of NT_PC2. Upon receipt of the address, NT_PC1 goes directly to NT_PC2 without broadcasting. Since the name queries go directly to the WINS server, p-node avoids loading the network with broadcast messages. Since broadcast messages aren’t used and the address is received directly, computers can be on opposite sides of routers.
The most significant problems with p-node are:
- All computers must be configured to know the address of the WINS server.
- If the WINS server is down, computers that rely on it to resolve addresses can’t get to any other systems on the network.
M-node
The m-node mode was created primarily to solve the problems associated with b-node and p-node. In an m-node environment, a computer first attempts registration and resolution with b-node. If that fails, it switches to p-node. Advantages include:
- M-node can cross routers
- Since b-node is always tried first, computers on the same side of a router continue to operate as usual if the WINS server is down
- In theory, using m-node should increase LAN performance
H-node
The h-node mode solves the most significant problems associated with broadcast messages and routed-environment operations. This mode is a combination of b-node and p-node that uses broadcast messages as a last resort. The h-node mode does more than change the order for using b-node and p-node: If the WINS server is down—making broadcast messages a necessity—the computer continues to poll the WINS server. When the WINS server can be reached again, the system returns to p-node. H-node also can be configured to use the LMHOSTS file after broadcast name resolution fails.
Since p-node is used first, no broadcast messages are generated if the WINS server is running, and computers can be on opposite sides of routers. If the WINS server is down, b-node is used, so computers on the same side of a router continue to operate as usual.
Other combinations
Another variation, known as modified b-node, is also used in Microsoft networks so that messages can go across routers. Modified b-node does not use p-node mode or a WINS server. In this mode, b-node uses a list of computers and addresses that are stored in an LMHOSTS file. If a b-node attempt fails, the system looks in LMHOSTS to find a name and then uses the associated address to cross the router. However, each computer must have this list, which creates an administrative burden because the list must be maintained and distributed. Both Windows for Workgroups 3.11 and LAN Manager 2.x used such a modified b-node system. Windows NT uses this method if WINS servers are not used on the network. In Windows NT, some extensions have been added to this file to make it easier to manage, but modified b-node is not an ideal solution.
Some sites might require both b-node and p-node modes. Although this configuration can work, administrators must exercise extreme caution and use it only for transition situations. Since p-node hosts disregard broadcast messages and b-node hosts rely on broadcast messages for name resolution, the two hosts potentially can be configured with the same NetBIOS name, leading to unpredictable results. Also, if a computer configured to use b-node has a static mapping in the WINS database, a computer configured to use p-node cannot use the same computer name.
Computers running Windows NT can be configured as WINS proxy agents to help the transition to using WINS. Windows-based networking clients (WINS-enabled Windows NT, Windows 95, or Windows for Workgroups 3.11 computers) can use WINS directly. Non-WINS computers that are b-node compatible (as described in RFCs 1001 and 1002) can access WINS through proxies. A WINS proxy is a WINS-enabled computer that listens for name-query broadcast messages and then responds for names that aren’t on the local subnet. Proxies are p-node computers.
When configuring TCP, you won’t find any way of setting the node type. The node type is set to a default during TCP configuration. The default Windows 95 TCP/IP node types are:
If DHCP=False, and WINS is disabled, then Node Type b-node (0x01)
If DHCP=False, and WINS is manually set, then Node Type h-node (0x08)
If DHCP=True, and DHCP sets WINS, then Node Type h-node (0x08)
If DHCP=True, and WINS is manually set, then Node Type h-node (0x08)
If DHCP=True, and WINS is disabled, then Node Type b-node (0x01)
If WINS server options are provided via DHCP, then Node Type should be set using DHCP option 46; however, locally defining a WINS server on the client will override these two options because locally defined WINS servers automatically set your node type to h-node.
The node type can be changed manually by editing the Windows 95 Registry. The location exists under the HKEY_LOCAL_MACHINE subtree under the subkey
SYSTEM\CURRENTCONTROLSET\SERVICES\VXD\MSTCP\Node Type
NodeType can be added as a String value under MSTCP if it doesn’t exist already.
The logon request
Now, let’s look at what takes place after the client enters the username, password, and domain information and clicks OK in the logon prompt window (before the logon request is serviced). Windows 9x and Windows NT behave slightly differently, so I’ll discuss them separately.
Windows 9x client
The client attempts to find a domain controller in a way defined by the node type with which it’s been configured. Below is a very simplified sequence of events:
- A b-node client will broadcast a request. If a server does not respond, the logon will fail.
- A p-node client will request the <1C> list from the WINS server. It then will broadcast a request to each of the servers in the <1C> list in turn, starting with the first (the PDC).
- The m-node and h-node clients do both of these things in the order described above, except that, if the client’s workgroup name is the same as the account domain to which the logon is being attempted, the WINS lookup for domain controllers on the local subnet is skipped. Provided that the WINS server is active and reachable, it means that the first domain controller in the <1C> list to respond will always handle the logon request.
As mentioned above, to ensure that the client is validated by the local domain controller, you must make the workgroup name the same as the domain represented by that domain controller. However, if you want to use workgroups within the office environment, this method of ensuring local validation may not be acceptable. In this case, the node type should be set to m to ensure that the client broadcasts on the local subnet initially so that there is a better chance of the local domain controller responding first. Note that it isn’t a hard and fast rule. The domain controller only needs to be a bit busy—which remote site servers often are because it’s usual for administrators to put a single domain controller at a remote site—and a more responsive, non-local domain controller could get in first.
Alternatively, WINS could be installed on the local domain controller, and the clients could use it as the primary WINS server. This method may be a good idea if users rarely access resources outside of the local branch, but it is an extra burden on the server, which is probably providing file and print services, DHCP, SQL, Exchange, and other duties.
If the workgroup name is different from the account domain, then using m-node will increase the chances of getting the logon request serviced locally.
Windows NT client
Windows NT logon is somewhat different from Windows 9x logon—the NT Workstation has a machine ID in a domain. So, the client goes through four steps for logon validation. First, the NT Workstation client validates its machine ID with the domain controllers from the resource domain, and then it sends user logon information for pass-through validation. The domain controller from the resource domain passes the logon information to a domain controller in the account domain. The resource domain-domain controller then passes back the user authentication information (received from the account domain-domain controller) to the user.
Whether or not users are logged on to them, NT Workstation clients go through ID validation during initialization and as required later (such as if someone logs on to the NT machine with the local cached profile because the resource domain controller is down).
First comes name resolution of the domain controllers. The NT Workstation client must locate a resource domain-domain controller. The discovery process that’s used by an NT Workstation client to find a resource domain controller is the same as the one that’s used by the resource domain-domain controller to establish a trusted connection with an account domain-domain controller.
Next, the NT machine ID is validated. The NT Workstation client always sends a local logon broadcast to Resource-Domain <1C> before sending unicast logon requests to resource domain-domain controllers that are obtained from WINS.
The client validates the NT Workstation machine ID—with the first domain controller from the resource domain to respond back to the logon request.
The NT Workstation client requests the resource domain-domain controller to enumerate the trusted domain list. The obtained domain names are displayed in the Domain drop-down box in the logon window.
The NT Workstation client passes the user logon credentials to the resource domain-domain controller and requests pass-through authentication.
The resource domain-domain controller passes the user logon credentials to the account domain-domain controller with which it has established a trusted connection and requests it to authenticate the user. It then passes back the validation information to the NT Workstation client.
The NT Workstation client gets the name of the account domain-domain controller from the resource domain-domain controller to connect and execute the logon script/profile, if it’s been configured.
The NT user is now logged on to the account domain, has executed a logon script, and has made appropriate network connections to home directories.
Of course, if the machine ID is registered with a domain outside of the local subnet or if the user is logging on to a domain that does not have a domain controller on the local subnet, the logon process will require communication over the WAN. If it’s a slow link, the logon process will be extended.
Conclusion
With Windows 9x clients, getting authenticated locally is achieved by making the workgroup name the same as the logon, or account, domain or by using b-mode or m-node to ensure that the logon request is broadcast locally first. Obviously, b-node is not very versatile, and it will cause a failed logon if the local domain controller doesn’t respond quickly.
With Windows NT clients, there should be a resource domain controller and an account domain controller in the local segment. (It could be a single server if the resource and account domains are the same.)
You can enhance the process further by having multiple WINS servers and by pointing the clients to the WINS server that will register the local, or nearest, domain controller in the <1C> list.
Richard Charrington’s computer career began when he started working with PCs—back when they were known as microcomputers. Starting as a programmer, he worked his way up to the lofty heights of a Windows NT Systems Administrator, and he has done just about everything in between. Richard has been working with Windows since before it had a proper GUI and with Windows NT since it was LANManager. Now a contractor, he has slipped into script writing for Windows NT and has built some very useful auto-admin utilities.
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.
