Name Resolution and Network Services
Table 4.1 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.
Table 4.1. Addresses and Names Used at Each Windows Server 2003 Network Layer
TCP or UDP
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.
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 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 www.iana.org.
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:
Proto Local Address Foreign Address State PID
TCP LAPTOP:http LAPTOP.company.com:0 LISTENING 1420
TCP LAPTOP:epmap LAPTOP.company.com:0 LISTENING 976
TCP LAPTOP:https LAPTOP.company.com:0 LISTENING 1420
TCP LAPTOP:microsoft-ds LAPTOP.company.com:0 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 (www.foundstone.com). 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
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:
This file contains a set of entries consisting of IP addresses and their corresponding NetBIOS computer names.
This file contains a set of entries consisting of IP addresses and their corresponding DNS host names.
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.
This is a central database containing flat NetBIOS names, service IDs, and IP addresses.
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.
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.
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 192.168.0.1
Physical Address Transport Name
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:
Windows Server 2003 IP Configuration
Host Name . . . . . . . . . . . . : PRO1
Primary DNS Suffix . . . . . . . : Company.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter Local Area Connection 2:
Connection-specific DNS Suffix . : Company.com
Description . . . . . . . . . . . : NETGEAR FA310TX Fast Ethernet Adapter (NGRPCI)
Physical Address. . . . . . . . . : 00-A0-CC-AA-AA-AA
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 10.1.200.1
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 10.1.1.254
DNS Servers . . . . . . . . . . . : 10.1.1.1