Technical Guide to Secure Channels and the NT Client Authentication Process

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.

By Alan von Weltin, Microsoft Consulting Services, Greater Pennsylvania District

AT A GLANCE

Key Point: Systems administrators in large Windows NT environments with multiple Backup Master Account Domain Controllers should monitor for user authentications performed by a non-local BDC.

Detail: Medium Task: Deploying, Administration

Article Section	What's There
Introduction	Scope of the problem, how to identify it, and a preview of steps to resolve.
Understanding the NT Client Authentication Process	Two steps that define where a given NT Workstation is authenticated.
Resource Domain to Account Domain Trust Communications	How Resource Domain DC establishes a secure channel to a Master Account Domain DC for trust communications and routes user requests for account authorization.
Monitoring and Managing Secure Channel Connections	Two basic approaches that administrators can take to manage secure channels.
Tools	Four Microsoft tools to view and modify how secure channels are configured.
Conclusion
More Information	Links to more information.

Introduction

Users in a large Windows NT environment who logon to local Backup Domain Controllers (BDC) for Master Account Domain authentication may instead be authenticated by a non-local BDC. In fact, a Windows NT Workstation user trying to logon to the network may not realize that the authentication is coming from a Master Account Domain Controller that is NOT local to that user.

Non-local logons may present a problem in your organization depending on your actual network and NT Domain design. Some possible outcomes include:

Long logon times
Needless utilization of WAN links
Failure to run logon scripts

Large organizations typically deploy BDCs to remote areas to enable a local logon. However, this issue can affect large NT deployments with multiple Backup Master Account Domain Controllers that span wide geographical areas. For example, a user in London may be authenticated across the WAN by a server in Puerto Rico.

This paper provides information on diagnosing and resolving non-local logon problems. Only experienced NT System Administrators with knowledge of NT Multiple Master Account Domains, Trust Relationships, and the Windows Internet Name Service (WINS) should implement the recommendations.

Note: This paper is focused on the Windows NT Server and NT Workstation. The Windows 95 client logon process is not addressed.

How Does This Issue Manifest Itself?

Depending on your specific network and NT domain design, users who have been authenticated by a remote Domain Controller (DC) may notice the following symptoms:

The logon process seems to take longer than it should.
Logon scripts may not run or other processes may fail if replication has not been enabled to the remote DC.
If implemented by the administrator, the user may see a dialog box that displays the name of a validating DC that is foreign to the user.

However, this issue may be occurring on your network now even without any symptoms or complaints from users. Proactive NT System Administrators are advised to use the tools described below to monitor and better understand their network.

How Can This Issue be Resolved?

There are several methods available for NT System Administrators to monitor and change the specific system functions involved in determining where a client is authenticated. These tools are discussed in the section, "Monitoring and Managing Secure Channel Connections."

Understanding the NT Client Authentication Process

The first thing to realize is that simply placing Backup Domain Controllers (BDC) for the Master Account Domain at remote locations does not assure local (non-WAN) user authentication.

To understand why requires an understanding of the Netlogon, Discovery, and Secure Channel functions and the interaction of the NT Workstation Machine Account to the Resource Domain and the Resource Domain to a trusted Master Account Domain. This paper does not go into exhaustive detail about these processes, but it does describe critical aspects of the Discovery process.

The important point to grasp is how NT Workstations get authenticated, starting with the two critical steps that define where a given NT Workstation is authenticated.

Discovery Part One: Computer Account to Resource Domain Controller

Before a user logs on at an NT Workstation, the Workstation will attempt to validate its Machine Account and create (Discover) a secure channel to a Resource Domain server.

The figure below represents a Windows NT Workstation establishing a secure channel with a Domain Controller in the Domain where its Machine Account is located.

Figure 1: A secure channel for Windows NT Workstation

The NT Workstation does this by first querying WINS for Resource Domain <1C> entries and then sending a local broadcast for the entries WINS returned. If the local broadcast fails, the Workstation will begin sending serial logon requests (logon requests sent one at a time) to the entries (list of servers) that WINS returned.

Note: This scenario assumes that the administrator has determined that NT Workstation Machine Accounts will be located in Resource Domains. It also assumes that the NT Workstation has been configured as an H-Node client. When NT Workstation is configured as a WINS client, H-Node will be the default node type. Reference the Windows NT Server 4.0 Resource Kit for a full description of WINS and NetBIOS Node Types. See the "More Information" section below for a pointer.

WINS is very important because the list of Resource Domain <1C> names returned to the client will be ordered first by the entries that were most recently refreshed, and then by entries obtained via replication (entries that have been pushed into the WINS database).

Recommendation Carefully review your WINS architecture and consider to which WINS servers a client should be directed.

Discovery Part Two: Resource Domain Controller to Account Domain Controller

