Server Message Block

From Wikipedia, the free encyclopedia

(Redirected from Common Internet File System)
Jump to: navigation, search

In computer networking, Server Message Block (SMB) operates as an application-level network protocol mainly applied to shared access to files, printers, serial ports, and miscellaneous communications between nodes on a network. It also provides an authenticated Inter-process communication mechanism. Most usage of SMB involves computers running Microsoft Windows: in Microsoft environments users often know it simply as "Microsoft Windows Network".

When discussing SMB, one should distinguish:

Contents

Barry Feigenbaum originally invented SMB at IBM with the aim of turning DOS "Interrupt 33" (21h) local file-access into a networked file-system. Microsoft has made considerable modifications to the version used most commonly. Microsoft merged the SMB protocol with the LAN Manager product which it had started developing with 3Com circa 1990, and continued to add features to the protocol in Windows for Workgroups (circa 1992) and in later versions of Windows.

The original design of SMB envisaged it running on top of the NetBIOS and NetBEUI APIs (typically implemented with NBF, NetBIOS over IPX/SPX, or NBT), though SMB can also run directly on the TCP/IP protocols, a feature introduced with Windows 2000.

At around the time when Sun Microsystems announced WebNFS [1], Microsoft launched an initiative in 1996 to rename SMB to Common Internet File System (CIFS), and added more features, including support for symbolic links, hard links, larger file sizes, and an attempt at supporting direct connections without all the NetBIOS trimmings (a largely experimental effort that required further refinement). Microsoft submitted some partial specifications as Internet-Drafts to the IETF[1], though these submissions have expired.

Because of the importance of the SMB protocol in interacting with the widespread Microsoft Windows platform, coupled with the heavily modified nature of the SMB implementation present in that platform, the Samba project originated with the aim of reverse engineering and providing a free implementation of a compatible SMB client and server for use with non-Microsoft operating systems.

With Windows Vista (released in 2006), Microsoft introduced Server Message Block 2.0.

SMB works through a peer-to-peer approach, where a client makes specific requests and the server responds accordingly. One section of the SMB protocol specifically deals with access to filesystems, such that clients may make requests to a file server; but some other sections of the SMB protocol specialise in inter-process communication (IPC). Developers have optimized the SMB protocol for local subnet usage, but users have also put SMB to work to access different subnets across the Internet — exploits involving file-sharing or print-sharing in MS Windows environments usually focus on such usage.

SMB servers make their file systems and other resources available to clients on the network. Client computers may want access to the shared file systems and printers on the server, and in this primary functionality SMB has become best-known and most heavily used. However, the SMB file-server aspect would count for little without the NT domains suite of protocols, which provide NT-style domain-based authentication at the very least. The NT Domains protocols offer MSRPC services available almost exclusively available on SMB IPC "named pipe", and almost all implementations of SMB servers use NT Domain authentication to validate user-access to resources.

Many people believe that the SMB protocol makes heavy use of network bandwidth because each client broadcasts its presence to the whole subnet. SMB itself does not use broadcasts. The broadcast problems commonly associated with SMB actually originate with the NetBIOS service location protocol. By default, a Microsoft Windows server will use NetBIOS to advertise and locate services. NetBIOS functions by broadcasting services available on a particular host at regular intervals. While this usually makes for an acceptable default in a network with fewer than 20 hosts, broadcast traffic will cause problems as the number of hosts increases. A proper implementation of a NetBIOS Name Server (NBNS) can mitigate this problem — for example Windows Internet Naming Service (WINS) offers a suitable solution in Microsoft environments. WINS uses a much more advanced system of registration and centralized service requests, but imposes its own complexity upon the design and maintenance of the network. Microsoft recommends the use of Dynamic DNS, another viable option, in Microsoft Active Directory environments.

Network designers should expect that latency will have a significant impact on the performance of the SMB protocol. Monitoring reveals this most commonly in cases of navigating among directories through SMB when significant network latency exists between hosts. For example, a VPN connection over the Internet will often introduce network latency, which can make for a frustrating experience.

Microsoft has added several extensions to its own SMB implementation. For example, it added NTLM Version 2 because NTLM version 1 (derived from the original legacy SMB specification's requirement to use IBM "LanManager" passwords) uses DES in a flawed manner. Additionally, the NT 4.0 Domain Logon protocols use 40-bit encryption outside of the United States of America, which does not conform with modern security standards.

SMB's "Inter-Process Communication" mechanism deserves a specific mention. The SMB "IPC" system provides named pipes. SMB's IPC mechanism provides one of the first few inter-process mechanisms commonly available to programmers that provides a means for services to inherit the authentication carried out when a client first connected to an SMB server. The inherited authentication in named pipes has become so ubiquitous and transparent that both Windows-users and programmers who use the Windows API often simply take it for granted.[citation needed]

Some services that operate over named pipes, such as those which use Microsoft's own implementation of DCE/RPC over SMB, known as MSRPC over SMB, also allow MSRPC client programs to perform authentication, which over-rides the authorization provided by the SMB server, but only in the context of the MSRPC client program that successfully makes the additional authentication.

Packet-signing has a significant deleterious effect on SMB over TCP, because it enforces serialization. However, because Windows Servers use SMB to transmit system policies at login, they normally have packet-signing enabled (used to prevent Man-in-the-middle attacks). SMB2 is designed to partly overcome this performance limitation by coalescing SMB signals into single packets.

As another point of interest, SMB supports opportunistic locking — a special type of locking-mechanism — on files in order to improve performance.

SMB serves as the basis for Microsoft's Distributed File System implementation.

The list below explicitly refers to "SMB" as including an SMB client or an SMB server, plus the various protocols that extend SMB, such as the Network Neighborhood suite of protocols and the NT Domains suite. For simplicity and conciseness and vagueness, however, the list omits mention of the extent or completeness of the reimplementation or porting status for any of these implementations, "lumping" them all together simply as "SMB".

Advanced Search
Included Web Search Engines


Safe Search

close

Top Matching Results

Occasionally Search.com will highlight specialized results that are based on the context of your query. Examples of specialized results include specific links to news, images, or video.

Top Matching Results may highlight information from other Search.com pages, content from the CNET Network of sites, or third party content. The listings are based purely on relevance. Search.com does not receive payment for listings in this section but our partners that provide this data may get paid for listing these products.

Sponsored Links

This section contains paid listings which have been purchased by companies that want to have their sites appear for specific search terms and related content. These listings are administered, sorted and maintained by a third party and are not endorsed by Search.com.

Search Results

Search.com sends your search query to several search engines at one time and integrates the results into one list which has been sorted by relevance using Search.com's proprietary algorithm. You can customize the list of search engines included in your metasearch from the preferences.

The search engines that are used in your metasearch may allow companies to pay to have their Web sites included within the results. To view the Paid Inclusion policy for a specific search engine, please visit their Web site. Search.com does not accept payment or share revenue with any search engine partner for listings in this section.