Name Resolution and Network Services

Name Resolution and Network Services

Figure lists the addresses, ports, and names used at each layer of the OSI model as it is implemented in Windows Server 2003. Processes running at each layer communicate with their peer processes at other stations using these addresses, ports, and names.

Let's now work our way down the OSI stack to see how each layer resolves the NetBIOS name into an address that can be used to communicate with its peer layer on another machine.

Addresses and Names Used at Each Windows Server 2003 Network Layer



Name or Address



NetBIOS name



Port number



IP address

Data link


MAC address

Multihomed NetBIOS Registrations and Single Adapters

The Multihomed NetBIOS name type is not assigned to name/service combinations originating from a computer with multiple IP addresses bound to the same adapter. Only the first IP address bound to the adapter is registered with WINS, but an SMB connection can be made to any IP address in the binding list. This contrasts to NT, where an SMB connection could only be made to the top address in the binding list.

Application Layer and Server Message Block (SMB)

Windows client redirectors and servers use the SMB protocol to communicate with each other. There are a variety of SMB dialects representing different maturity states of the protocol. One of the first actions in an SMB transaction is a negotiation between the parties to agree on a common dialect. Windows Server 2003 uses the NT LM 0.12 dialect.

A few years ago, Microsoft rechristened SMB as the Common Internet File System (CIFS). The new name is purely market positioning. The CIFS/SMB dialect used by Windows Server 2003 is the same dialect used by all versions of NT since 3.51.

In the absence of a locator mechanism such as WINS or DNS, SMB applications can use broadcasts to find each other. This works something like a CB radio. When the Workstation service on one station wants to communicate with the Server service on another station, for example, the Workstation service puts out a broadcast that essentially says, "Breaker on that Ethernet. This here's the Workstation service on PRO1 looking for that Server service on SVR13. Come on back, SRV13 Server service." When the Server service on SVR13 gets this message, it returns a response such as, "You got that SRV13 Server service, good buddy. Come on back." The two services agree on a dialect, assign a unique ID to the session, and begin communications.

When a Windows computer that is a member of a domain establishes SMB communication with a domain controller, it also establishes a secure Remote Procedure Call (RPC) session. This RPC session uses SMB but is capable of encrypting the traffic used to carry sensitive information between a client and a server. This includes authentication information.

The computer password is stored in the local Security Account Manager (SAM) of the client and in Active Directory. If a domain member cannot resolve the domain controller name into an IP address, it cannot build a secure RPC channel and users cannot get authenticated in the domain.

Transport Layer

SMB is a session-oriented protocol. Peer SMB applications running on two stations must establish a link with each other prior to exchanging SMB messages. For this reason, SMB traffic is always carried in TCP datagrams.

SMB and System Integration

SMB is the lingua franca for a variety of network operating systems, not just Windows Server 2003. It is used by all versions of Windows, from Windows for Workgroups through Windows 9x and classic NT. OS/2 Warp uses SMB because Warp and NT share a common ancestor in OS/2 LAN Manager. SMB is also used by Samba, a UNIX port of SMB. There are Samba implementations for NetWare and VMS, as well.

Different SMB applications can talk to each other, although you might not get full functionality. It's like a conversation between a Portuguese merchant and an Italian tourist. The general ideas might get across just fine, but there may be problems with the details of the transaction. SMB applications on non-Windows platforms most commonly have problems with authentication.

The well-known port for SMB traffic is TCP port 139. This port is used by the NetBIOS-over-TCP helper, Netbt.sys, which essentially "tunnels" SMB into TCP. Windows Server 2003 and Windows 2000 computers can use TCP directly to carry SMB commands. This "direct hosting" of SMB occurs over TCP port 445. Windows computers capable of direct SMB communication will always use TCP port 445 to exchange traffic with each other while falling back on classic TCP port 139 to exchange traffic with downlevel clients. See "Disabling NetBIOS-over-TCP/IP Name Resolution" at the end of this chapter for more information about the benefits of using direct hosting of SMB exclusively.