The second part of the NT Workstation logon process is understanding the Discovery and Secure Channel process initiated by a Resource Domain Server to a Master Account Domain Server. Figure 2 shows a Windows NT Server Resource Domain Controller establishing a secure channel with a Domain Controller in the Master Account Domain.

Figure 2: A secure channel for Windows NT Server

Just like the NT Workstation scenario explained above, each NT Server within a Resource Domain will use the same process of querying WINS and broadcasting locally. The difference is that instead of querying WINS for Resource Domain <1C> entries, Resource Servers query WINS for Account Domain <1C> entries.

Key Point Once the Resource Domain Server Discovers and establishes a Secure Channel with an Account Domain Server, it will pass user account logon requests from that server.

Before the User is Prompted to Logon

When an NT Workstation is started, it attempts to validate its Machine Account with the DC from the appropriate Resource Domain via the Discovery process. If the Discovery is successful, a secure channel is created between the NT Workstation and a DC in the Resource Domain.

This activity, summarized by the following steps, occurs before the user is presented with the CTRL+ALT+DEL logon screen.

H-Node clients (default for WINS users) query WINS for Resource Domain <1C> and obtains a list of DCs. M-Node clients will broadcast the query first in order to obtain the DC list.
The NT Workstation will attempt to resolve a DC name by sending a local netlogon broadcast to Resource Domain <1C> first and then sending netlogon requests serially to the list of Resource Domain DCs obtained from WINS.
The NT Workstation machine account is validated with the first DC from the Resource Domain to respond back to the logon request.
The NT Workstation then requests the Resource Domain DC to enumerate the trusted Domain list. The Domain names obtained are displayed as a list in the user's Logon dialog box.
Users enter their USERID, select an Account Domain name, and enter their password.

After the User is Prompted to Logon

The Resource Domain DC then makes a logon request on behalf of the user to the Master Account Domain DC and passes back the validation information (the name of the actual server that validated their account) to the user. It's important to understand that the Resource Domain DC uses its pre-established trusted connection path to the Account Domain DC to perform this step.

NOTE: This is a critical step because it defines where user account authentication requests are sent. For more information, see the section below titled, "Resource Domain to Account Domain Trust Communications." Also, see the "Tools" section for a discussion of the NLTEST, DOMMON, and SETPRFDC utilities.

The client gets the name of the Account Domain DC to connect to from the Resource Domain DC and is logged onto the Master Account Domain. If a logon script has been defined, it is now executed.

Resource Domain to Account Domain Trust Communications

When a Resource Domain DC boots up, it discovers and establishes a secure channel to a Master Account Domain DC for trust communications and to route user requests for account authorization.

Resource Domain Discovery Process

The Resource Domain DC uses its defined name resolution node type (M, H, etc.) to obtain the list of Master Account Domain DCs.
The DC then sends a local netlogon broadcast to the Account Domain DC <1C> name and unicast netlogon requests serially to the list of Master Account Domain DCs obtained from WINS.
The DC establishes a trusted connection with the first Master Account Domain DC to validate the netlogon request.
This process is repeated at each DC that is restarted or if the secure channel connection is lost. This process also repeats if the netlogon service has stopped and restarted.

Recommendations to Prevent User Authentication Across the WAN

NT Workstations and Resource Domain Servers both utilize WINS for Discovery and Secure Channel creation. NT Workstation queries WINS for the Resource Domain <1C> list while Resource Domain Servers queries WINS for the Account Domain <1C> list.

After this list is obtained, both clients (Workstations and Resource Domain Servers) broadcast locally and then serially attempt logons to the list of servers returned by WINS. The list is ordered by the following logic:

DC entries registered with the WINS server in order of most recently refreshed to least recently refreshed.
DC entries obtained from replication with other WINS servers.

The first entry is always the primary domain controller (PDC).

Monitoring and Managing Secure Channel Connections

System Administrators who manage a large NT environment with multiple BDCs must be aware of how the secure channels between their Resource and Master Account domains are configured. The two basic approaches that administrators can take to manage secure channels are reactive and proactive:

Reactive Approach

Once the system administrator is aware of a secure channel problem (users being authenticated by remote BDCs, logon scripts not running, logons taking longer to complete, etc.), the following procedures should be followed:

Install the NT Server Resource Kit and run the DOMMON utility to graphically view secure channels between trusted domains.
If a channel is found to connected improperly, use the DOMMON, NLTEST, or NETDOM utilities to reset the secure channel.

Quick Tool Usage Example

To check the secure channel, use NETDOM to issue the following commands from the Resource Domain:

NETDOM MASTER MASTERDOMAIN /QUERY 
NETDOM MASTER MASTERDOMAIN /RESET

Use NLTEST to find out if the secure channel is currently established and which Master Account DC is used:

NLTEST /SC_QUERY:MASTERDOMAIN

More Tool Information

