Secure Channel Manipulation with TCP/IP

 Last reviewed: March 10, 1998
Article ID: Q181171
The information in this article applies to:
  • Microsoft Windows NT Workstation versions 3.51 and 4.0
  • Microsoft Windows NT Server versions 3.51 and 4.0

IMPORTANT: This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information on how to do this, view the "Restoring the Registry" online Help topic in Regedit.exe or the "Restoring a Registry Key" online Help topic in Regedt32.exe.

SUMMARY

There are several processes on a Windows NT network that require workstations and servers to establish a secure channel with a domain controller. One of these processes is user validation. A common misconception is that this secure channel will be formed with the nearest domain controller. In reality, a computer running Windows NT Workstation or Server will establish a secure channel with the first domain controller to respond to a logon request. Because many factors contribute to the speed of the response -- including network speed, work load, name resolution methods, and WINS registration order -- it is quite possible for a secure channel to be established with a domain controller several network hops away. This is rarely desirable, and, therefore, it becomes necessary to attempt to control the formation of secure channels.

This article will document five methods to control which domain controller a secure channel is setup to.

RESOLUTION

Method 1: M-Node Name Resolution

Windows NT will always broadcast first to set up a secure channel; however, we will not always wait the full time out period for a response. By explicitly setting the Node type to Broadcast first (m-node), we will wait longer and give the local domain controller more time to response to our Secure Channel request. This method will only work if there is a domain controller on our local subnet. If there is not, we will still query WINS (if specified) for a list of domain controllers.

H-node is the default node type of a Windows NT client if a WINS address is specified. Without a WINS address specified, modified b-node is the default. H-node uses the WINS server first and then will broadcast for name resolution. M-node will broadcast first on the local subnet.

WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall Windows. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

For information about how to edit the registry, view the "Changing Keys And Values" online Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" online Help topics in Regedt32.exe. Note that you should back up the registry before you edit it.

  1. Run Regedt32 and navigate to the following key: 

          HKEY_LOCAL_MACHINE\Registry\Machine\System\CurrentControlSet\Services
      \NetBT\Parameters\NodeType

    NOTE: The above registry key is one path; it has been wrapped for readability.

  2. Change it to 0x00000004 for mixed node or m-node.

    The possible values are: 

          0x00000008 for hybrid node or h-node
      0x00000004 for mixed node or m-node
      0x00000002 for point-to-point WINS or p-node
      0x00000001 for broadcast node or b-node

-or-

If the clients in question are using DHCP, use DHCP to change the node type of DHCP clients. However, this will change the node type on all computers serviced by that scope.

After you change the node type, restart the computer for the changes to take effect.

Method 2: LMHOSTS File

When a computer running Windows NT sets up a secure channel, it will use the NetBIOS 1C entry for the domain that it needs to contact. For a computer running Windows NT Server or Workstation, this will be its own domain. For a domain controller, it will need to contact all trusted domains. To add a 1C for a preferred domain controller, verify that the TCP/IP Enable LMHOSTS Lookup property is selected. Edit or create the LMHOSTS file in the %SystemRoot%\system32\drivers\etc directory. Add an entry for the domain with which you want to control the secure channel. The entry should look like: 

   IP_ADDRESS_OF_DC  "DOMAIN         \0x1C" #PRE
The domain name must be padded with enough characters to make it 15 characters, there should be exactly 20 characters inside the quotes. To avoid problems that may arise from non-ASCII characters and hidden extensions, the use of Notepad.exe is discouraged. Edit.com is a true ASCII editor, and its use is strongly recommended. The LMHOSTS file needs to have several blank lines at the bottom.

When you are done, use NBTSTAT -R (must be capitalized) and then NBTSTAT -c to verify that the entry is now in the NetBIOS cache.

When used by itself, we will have to restart the computer to establish a new secure channel; however, an LMHOSTS file can be with the following methods to point the secure channel to a desired server.

Method 3: NLTEST

NLTEST (included with the Windows NT Server 4.0 Resource Kit) will allow us to determine who our secure channel is set up with and also to force it to reestablish the secure channel. To determine who your secure channel is set up with, type the following at a command prompt: 

   NLTEST /SC_QUERY:<DOMAIN_NAME_TO_CHECK>
To reestablish a secure channel, use the parameter: 

   NLTEST /SC_RESET:<DOMAIN_NAME_TO_RESET>
The first thing NLTEST does to reestablish a secure channel is query the network for the 1C list for the domain. By using NLTEST and an LMHOSTS file to preload a 1C entry for our preferred domain controller, we can control who we will resolve the 1C entry to. NLTEST can also be used if the network has been altered and the distant or slow domain controller would not be chosen again.

You do not need to restart your computer when you use NLTEST.

Method 4: SETPRFDC

SETPRFDC is currently only available from Microsoft Technical Support, but should be included in a future service pack. SETPRFDC uses additions to the Netlogon.dll file to tell it who it should attempt to set up its secure channel with.

Usage: 

   SETPRFDC <TrustedDomain> <ListOfDcsInTrustedDomain>
SETPRFDC allows you to supply a list of domain controllers in the order you would like them tried.

You do not need to restart your computer when you use SETPRFDC.

Method 5: NETDOM

NETDOM (included with the Windows NT Server 4.0 Resource Kit) allows us to control many domain or account functions from the command line. Only the ones concerning secure channels will be discussed here.

Type the following to reset a workstation or member server: 

   NETDOM /Domain:mydomain MEMBER mycomputer /JOINDOMAIN
Type the following to reset a backup domain controller: 

   NETDOM BDC mybdc /RESET
Type the following to reset a trust relationship: 

   NETDOM /Domain:MyResourceDomain /User:MyResourceDomain\AUser
   /Password:apassword MASTER MyMasterDomain MyPassword /TRUST
NETDOM will also query for the 1C list when reestablishing the new secure channel. If we preload our preferred domain controller in an LMHOSTS file, we can control the location of the secure channel.

For more information on NETDOM, please see the Netdom.hlp file in the Resource Kit.

MORE INFORMATION

For additional information, please see the following articles in the Microsoft Knowledge Base:

TCP/IP Node Types: 

   ARTICLE-ID: Q167640
   TITLE     : Automatically Changing the Node Type of a WinNT Wkst
LMHOSTS Files: 

   ARTICLE-ID: Q101927
   TITLE     : The LHMOSTS File for TCP/IP in Windows NT

   ARTICLE-ID: Q105997
   TITLE     : Differences Between the HOSTS and LMHOSTS Files in Windows
               NT

   ARTICLE-ID: Q129218
   TITLE     : How to Statically Initialize WINS with 0x1B for the PDC
NLTEST: 

   ARTICLE-ID: Q156684
   TITLE     : How to Use NLTEST to Force a New Secure Channel

   ARTICLE-ID: Q165202
   TITLE     : WinNT Client Logon in Resource and Master Domain Environment
NETDOM: 

   ARTICLE-ID: Q175024
   TITLE     : Resetting Domain Member Secure Channel

   ARTICLE-ID: Q150518
   TITLE     : NetLogon Service Fails when Secure Channel Not Functioning

   ARTICLE-ID: Q175025
   TITLE     : How to Build and Reset a Trust Relationship from a Command
               Line

Keywords          : ntdomain NTSrvWkst
Version           : WinNT:3.51,4.0
Platform          : winnt
Issue type        : kbinfo

================================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: March 10, 1998
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.