Windows computers can also exchange sessionless traffic. Examples include name resolution/registration transactions and NetBIOS broadcasts. Because these messages do not require sessions and are generally quite small, they use UDP. Windows uses UDP port 137 for NetBIOS name resolution/registration and UDP port 138 for NetBIOS broadcasts and unidirectional traffic. For example, when you use the net send command to pop up a message on a user's console, the message goes out over UDP port 138.

A TCP-based service places a "listen" on a TCP port then waits for connections to that port. You can get a list of the active TCP ports on a server using the NETSTAT utility with the syntax netstat -a. If a port is listed in the Services file located at C:\Windows\System32\drivers\etc, the registered port name is used in place of the port number. You can get a full list of ports from

A new feature in the NETSTAT utility in Windows Server 2003 is the ability to list the process that owns each port. This helps identify rogue processes and acts as a troubleshooting aid. Here is a sample listing:

C:\>netstat -ao

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    LAPTOP:http     LISTENING       1420
  TCP    LAPTOP:epmap    LISTENING       976
  TCP    LAPTOP:https    LISTENING       1420
  TCP    LAPTOP:microsoft-ds   LISTENING       4

You can get a mapping of PIDs (process IDs) to service names using Task Manager or the new TASKLIST utility in Windows Server 2003. Here is a sample listing using the /svc switch to show the individual services under each process executable:

svchost.exe                  976 RpcSs
svchost.exe                 1000 AudioSrv, Browser, CryptSvc, Dhcp, dmserver,
                                 ERSvc, EventSystem, helpsvc, lanmanserver,
                                 lanmanworkstation, Messenger, Netman, Nla,
                                 RasMan, Schedule, seclogon, SENS,
                                 ShellHWDetection, srservice, TapiSrv,
                                 TermService, Themes, TrkWks, uploadmgr,
                                 W32Time, winmgmt, WmdmPmSp, wuauserv, WZCSVC
svchost.exe                 1164 Dnscache
svchost.exe                 1188 LmHosts, RemoteRegistry, SSDPSRV, WebClient
spoolsv.exe                 1280 Spooler
inetinfo.exe                1420 IISADMIN, W3SVC

