Integrating CIFS and NFS File Sharing
Bridget Allison File sharing has consistently been one of the key motivating factors driving the proliferation of Local Area Networks (LANs). Two competing file sharing technologies were developed for use within the UNIX realm, Remote File Sharing (RFS) from AT&T and the Network File System (NFS) from Sun Microsystems, Inc. Novell's NetWare network operating system (NOS) provided similar basic functionality to PC users, while proprietary mini-computer and mainframe operating systems used differing techniques to accomplish the same goal. Interoperability between the various file sharing facilities has been lacking, however, each facility requiring its own environment and its own set of supporting software elements. For most organizations, however, the key issue is integrating the file sharing facilities provided by UNIX and Microsoft operating systems. This article identifies several key issues that arise when answering the question: How can a network administrator best provide file services to users who may access their data from UNIX or Microsoft Windows-based machines? There are several possible answers to this question and each has its good and bad points. Since UNIX and Windows clients use a different protocol for remote file sharing, UNIX uses NFS, and Microsoft Windows now uses Common Internet File System (CIFS). Combining NFS and CIFS raises challenges in file and data security, user authentication, and more. One of the first things to decide is whether you want to keep the two platforms separate and use UNIX servers for serving UNIX data and Windows servers for Windows data. Alternatively, you may decide to focus on one protocol and install client versions of that protocol on each machine that does not speak it natively. You might choose to install NFS on all your Windows clients or to install a CIFS client on your UNIX clients. A third alternative that is becoming increasingly popular is to leave your client machines alone and make sure that your server can talk both NFS and CIFS. This article focuses on the third alternative and examines which issues become important when you choose to use a server that will speak to each type of client with the client's native protocol. CIFS - What Is It? In 1987, Microsoft and Intel published a document called "Microsoft Networks/OpenNet-File Sharing Protocol," which introduced the SMB (Server Message Block) remote file access protocol. This protocol has been used since in various PC networked environments: Microsoft's LAN Manager, Windows for WorkGroups and more recently OS/2, Windows NT and Windows 95. In 1992, SMB was ratified as an X/Open specification (X/Open CAE Specification C209). As the protocol developed, the name was changed in 1996 to CIFS as part of the effort by Microsoft to promote the protocol as an Internet standard. Work on extending and documenting the specification continues, with one aim being the production of an Informational RFC. The CIFS 1.0 specification has also been submitted to the Internet Engineering Task Force as an Internet Draft document. Full details on the CIFS specification are available at:
http://www.microsoft.com/intdev/cifs/
Specification Details The CIFS protocol specification and auxiliary documents define the way in which clients and servers interoperate in the following areas:
The latest version of the CIFS documentation also covers the following enhancements:
By conforming to the CIFS protocol specification, a server can provide network-related services to all clients that also conform to the protocol. It is possible to provide CIFS server services without providing full compliance with every element of the current CIFS specification, so administrators looking for a CIFS server must choose their list of core requirements and shop appropriately. For many administrators the balance must be struck between feature-rich CIFS functionality and truly solid interoperability between CIFS and NFS. The CIFS protocol specification itself does not address interoperability with other protocols, and vendors have widely differing ways of integrating CIFS and NFS. CIFS Integration with NFS The State Concept One major difference between NFS and CIFS is the client's concept of state. NFS pretends state does not exist, but CIFS is dependent on it. NFS clients are oblivious to server reboots - a hard mount will keep trying to establish connectivity until it is successful. NFS emphasizes error recovery over file locking (an application will recover much more easily after a break-in service if there is no state preservation to check). CIFS clients are very sensitive to state. This means that applications accessing data via CIFS rely on a sustained connection to maintain file locking, which is the main data safeguard in the CIFS world. CIFS clients emphasize locking over error recovery. Under these circumstances a lost network connection appears to the PC application just as a failed local drive would and the application may not recover gracefully. Therefore PC clients need to be warned before server shutdowns and reboots whenever possible. Both Windows 95 and NT clients can re-establish a persistent drive mapping once the server reappears on the network but the CIFS client's sensitivity to state makes it vulnerable to data loss in an unstable network environment. Administrators need to be aware that server reboots will be much more visible if that server is servicing CIFS clients as well as NFS clients. This, of course, makes server reliability a critical factor. Authentication The authentication models used by NFS and CIFS are very different, and integrating these two disparate systems remains one of the primary challenges in a multiprotocol environment. Users frequently want to log in once and have access to all resources they are entitled to without entering multiple usernames and passwords. Unlike NFS, which exports data to a client system and relies on that client system to authenticate (potentially) multiple users, CIFS shares data with single-user systems. Authentication of those users is performed by the CIFS server. CIFS user authentication can be done in Microsoft's workgroup or domain models. In a workgroup environment, each CIFS server is responsible for authenticating users locally. This means that the CIFS server has to maintain an account database of some kind, and each user needs to have an entry in the local database. Some CIFS servers also provide some type of guest access if a user requesting access does not appear in the server's local list of accounts. The CIFS protocol does not specify the format of the account database, and so there are a variety of solutions. Some CIFS servers provide a passwd-type file for CIFS access, Microsoft's CIFS servers store the account information in the server registry. Some CIFS servers can also use NIS rather than a local passwd file. For example, Network Appliance Corporation's filers (file server appliances) and Samba (a freeware CIFS server for UNIX) are both capable of this. In a Microsoft domain environment, account information for the domain is handled by a designated machine, which is the master for the domain. Windows NT Domain Controllers perform this function for Microsoft Windows NT domains. Although the CIFS specification does not cover the mechanics of Windows NT Domain Controller, it does describe how to interact with the Domain Controller for pass-through authentication. By using pass-through authentication, a CIFS server can forward a user access request to a Windows NT Domain Controller for validation. In this scenario all the CIFS server knows is that the Windows NT Domain Controller either confirms or denies the user's identity, and the CIFS server grants or denies access to the user on the basis of the Domain Controller's answer. The problem with pass-through authentication is that it lends itself to man-in-the-middle attacks. This happens when another server inserts itself into the conversation and grabs the user's encrypted password information, which can then be used in a dictionary attack scenario. Security of CIFS passwords is a topic that is currently being debated in several newsgroups and mailing lists. Those interested in reading more on this issue should take a look at Alan Ramsbottom's "FAQ: NT Cryptographic Password Attacks & Defences" at:
http://ntbugtraq.rc.on.ca/samfaq.htm.
The topic of authentication raises more issues than this article can address, but one of the first questions an administrator must answer is: Should one server platform control all user authentication ( and if so, which one?) or should key servers from each platform be configured to authenticate clients of their own type? The answer to this question depends on what functionality is needed on the server-side. The CIFS protocol specification does not describe how to retrieve NT domain-specific information (e.g., user security ID, NT domain group membership, and login restrictions). Thus, if these details are important then your CIFS server functionality needs to go beyond the public specification. Username and group name integration issues are also raised here. Do you need a CIFS server that can understand and translate between UNIX user IDs and NT security IDs? And what about group membership and quota management dependencies? Microsoft Windows NT 5.0 will use Kerberos 5 for authentication, which offers some hope that a unified authentication space may one day be the norm. Kerberos has been available for UNIX platforms for several years, and NT-based Kerberos servers are also available today. Of course, a critical component of this will be Microsoft's adopting the existing Kerberos standards without making modifications that prevent interoperability with other platforms. Information on just how Microsoft will do this is not currently generally available. File and Directory Permissions Having successfully authenticated a user, their access to individual directories and files must also be regulated based on their identification as passed back by the authentication process. Here again, CIFS and NFS have different methods for evaluating file and directory access. In an NFS environment, file and directory access is granted or denied based on the UID provided with each NFS request. Each file and directory has an access mode that is stored by the file system as mode bits that map to rwx for user, group, and other where user implies file owner. (There are of course other file mode settings, but they are not relevant for the purposes of this discussion.) In addition to per-file access permissions NFS servers can export file systems as "read-only," and NFS clients can mount file systems as "read-only" independent from the server export criteria. The CIFS specification itself does not define just how file and directory permissions should be implemented beyond a description of share level and user level access. However, because the overwhelming number of CIFS clients and servers are Microsoft implementations, most CIFS server providers see the Windows NT file and directory Access Control Lists (ACLs) as the actual standard permission sets for the CIFS filespace. File and directory ACLs are stored in two lists: a deny ACL and an allow ACL, both of which contain a list of user and group security IDs (SIDs). The combination of the two lists defines what access a client has to the file or directory. There are three problems here. First, the public CIFS specification does not document how to retrieve user and group SIDs - that is part of the NT domain-specific information which is not available without a non-disclosure agreement with Microsoft1. Second, the file system needs to store this extra information about each file and directory, and the file system may not be designed to store extra attributes. Third, if NFS and CIFS users are to share a common filespace then there must be some translation of UNIX permissions to ACLs and vice versa. CIFS server providers must have good solutions to all three of these problems if NFS users and CIFS users are to set native permissions on the same filespace. File and Byte Range Locking Allowing NFS and CIFS users to access the same file system raises the question of just how the shared file access should be managed. This is a critical area since NFS and CIFS treat file and byte range locking somewhat differently. For example, what happens when a CIFS user has a file open for writing and an NFS user also decides to open that file for writing? The answer depends on which locking ruleset the server is enforcing. NFS locking is advisory rather than mandatory, and applications running under UNIX may access a file without checking for the existence of another client's lock or requesting a lock itself. The UNIX and NFS designs assume that applications requiring more stringent locking mechanisms will impose those mechanisms themselves. In contrast to NFS, CIFS locking is mandatory, and CIFS clients rely on strict file locking for data integrity. If a CIFS client receives confirmation from the server that it has been granted a lock, the client relies on the server to enforce the lock and defend against other-client access to the file. If the lock is violated, data may be corrupted. CIFS server implementations address this problem in one of two ways largely depending on the type of implementation. Servers that emulate CIFS on top of UNIX may convert the CIFS lock request into a UNIX advisory (fcntl) lock, which is what lockd expects for remote locks. This does not give the full protection that the CIFS client is expecting but does provide an integration into the native UNIX environment. Samba, for example, implements cross-protocol locking in this way. Servers that provide native implementations of both protocols and also have complete control over the file system are able to provide locking behavior consistent to each protocol (i.e., CIFS locks are always enforced as the client expects, and NFS locks are always advisory except where both protocols access a shared file). In the shared file scenario, the stricter CIFS locking takes precedence, thus ensuring data integrity. Some network filers provide this type of locking integration. Password Synchronization UNIX passwords are encrypted using a one-way hash function that uses a random element, known as 'salt,' to ensure that identical passwords hash to different values. CIFS client passwords are also encrypted using one of two one-way hash functions with different SMB dialects. The hashing algorithm used depends on which SMB dialect the client and server negotiated when the client requested the connection. Neither of the CIFS functions uses 'salt,' however. Microsoft recently issued a hotfix that may be applied to prevent client/server negotiation of the less secure of the two algorithms after complaints about vulnerability (see http://www.microsoft.com/kb/articles/q147/7/06.htm for details and a pointer to the patch). Unfortunately, the password encryption used by each platform is platform-specific and not transferable. (CIFS uses different hashing algorithms than the one used by UNIX and since they are all one-way, the original clear-text password cannot be retrieved by one system from the other.) Therefore users must maintain two accounts for authentication purposes: one in the UNIX space and one in the CIFS space. This raises other questions for the system administrator: If the same users will be accessing the server from NFS and CIFS platforms, and you choose to use specific servers from each platform to authenticate clients of their own type, then how will the two account databases be synchronized? Is synchronization necessary? If your users will not tolerate two accounts with two passwords, then an integrated NFS and CIFS solution must include a means of synchronizing passwords between the two platforms. There have been several proposals on how to do this, but to date there is no ideal solution. Filenames UNIX is case sensitive, CIFS is case insensitive, and PC-generated files may have two names: a long filename and also a DOS-style 8.3 name. Allowing NFS and CIFS users to share a common filespace introduces questions on just how the file namespace will be protected. To an NFS user, the files Foo and foo are completely different. To a CIFS client, they are the same file. When the "helpful" behavior of Windows 95 and NT clients (displaying filenames with initial capitals in Explorer and File Manager and causing any update to the file to be written back with the newly capitalized filename) is introduced, the possibility for data corruption and mismanagement only increases. The heart of this problem lies with the file system itself. UFS, for example, was never designed to store PC file information. Extending the file system to accommodate extra attributes is beyond most CIFS server vendors, and this dilemma has produced a variety of responses. One approach used by Syntax in their TotalNet product is to provide shadow files which store the extra information for CIFS clients files, because the UNIX file system cannot store this extra information. Users must then remember to delete the shadow file when they delete the real file, or alternatively use the vendor-specific commands which will take care of both the real file and its shadow. Another server solution used by Samba, for example, is to provide dynamic mapping of both 8.3 and case-insensitive versions of the files with a cache to help performance. Network Appliance filers solve the problem by storing both CIFS and NFS file information natively in an extended proprietary file system designed to accomodate both protocols. CIFS Providers, Developers, and Resources CIFS implementations typically are either ports of the Microsoft Windows NT code that can be licensed from AT&T, or ground-up implementations of the CIFS specification that do not reference the Microsoft code base. AT&T receives NT source code which they port to UNIX. They then sell/license their port to others who can modify it to run on their particular flavor of UNIX. The Microsoft Web site contains a listing of vendors who fall into either of these categories:
http://www.microsoft.com/intdev/cifs/
Every year a CIFS Developers' Conference is held to provide a forum for the further development of the protocol. Presentations from this year's conferences can be found at:
http://www.cifs.com/2ndcifsconf/
Much of the cooperative development takes place on the CIFS mailing list. To subscribe to the list, send mail to Listserv@listserv.msn.com with "sub CIFS your name" in the message text. Mailing list archives can be searched from:
http://microsoft.ease.lsoft.com/archives/CIFS.html
Another indispensable venue for CIFS information is the newsgroup comp.protocols.smb. Summary Integrating NFS and CIFS in a way that makes life easier for both end users and system administrators is a challenge faced by a growing number of sites. This article has highlighted some of the primary interoperability concerns and provides pointers to more information. Although interoperability work is progressing on various fronts, currently working solutions are vendor specific. Footnotes
About the Author
Bridget Allison is a Product Marketing Manager with Network Appliance Inc. She specializes in NFS/CIFS integration issues and Windows NT networking. She can be reached at bridget@netapp.com.
|