分类： WINDOWS
2009-09-28 16:51:02
SMB is an important protocol because of the large number of PCs out there that already have client and server implementations running on them. All Windows for Workgroups, Windows 95 and Windows NT systems are (or are capable of) running SMB as either a client, a server, or both.
The earliest document I have on the SMB protocol is an IBM document from 1985. It is a copy of an IBM Personal Computer Seminar Proceedings from May 1985. It contains the IBM PC Network SMB Protocol. The next document I have access to is a Microsoft/Intel document called Microsoft Networks/OpenNET-FILE SHARING PROTOCOL from 1987. The protocol was subsequently developed further by Microsoft and others. Many of the documents that define the SMB protocol(s) are available at ftp.microsoft.com in the SMB documentation area.
SMB is a client server, request-response protocol. The diagram
to the left illustrates the way in which SMB works. The only exception
to the request-response nature of SMB (that is, where the client
makes requests and the server sends back responses) is when the
client has requested opportunistic locks (oplocks) and the server
subsequently has to break an already granted oplock because another
client has requested a file open with a mode that is incompatible
with the granted oplock. In this case, the server sends an unsolicited
message to the client signalling the oplock break.
Servers make file systems and other resources (printers, mailslots, named pipes, APIs) available to clients on the network. Client computers may have their own hard disks, but they also want access to the shared file systems and printers on the servers.
Clients connect to servers using TCP/IP (actually NetBIOS over TCP/IP as specified in RFC1001 and RFC1002), NetBEUI or IPX/SPX. Once they have established a connection, clients can then send commands (SMBs) to the server that allow them to access shares, open files, read and write files, and generally do all the sort of things that you want to do with a file system. However, in the case of SMB, these things are done over the network.
As mentioned, SMB can run over multiple protocols. The following diagram shows this:
SMB can be used over TCP/IP, NetBEUI and IPX/SPX. If TCP/IP or
NetBEUI are in use, the NetBIOS API is being used.
SMB was also sent over the DECnet protocol. Digital (now Compaq) did this for their PATHWORKS product.
NetBIOS over TCP/IP seems to be referred to by many names. Microsoft refers to it as NBT in some places and NetBT in others (specifically in their Windows NT documentation and in the Windows NT registry). Others refer to it as RFCNB. NetBEUI is sometimes refered to as NBF (NetBIOS Frame Format?) by Microsoft.
NetBIOS Names
If SMB is used over TCP/IP, DECnet or NetBEUI, then NetBIOS names
must be used in a number of cases. NetBIOS names are up to 15
characers long, and are usually the name of the computer that
is running NetBIOS. Microsoft, and some other implementors, insist
that NetBIOS names be in upper case, especially when presented
to servers as the CALLED NAME.
When NetBIOS names are sent over the wire they are padded to 15 characters with spaces and a 16th character is added that specifies the type of NetBIOS name. Microsoft refers to these as NetBIOS Suffixes. A complete list can be found in the Microsoft Knowledge Base article .
There are two classes of NetBIOS names, Unique names and Global Names. However, Microsoft also defines a few other classes: Internet Group, Domain, and Multihomed.
SMB Protocol Variants
Since the inception of SMB, many protocol variants have been
developed to handle the increasing complexity of the environments
that it has been employed in.
The actual protocol variant client and server will use is negotiated using the negprot SMB which must be the first SMB sent on a connection.
The first protocol variant was the Core Protocol, known to SMB implementations as PC NETWORK PROGRAM 1.0. It could handle a fairly basic set of operations that included:
Subsequent variants were introduced as more functionality was
needed. Some of these variants and the related version of LAN
Manager are:
| SMB Protocol Variant | Protocol Name | Comments |
|---|---|---|
| PC NETWORK PROGRAM 1.0 | Core Protocol | The original version of SMB as defined in IBM's PC Network Program. Some versions were called PCLAN1.0 |
| MICROSOFT NETWORKS 1.03 | Core Plus Protocol | Included Lock&Read and Write&Unlock SMBs with different versions of raw read and raw write SMBs |
| MICROSOFT NETWORKS 3.0 | DOS LAN Manager 1.0 | The same as LANMAN1.0, but OS/2 errors must be translated to DOS errors. |
| LANMAN1.0 | LAN Manager 1.0 | The full LANMAN1.0 protocol. |
| DOS LM1.2X002 | LAN Manager 2.0 | The same as LM1.2X002, but errors must be translated to DOS errors. |
| LM1.2X002 | LAN Manager 2.0 | The full LANMAN2.0 protocol. |
| DOS LANMAN2.1 | LAN Manager 2.1 | The same as LANMAN2.1, but errors must be translated to DOS errors. |
| LANMAN2.1 | LAN Manager 2.1 | The full LANMAN2.1 protocol. |
| Windows for Workgroups 3.1a | LAN Manager 2.1? | Windows for Workgroups 1.0? |
| NT LM 0.12 | NT LAN Manager 1.0? | Contains special SMBs for NT |
| Samba | NT LAN Manager 1.0? | Samba's version of NT LM 0.12? |
| CIFS 1.0 | NT LAN Manager 1.0 | Really NT LM 0.12 plus a bit? |
Some variants introduced new SMBs, some simply changed the format of existing SMBs or responses, and some variants did both.
Security
The SMB model defines two levels of security:
Browsing the network
Having lots of servers out in the network is not much good if
users cannot find them. Of course, clients can simply be configured
to know about the servers in their environment, but this does
not help when new servers are to be introduced or old ones removed.
To solve this problem, browsing has been introduced. Each server
broadcasts information about its presence. Clients listen for
these broadcasts and build up browse lists. In a NetBEUI environment,
this is satisfactory, but in a TCP/IP environment, problems arise.
The problems exist because TCP/IP broadcasts are not usually sent
outside the subnet in which they originate (although some routers
can selectively transport broadcasts to other subnets).
Microsoft have introduced browse servers and the Windows Internet Name Service (WINS) to help overcome these problems.
CIFS: The latest incarnation?
Microsoft and a group of other vendors (Digital Equipment, Data
General, SCO, Network Appliance Corp, etc) are engaged in developing
a public version of the SMB protocol. It is expected that CIFS
1.0 will be essentially NT LM 0.12 with some modifications for
easier use over the Internet.
An Example SMB Exchange
The protocol elements (requests and responses) that clients
and servers exchange are called SMBs. They have a specific format
that is very similar for both requests and responses. Each consists
of a fixed size header portion, followed by a variable sized parameter
and data portion.
After connecting at the NetBIOS level, either via NBF, NetBT, etc, the client is ready to request services from the server. However, the client and server must first identify which protocol variant they each understand.
The client sends a negprot SMB to the server, listing the
protocol dialects that it understands. The server responds with
the index of the dialect that it wants to use, or 0xFFFF if none
of the dialects was acceptable.
Dialects more recent than the Core and CorePlus protocols supply
information in the negprot response to indicate their capabilities
(max buffer size, canonical file names, etc).
Once a protocol has been established. The client can proceed to
logon to the server, if required. They do this with a sesssetupX
SMB. The response indicates whether or not they have supplied
a valid username password pair and if so, can provide additional
information. One of the most important aspects of the response
is the UID of the logged on user. This UID must be submitted with
all subsequent SMBs on that connection to the server.
Once the client has logged on (and in older protocols-Core and
CorePlus-you cannot logon), the client can proceed to connect
to a tree.
The client sends a tcon or tconX SMB specifying the network name of the share that they wish to connect to, and if all is kosher, the server responds with a TID that the client will use in all future SMBs relating to that share.
Having connected to a tree, the client can now open a file with an open SMB, followed by reading it with read SMBs, writing it with write SMBs, and closing it with close SMBs.
The main clients are from Microsoft, and are included in Windows for WorkGroups 3.x, Windows 95, and Windows NT. They are most evident when you use the File Manager or the Windows 95 Explorer, as these allow you to connect to servers across the network. However they are also used when you open files using a UNC (universal naming convention).
Some other clients that I am aware of are:
Server implementations are available from many sources. Some that I am aware of are:
The next two sections will discuss each of the above in turn.
Workgroups
A workgroup is a collection of computers that each maintain
their own security information. With Windows for Workgroups, each
server is pretty much in share level security. Windows 95 can
pass user authentication off to an NT or LAN Manager server.
However, the point of a workgroup is that security is distributed, not centralized.
Domains
A domain is a collection of computers where security is handled
centrally. Each domain has one or more domain controllers. There
is usually a primary domain controller and several backup domain
controllers. The domain controllers maintain account style information
related to users (clients), like account names, encrypted passwords,
authorized hours of use, groups the user belongs to, etc.
Samba
Samba is a freely available SMB server for UNIX, OpenVMS (recently
ported and maybe not very stable) developed by
and maintained by a loosely knit group of people all over the
world. Samba runs on a great many UNIX variants (Linux, Solaris,
SunOS, HP-UX, ULTRIX, DEC OSF/1, Digital UNIX, Dynix (Sequent),
IRIX (SGI), SCO Open Server, DG-UX, UNIXWARE, AIX, BSDI, NetBSD,
NEXTSTEP, A/UX, etc).
Samba implements the NT LM 0.12 protocol dialect. Samba can now participate in a domain (both as a PDC and a Member of a domain), and it can participate in browsing and can be a browse master. Samba can also process logon requests for Windows 95 systems
Samba implements user level security, but shares can be public where access is mapped to the owner etc of the share.
Microsoft Windows Servers
Microsoft has a number of SMB server implementations for the
Windows range of operating systems. These are not separate products,
rather, they are integral to the appropriate version of the Windows
operating system. However, they can be switched off either though
the Control Panel or at the command line (net stop server
at DOS prompt).
It is clear from the fact that the Windows 95 and Windows NT SMB servers react differently to certain sequences of SMBs, that Microsoft do not use the same code for each of these servers (although the Windows for Workgroups and Windows 95 implementations may be derived from the same code).
Windows for Workgroups 3.11 implements the Windows for Workgroups 3.0a protocol variant, and implements share level security.
Windows 95 implements the NT LM 0.12 protocol level and implements both share and user level security.
Windows NT implements the NT LM 0.12 protocol level and implements both share and user level security.
LAN Manager and LAN Manager for UNIX (LM/X)
Microsoft and AT&T GIS ported various LAN Manager versions
to the UNIX operating system. This code formed the basis of many
SMB servers available for UNIX operating systems from many vendors.
Some examples are: LM/X for SCO, LM Server for HP-UX (Advanced Server/9000), etc.
The most recent version of this software seems to be LAN Manager for UNIX Version 2.2, which implements the LANMAN2.1 protocol variant.
VisionFS
VisionFS is a written-from-scratch SMB server from SCO. It
is available for Solaris 2.x, HP-UX and SCO (both SCO OpenServer
and UNIXware).
TotalNET Advanced Server
This product is from Syntax. It is a completely independently written SMB server,
that was perhaps the first SMB server for UNIX. These days, it comes
with additional modules
providing AppleShare and NetWare serving all in the one product.
Advanced Server for UNIX
After LM/X, NCR (which used to be ATT GIS) (perhaps with help from Microsoft)
ported the Windows NT SMB server code to UNIX to provide the same level
of functionality as Windows NT.
PATHWORKS
PATHWORKS is the name of a product family from Digital equipment
corporation. It included both servers and clients, with the servers
running on:
The clients ran on DOS, Windows, Windows for Workgroups, Windows NT and Windows 95 and are explained below.
Digital's clients and server implement SMB over DECnet as well as TCP/IP and more recently, NetBEUI. The SMB over DECnet specification has never been released.
Digital's original PATHWORKS servers were for VAX/VMS and implemented the CorePlus protocol (MICROSOFT NETWORKS 1.03 dialect). This product went through several versions and culminated in version 4.2. After a time, a version was done for ULTRIX and called PATHWORKS for ULTRIX V1, the highest version of which was 1.3. Both of these product streams were internally developed.
Subsequently, Digital used the AT&T and Microsoft LAN Manager for UNIX (LM/X) code. This was released as PATHWORKS V5.0 for OpenVMS (LAN Manager) and PATHWORKS V5.0 for Digital UNIX (LAN Manager). This product implements LAN Manager for UNIX V2.2 and the highest SMB dialect that it recognizes is LANMAN2.1 (and DOS LANMAN2.1). The reason for the LAN Manager in brackets at the end of each product name is that the products also support NetWare functionality.
PATHWORKS V5 is able to participate in a Windows NT based domain, albeit only as a Backup Domain Controller or a member server.
Recently, Digital has announced PATHWORKS V6.0 for UNIX (Advanced Server), which is based on AT&T's ASU (Advanced Server for UNIX) product.
LAN Server for OS/2
This is an IBM product that seems to be derived in some way from
Microsoft's LAN Manager code.
