You'll also see people using terms like "NetBEUI", "NetBIOS", "NetBT", or "LanManager" as if they were file sharing protocols. NetBEUI is a networking protocol used on local area networks; it operates at the same level that IP does. NetBIOS is a higher-level networking protocol originally run on top of NetBEUI. NetBT is a TCP/IP implementation of NetBIOS; a program that uses NetBIOS can use either normal NetBIOS over NetBEUI or NetBT over TCP/IP, without needing to know what's going on. LanManager is an older Microsoft protocol suite, still supported by SMB file sharing and CIFS in compatibility modes. All of these protocols tend to come together; normally, if you run SMB, you also run NetBIOS (in which case you must run either NetBEUI or NetBT), and if you run NetBIOS, you also run SMB, which is why there is so much confusion about which does what. These days, the association is getting looser (in particularly, running CIFS directly over TCP/IP is supported in Windows 2000). Figure 17-3 shows the protocol stack normally involved in running CIFS over TCP/IP.
It is almost impossible to separate file sharing from the other services supported by SMB. CIFS is not actually a new protocol but simply a new name for a way of using SMB. As such, it provides all the capabilities of SMB, including a number of capabilities that are not normally thought of as part of a filesystem, including messaging, print service, and multiple methods of doing general-purpose transaction processing. This makes it much more risky than dedicated file sharing protocols.
It is worth noting that although the extra features in CIFS make it more risky than NFS, it does at least usually provide better authentication. CIFS filesystem transactions require the user to authenticate, instead of relying on the client host to provide user identification, the way most NFS servers do. CIFS can also provide message authentication to protect from hijacking. It does not provide data encryption, however.
The base of Samba is a file server; in order to effectively provide file service from a Unix machine without a Microsoft support structure, it also includes a WINS server and a browser server and is capable of acting as a domain controller to do user authentication. SMB clients are available for Linux and some Unix operating systems, and although they are not actually part of Samba, they are often distributed with Samba.
Samba itself is both more robust and more secure than most SMB file servers. Admittedly, much of its security derives from the fact that it doesn't offer all of the services you would get from an equivalent server on a Microsoft operating system (for instance, there's no need to worry about people using a Samba server to remotely access the Performance Monitor or the User Manager). Most security problems with Samba are caused by the fact that it bridges the Unix and Microsoft world and is often managed by people who are naive about one of the two. Samba provides authentication and file service and can give away all of your authentication information and files if you configure it incorrectly, just like any other program that provides these services. If you configure it poorly, you will not be protected just because it uses Microsoft protocols that are supposed to have well-behaved clients, and you should not blame unfortunate results on either Samba or Microsoft.
[76]Microsoft appears to prefer the capitalization "Dfs" instead of the more traditional "DFS".Dfs has been available for some time but is first becoming a standard part of installations in Windows 2000. Dfs is not actually a separate file sharing protocol. Instead, it uses standard file sharing protocols for actual file access (usually, this means CIFS, but a client can use any file sharing protocol it has available). Dfs clients use RPC to get information from a Dfs server about where to look for actual files.