لطفا منتظر باشید ...
PublisherName 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.
Layer | Protocol | Name or Address |
|---|---|---|
Application | SMB | NetBIOS name |
Transport | TCP or UDP | Port number |
Network | IP | IP address |
Data link | NDIS | MAC address |
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 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:
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:
Another great utility for seeing TCP port usage is the FPORt tool from Foundstone (www.foundstone.com). Here is a sample listing:
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 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:
|
