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.
Layer |
Protocol |
Name or Address |
---|---|---|
Application |
SMB |
NetBIOS name |
Transport |
TCP or UDP |
Port number |
Network |
IP |
IP address |
Data link |
NDIS |
MAC address |
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 and System IntegrationSMB 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 wellDisabling 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: C:\>netstat -ao Active Connections 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: D:\>fport FPort v2.0 - TCP/IP Process to Port Mapper Copyright 2000 by Foundstone, Inc. http://www.foundstone.com 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 LayerThe 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:
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 LayerBy 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. 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 =================== ================================================== 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 . . . . . . . : 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 |