Another great utility for seeing TCP port usage is the FPORt tool from Foundstone ( Here is a sample listing:

FPort v2.0 - TCP/IP Process to Port Mapper
Copyright 2000 by Foundstone, Inc.

Pid   Process            Port  Proto Path
1420  inetinfo       ->  80    TCP   C:\WINDOWS\System32\inetsrv\inetinfo.exe
976   svchost        ->  135   TCP   C:\WINDOWS\system32\svchost.exe
4     System         ->  139   TCP
1420  inetinfo       ->  443   TCP   C:\WINDOWS\System32\inetsrv\inetinfo.exe
4     System         ->  445   TCP
1000  svchost        ->  1025  TCP   C:\WINDOWS\System32\svchost.exe
1420  inetinfo       ->  1027  TCP   C:\WINDOWS\System32\inetsrv\inetinfo.exe

Network Layer

The IP protocol takes UDP and TCP datagrams and packages them for delivery to the NDIS driver waiting at the MAC layer. IP can also carry so-called raw IP traffic from applications that bypass TCP and UDP.

The Tcpip.sys driver is responsible for determining the IP address of the destination based on the NetBIOS name in the SMB message. Tcpip.sys can either use its own internal DNS resolver or it can rely on the NetBIOS-over-TCP/IP helper, Netbt.sys, to resolve the address using NetBIOS name resolution. In brief, Tcpip.sys has the following tools at its disposal:

  • Lmhosts. This file contains a set of entries consisting of IP addresses and their corresponding NetBIOS computer names.

  • Hosts. This file contains a set of entries consisting of IP addresses and their corresponding DNS host names.

  • Broadcasts. This method uses UDP datagrams sent as IP multicasts that request a response from the station having the destination name in the datagram. A response to this datagram contains the station's IP address.

  • WINS. This is a central database containing flat NetBIOS names, service IDs, and IP addresses.

    Restricting SMB Traffic Through Firewalls

    If you want to restrict SMB communications from outside the local network, configure your firewall or TCP/IP filter to block traffic over TCP port 139 and UDP ports 138 and 137. If you want to block SMB traffic from Windows Server 2003, XP, and Windows 2000, also block TCP port 445.

  • NetBIOS name cache. When a NetBIOS name is resolved, it is cached to speed up subsequent lookups.

  • DNS. This is a central database containing hierarchical host names and IP addresses.

  • DNS resolver cache. When a DNS name is resolved, it is cached to speed up subsequent lookups.

A simple way to remember the order in which TCP/IP uses these tools is the phrase "Can We Buy Large Hard Drives?" The first letters are keys for cache, WINS, Broadcast, Lmhosts, Hosts, and DNS.

Media Access Control Layer

By the time the original SMB message arrives at the network adapter, it has been sliced and diced and nearly fully digested. Just one thing is lacking. The NDIS drivers at the MAC layer don't know diddly about NetBIOS names, TCP/UDP ports, or IP addresses. Down here in the basement of the OSI stack, only one thing counts, and that is the MAC address associated with the physical device. Tcpip.sys must provide a MAC address to the NDIS driver so NDIS can build a transmission frame. For this purpose, Tcpip.sys uses the Address Resolution Protocol, or ARP.

ARP works by broadcasting the destination stations' IP address then waiting for a response. All network interfaces on the subnet hear the broadcast, but only the station with the matching IP address responds. The response contains the station's MAC address.

Tcpip.sys plucks the MAC address out of the ARP response and gives it to NDIS. The NDIS drivers use the MAC address to build the header of the transmission frame. Tcpip.sys caches the IP address/MAC address pair so it doesn't need to do another ARP broadcast for a while. A cache entry times out after 10 minutes if it is used and after 2 minutes if it is not used.

ARP broadcasts succeed even in routed environments. IP routers are programmed to act on ARP requests for IP addresses in their network range. The router responds by returning the MAC address of the router interface associated with the network number in the IP address. This fools the originating station into thinking that it is talking to the destination station. The router then repackages the packet and sends it either to the destination network (if it is in the routing table) or to its own gateway for further processing.

Internet Control Management Protocol (ICMP)

Another Network layer protocol implemented by Tcpip.sys is the Internet Control Management Protocol (ICMP).

The most familiar use of ICMP is in diagnostic programs such as Ping and Tracert. When you ping a host, for example, the result is a series of ICMP Echo Request and ICMP Echo Reply transactions.

ICMP is also used to communicate network connection problems between physical layer entities. For example, if an IP packet exceeds the Maximum Transmission Unit (MTU) value for a router interface, the router discards the packet and sends back an ICMP message with the correct MTU.

You can view the MAC address returned from a host as part of an arp transaction in a couple of ways. One way is to first ping the host then display the contents of the arp cache using the arp utility with this syntax: arp -c. A better way is to use the new GETMAC utility in Windows Server 2003. Here is an example listing:

D:\>getmac /s

Physical Address    Transport Name
=================== ==================================================
00-02-3A-2A-3C-DC  \Device\Tcpip_{CDB02354-574F-4FEE-8CFF-AFBCE6CC1511}

You can see the MAC address associated with the network adapters in your machine by opening a command prompt and entering ipconfig /all. This also shows the IP information associated with the interfaces. Here is an example:

C:\>Ipconfig /all

Windows Server 2003 IP Configuration

        Host Name . . . . . . . . . . . . : PRO1
        Primary DNS Suffix  . . . . . . . :
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection 2:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : NETGEAR FA310TX Fast Ethernet Adapter (NGRPCI)
        Physical Address. . . . . . . . . : 00-A0-CC-AA-AA-AA
        DHCP Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . :
        Subnet Mask . . . . . . . . . . . :
        Default Gateway . . . . . . . . . :
         DNS Servers . . . . . . . . . . .   :

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows