Systems Engineering - Under the Hood of Client Logon (Windows 95 and Windows NT 3.51 and 4.0)

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : July 1, 1997

By Prakash N. Murthy, MCSE

You might assume that placing a backup domain controller at remote locations will ensure that clients get validated locally. But here's the nitty-gritty on how Windows 95 and Windows NT really handle client logon. You may be surprised.

In this article, I explain the process that occurs when a Microsoft network client logs on to a Windows NT domain in a TCP/IP environment. I also provide a set of recommendations for optimizing the logon process for your LAN/WAN environment. By understanding how the logon procedure works, you can avoid a common NT domain design mistake that needlessly uses up costly WAN resources.

First of all, here's some refresher information for you on NT domains. A Windows NT domain is a logical grouping of network servers and other computers that share common security and user-account information. The domain also provides centralized user and network administration. The security and user-account information for a domain are stored in a central directory database. The master copy of the directory database is stored on the primary domain controller (PDC) and is regularly synchronized/replicated to backup domain controllers (BDCs) to maintain centralized security.

When a client logs on to a Windows NT domain, the logon request can be processed either by the PDC, or by BDCs belonging to the domain. In a typical TCP/IP-based network environment of most medium to large companies, the BDCs are spread across the WAN. This is done to accommodate local client logon requirements at remote office locations.

Many customers and network design/implementation professionals assume that placing BDCs at remote locations will ensure that clients get validated locally. This can be a costly mistake in designing Windows NT domains spread across a WAN environment—costly because it may use up WAN resources needlessly.

Say you're working in a corporate TCP/IP-based network environment that consists of Microsoft Windows NT servers, Windows NT Workstations, and Windows 95 clients. It's impossible for you to define the domain controller (DC) that validates a domain user. The problem is that your users may end up getting validated by a DC across the WAN—in other words, over an expensive link. This logon request will be broadcast locally and then sent serially to other BDCs across the WAN. If the local DC is able to respond to the request fast, then the request across the WAN can be prevented.

Some Assumptions

I make several assumptions about the environment in this article. First, the DC is a Windows NT Server 3.51 or 4.0, and the clients are Windows 95 and NT Workstations (version 3.51 or 4.0). If you're running other clients, you can apply the concepts I discuss here for Windows 95 to other network clients like Windows for Workgroups 3.11 (as long as you're working with a 32-bit TCP/IP stack), as well as other 16-bit clients with WINS-aware TCP/IP stacks. Also, the logon process I detail encompasses NetBIOS node types of H-node and M-node. (You should be able to interpret the expected behavior for the P-node and B-node from our results.)

In order to keep the article brief, I leave out some points in the discussion:

The logon flowchart (Figure 1) doesn't include every step of the domain controller name resolution; for example, I omit things like using LMHOSTS and DNS.
Also, although you can use DNS (along with a few NT client patches) in a limited way to define DCs for client logon, I don't discuss it here. (To learn more, refer to the resources listed in "Additional Information.").
The NetBIOS-over-TCP/IP (NetBT) name cache (the name resolution flowchart, Figure 2) can't be used in the logon process, since the cache lacks the domain information.

I'll use the following NetBIOS group names throughout my explanation of the logon process. (For more coverage of this, again, refer to resources in "Additional Information.")

Domain <00> = NetBIOS group name.
Domain <1C> = NetBIOS Internet group name.

And I use these symbols:

AD <00>
Resource1Domain <1C>

The WINS Domain <1C> List

WINS servers maintains a list of all the DCs. A client query for a list of DCs, the NetBIOS Internet group name for a domain (Domain <1C>), will return a list of a maximum of 25 DC entries for the domain and their IP addresses. Their ordering within the list follows this logic:

Domain controller entries registered with this 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.

With that understanding, let's walk through the logon validation of a Windows 95 client and then the process for a Windows NT client. By doing this, you'll come to understand the logon process in detail, and you'll see how you can design your system to avoid costly remote logons.

The Windows 95 Process

If you find visual representation helpful, you can refer to Figure 1 to follow along.

Figure 1: The Windows 95 process

First, comes the name resolution of the DCs&

The DC name resolution [Account-Domain <1C>] follows the NetBIOS name resolution based on the NBT node type flowchart documented in TechNet.
If the workgroup name is different from the Account-Domain name, the Windows 95 client queries for Account-Domain <00>, following the NetBIOS name resolution pattern.