More information on using NETDOM and NLTEST is available in the following Knowledge Base articles. Also refer to the "More Information" section below.

**175025—**How to Build and Reset A Trust Relationship from a Command Line
**156684—**How to Use NLTEST to Force a New Secure Channel
**158148—**Domain Secure Channel Utility: Nltest.exe
**181171—**Secure Channel Manipulation with TCP/IP

Proactive Approach

NT System Administrators can also take a proactive approach to ensure that a user's authentication occurs where it is intended. To do this, the System Administrator should actively monitor and change (if required) secure channel connections by following these steps:

Obtain the SETPRFDC utility from Microsoft Product Support Services (PSS)
Install the utility on all Resource Domain Controllers
Create a list of preferred partners for each Resource Domain Controller back to a Master Account Controller
Create an AT Command that will run on each Resource Domain Controller that issues a call to SETPRFDC using the names of the previously defined preferred partners (for example: SETPRFDC.exe MasterDomainName MasterDomainController1 MasterDomainController2 MasterDomainController3)
Configure the AT Command with the call to SETPRFDC to run at a set interval as required by the network design.

Tools

The following section describes tools available from Microsoft to view and modify how secure channels are configured.

Note: Unlike most Resource Kit Tools, Microsoft Product Support Services (PSS) does NOT support the SETPRFDC and NLTEST tools. These tools are considered "Informational Resources" and should be used only by experienced network administrators and support personnel.

DOMMON

Available in the Windows NT 4.0 Resource Kit Supplement 3, DOMMON is a graphical domain monitoring tool that displays secure channels between Windows NT computers that are members of a domain, and between domain controllers that are trusting other domains. See the "More Information" section below for a pointer.

NETDOM

Available in the Windows NT 4.0 Resource Kit Supplement 3, NETDOM is a command line utility used to reset the secure channel of the BDC. For a more detailed description of this utility, reference the NETDOM.HLP file. Review the following Knowledge Base article for more information on NETDOM. (See the "More Information" section below for a tip on querying Q#s in TechNet.)

175463—NETDOM 1.2 Fails to Join a Domain
178635—Can Not Change Domain in Windows After You Use NETDOM
186818—RPC Server Unavailable When Joining a Domain with NETDOM

NLTEST

Available in the Windows NT 4.0 Resource Kit Supplement 3, NLTEST is a command line utility used to test trust relationships and the state of domain controller replication in a Windows NT domain. Review the following Knowledge Base article for a full description of the NLTEST utility:

**156684—**How to Use NLTEST to Force a New Secure Channel
158148—Domain Secure Channel Utility -- Nltest.exe

SETPRFDC

A special utility, SetPrfDC requires Service Pack 3 or Service Pack 2 along with a newer NETLOGON.DLL that must be requested from Microsoft Product Support Services. It is a command line utility used to test the current secure channel against a list of preferred partners.

SetPrfDC is not shipped as part of any resource kit, it can only be obtained via a request to Microsoft Product Support Services.

When SetPrfDC is run, it will check the current secure channel partner. If it is the same as the one in its list of preferred partners then it does nothing. If the current secure channel partner is different than those in its list, then it will cause the resource domain controller to re-query the master domain for a list of domain controllers. If an entry from the master domain list matches the first entry from the application/utilities parameter list, then the first entry will be chosen. If the first entry is not in the list then it will check the second entry and so on until it finds a match. If a match is not found, then the domain controller from the master domain that responded first will be chosen.

Usage:

SetPrfDC should be installed and run on every Resource Domain Controller. The server must have at least SP2 installed; SP3 is recommended.

Syntax for using SETPRFDC:

Setprfdc.exe MasterDomainName MasterDomainController1 MasterDomainController2  
MasterDomainController3

Conclusion

The information presented in this paper details one of the least understood concepts of Windows NT. For System Administrators in large, geographically dispersed environments, implementing the recommendations will enable a greater understanding of secure channels, the discovery process, and the role of WINS.

More Information

For more information on this subject, please refer to these TechNet articles:

Also, the following Knowledge Base articles provide specific troubleshooting tips. To find the specific articles listed below, type "number: Q#"" in the TechNet query tool.

**158388—**Useful Resource Kit Utilities for Domain Administrators
**181171—**Secure Channel Manipulation with TCP/IP
**154398—**BDC Secure Channel May Fail if More Than 250 Computer Accounts
**175024—**Resetting Domain Member Secure Channel
**150518—**NetLogon Service Fails when Secure Channel Not Functioning
**161938—**Slow Exchange Client Logons Due to Resource Deadlock
**185625—**Windows NT Client Logon Fails with EnableSecuritySignature Set
**165202—**WinNT Client Logon in Resource and Master Domain Environment

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the information mentioned in the work are supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

Microsoft TechNet
December 1998
Volume 6, Issue 12