&then sending netlogon requests to DCs:
The Windows 95 client, broadcasts (limited IP broadcast) netlogon request for Account-Domain <00>, before using NBT name resolution methods, for resolving Account-Domain <1C>.
The client broadcasts netlogon requests for Account-Domain <1C> name and then sends unicast netlogon requests serially to all the DCs (contained in the Account-Domain <1C> group name) obtained from the WINS query.
The client, for the logon process, will use the first DC that validates the client's logon request.

Note: The Windows 95 client sending logon request to AD<00> name is for backwards compatibility with LAN Manager domains.

The Windows NT Process

You may wonder why you can't use the same domain model with NT Workstation as you do with Windows 95. The domain model doesn't apply the same way with Windows 95 as in NT. In NT, the machine accounts are normally defined in the resource domain. In the case of Windows 95, the normal recommendation would be to make the workgroup name equal the resource domain name. But, in reality, people choose their own workgroup names, so the above explanation is a definite possibility.

Figure 2: The Windows NT process

When a user logs onto an account domain from an NT Workstation machine belonging to the resource domain, the client goes through four steps for logon validation. First, the NT Workstation client validates its machine ID with the DCs from the resource domain, then sends user logon information for pass-through validation. The DC from the resource domain passes the logon information to a DC in the account domain. The resource domain-DC then passes back the user authentication information (received from the account domain-DC) to the user.

I should note that whether or not users are logged onto them, NT Workstation clients go through ID validation and the enumerating of trusted domains during initialization and as required later (such as if the NT machine is logged on using the local cached profile because the resource DC is down).

Again, if you find visual representation helpful, you can refer to Figure 2 to follow along.

First comes name resolution of the DCs. The NT Workstation client must locate a resource domain-DC. To do this, the client follows the NetBIOS name resolution (based on the NetBT node type) flowchart mentioned earlier and shown in Figure 2. The discovery process, used by an NT Workstation client to find a resource DC, is the same as that used by the resource domain-DC to establish a trusted connection with an account domain-DC. More on this shortly.

Next, the NT machine ID requires validating. The NT Workstation client always sends a local netlogon broadcast to Resource-Domain <1C> before sending unicast netlogon requests to resource domain-DCs obtained from WINS.

The client validates the NT Workstation machine ID, with the first DC from the resource domain to respond back to the logon request.

The NT Workstation client requests the resource domain-DC to enumerate the trusted domain list. The domain names obtained are displayed in the From dialogue box of the logon screen, as shown in Figure 3.

Figure 3: The domain names obtained by the NT client display in the From dialogue of the logon screen.

Figure 3: The domain names obtained by the NT client display in the From dialogue of the logon screen.

In the next phase of the process, the NT Workstation client passes the user logon credentials to the resource domain-DC and requests pass-through authentication.

The resource domain-DC requests the account domain-DC (by relaying the user logon credentials) with which it has a trusted connection established (as explained in the earlier steps) to authenticate the user. It then passes back the validation information to the NT user.

The NT Workstation client gets the name of the account domain-DC from the resource domain-DC to connect and execute the logon script/profile.

At the end of this step, the NT user is logged on to the account domain, has executed a logon script, and made appropriate network connections to home directories.

How the Discovery Process Works

The resource domain-DC discovers a DC from the account domain to establish a secure channel for trust-based communications. This occurs during boot up and later as required. The trust communication is managed by the netlogon service. The process used by the resource domain-DC to discover and establish a secure connection with an account domain-DC works like this.

The resource domain-DC uses the NetBT name-resolution technique to obtain the list of account domain-DCs. Then it sends a netlogon broadcast to the Account Domain-DC <1C> name and unicast netlogon requests serially to all the DCs obtained from the WINS query.

Last, it establishes a trusted connection with the first account domain-DC to validate the netlogon requests.

The process of rediscovering an account domain-DC by the resource domain-DC can occur for several reasons. Perhaps the account domain-DC with which the resource domain-DC had a connection is down. Maybe the resource domain-DC has restarted. The netlogon service has stopped and restarted. Or the connection could have been lost due to network or other problems.

Some General Recommendations

The whole idea of understanding the process is to increase the chance of clients getting validated by a local DC, thereby reducing costly remote logons. I base the following recommendations on the fact that the client broadcasts a netlogon request locally before sending a unicast netlogon request to the DCs.

Tip 1: Same Segments for DCs

At remote sites with local resource domains, place the resource domain-DCs and account domain-DC on the same segment. This will reduce the possibility of the resource domain-DC communicating with a account domain-DC across the WAN.

Tip 2: Same Segments for NT Machines

At remote sites having a local resource domain (with few resource domain-DCs spread across multiple subnets in the same location) with lots of NT workstations, put as many NT machines as possible on the same segment as the resource domain-DC. This ensures that the NT clients establishes a connection with a local resource-domain DC and doesn't send unwanted netlogon requests to all the resource domain-DCs in that location.

Tip 3: Same Segments for NT and Resource Domain DCs

If the resource-domain spans multiple physical sites, and these sites have many NT workstations, put the NT machines on the same segment as the resource domain-DC. This prevents the NT workstations from going across the WAN to establish sessions with remote resource domain-DCs.

Tip 4: Multiple NICs

For remote sites having predominantly Windows 95 clients configured as M-node with multiple IP subnets and one account domain-DC, evaluate having multiple NICs (one for each subnet) in the DC. This gives the account domain-DC the flexibility of responding to a client's broadcast netlogon requests on multiple subnets. In such situations, if the costs are too prohibitive to allow client logon requests to occur over the WAN, consider opening up user datagram protocol (UDP) ports 137, 138, and transport control protocol (TCP) port 139 between local LAN segments only. You'll have to weigh the pros and cons of this option carefully for your environment.

Tip 5: Put WINS To Work

The client (both Win95 and NT Workstation) sends unicast logon requests serially to all the DCs in the same order as the names returned from WINS. The list of DCs from WINS contains directly refreshed names before the replicated ones. Therefore, the client actually sends the unicast logon requests to just-refreshed DCs (through the WINS server) before replicated DCs. So it makes sense to configure the clients to use the same WINS server responsible for registering the DC you'd prefer the client to use.

For example, if you have a WINS server at a remote office that registers DCs in that office, then configure the clients at this remote office to use the same WINS server. This enhances the possibility of the clients using the local DCs, regardless of the remote office having multiple IP subnets.

To extend this example, much like replicated DC names follow directly refreshed DC names, the order of the replicated DC names is also well known. Specifically, names directly refreshed on the replica WINS source appear before names replicated to the WINS source.

Therefore, you can set up a replication hierarchy for the WINS servers to take advantage of their geographical environment. If you have a three-tier infrastructure hierarchy (such as a remote branch office, regional office, and corporate office), then it follows that the clients at the branch office should use DCs in this order: local, regional, and corporate. However, if the local DC were slow compared to the remote DC, then there might be times when the remote DC should validate the clients.

Final Thoughts

In a typical network environment consisting of Windows NT domains, it's a challenge to predict what DC will validate the client—which, in turn, adds an additional level of design challenge in the placement of the DCs across the LAN/WAN environment. I hope you'll find the client logon process I describe in this article useful in the optimal design of your NT domains.

I'd like to thank Cliff Van Dyke for reviewing this article and recommending changes.

Prakash N. Murthy, MCSE, is a consultant with Microsoft Consulting Services(MCS) in Atlanta. He specializes in analyzing, designing, and deploying mission critical IS infrastructure systems using Microsoft BackOffice products for Fortune 100 companies. He has been actively involved with networking, messaging, and systems management consulting for several years now. His areas of expertise and interests are in-depth protocol analysis (with a specialty in TCP/IP),enterprise network architecture and design, Internetworking, and multi-vendor systems interoperability and integration. His last article for MCP Magazine, " Integrate WINS and DNS in Your Internetwork,"appeared in the May/June 1996 issue. Reach him at Prakashn@microsoft.com.

Additional Information

Learn more about NetBIOS name resolution by studying the flowchart found on Microsoft's TechNet CD or MSDN. You can see the flowchart online by registering for free MSDN access at https://premium.microsoft.com/msdn/library/, then accessing https://premium.microsoft.com/msdn/library/winresource/ntserv/fa/dc/s3378.htm.
The Windows NT Server 4.0 Resource Kit, Networking Guide, from Microsoft Press, is also useful in understanding DCs. ISBN 1-57231-344-7.

Reprinted with permission from Microsoft Certified Professional Magazine, the career and technical magazine for Microsoft Certified Professionals. For subscription information, call toll-free (888) 4MCPMAG or (714) 476-1015, or send e-mail to mail@mcpmag.com.