Sharing and Securing Information in Mixed NT-UNIX Environments

The keys to efficient interoperability

Suppose you're the network administrator at a large UNIX shop, and your MIS department standardizes all your network's client workstations on Windows NT Workstation 4.0. Naturally, your new NT users want to access their UNIX-based files from their NT machines. What are your choices for a low-cost, workable solution to this problem? Unfortunately, the options are fairly limited. UNIX and NT originated from distinct roots, and because their backgrounds are different, each operating system's (OS's) mechanism for storing and sharing files is unique.

There is good news, however. With the growing popularity of NT in large enterprise environments, several methods can help you facilitate file sharing between NT and UNIX. You can enact noninteractive access by means of Microsoft programs such as File Transfer Protocol (FTP) or HyperTerminal, or interactive access by using tools that employ either the Common Internet File System (CIFS) standard or the NFS communications protocol. In this article, we'll describe how these access methods work, and what their strengths and weaknesses are. Then, we'll discuss the security problems that arise when you share files across platforms, and what you can do to address those problems. Along the way, we'll describe connectivity tools that can help make cross-system file sharing as painless and transparent as possible.

File-Sharing Solutions
Microsoft's TCP/IP suite is limited in file-transfer options. One option is to use NT's FTP client to transfer files between UNIX and NT hosts. Or, you can use the Telnet program to transfer files. Unfortunately, these solutions are slow and don't work in environments where multiple-user access to a file is necessary. In addition, Telnet can transfer only ASCII files--not binary files. TCP/IP solutions are suited primarily to environments where you need to transfer personal files to and from a storage facility on a UNIX host. The points in the TCP/IP methods' favor are that all UNIX OSs include FTP and Telnet servers, and NT includes FTP and Telnet clients.

Another native Microsoft solution is to use HyperTerminal (packaged with NT 4.0 and Windows 95) to transfer files to and from a UNIX system. HyperTerminal supports four file-transfer protocols: XMODEM, YMODEM, ZMODEM, and Kermit. When you use HyperTerminal, you must have a program on your UNIX system that supports one of the HyperTerminal transfer protocols.

If you use a third-party vendor's TCP/IP suite on your NT machines, you might have additional options for performing NT-UNIX file transfers. On most UNIX systems, users have access to the remote copy (rcp) command, which copies files from one OS to another. Another group of programs, collectively referred to as the UNIX-to-UNIX Copy (UUCP) program, lets you transfer files interactively or in a batch mode. Vendors are now making these once UNIX-specific programs available on NT for easier cross-system communication.

The CIFS and NFS options are interactive--either protocol installed on one platform can access files on the other platform as if the files were local. However, to use CIFS or NFS, you must install additional software on either your UNIX or NT hosts. CIFS, originally known as Server Message Block (SMB), is the default network file-sharing mechanism that NT machines use. You equip your UNIX hosts with CIFS software to let UNIX users participate in your NT file-sharing network environment. Alternatively, you can install NFS-enabling software on your NT machines to let your NT users participate in UNIX file sharing. Using NFS requires you to install an additional software package on all your NT machines, a potential administrative headache. Fortunately, a growing number of NFS products offer gateway connectivity between desktop computers and NFS resources, eliminating the need to install software on every NT machine. Let's look more closely at the CIFS and NFS options.

CIFS on UNIX. Implementing a CIFS solution on the UNIX side is often the cleanest cross-system file-sharing solution, because it doesn't require you to install special drivers on your NT host. In addition, growing numbers of UNIX vendors include some form of CIFS software with their products. Even if your UNIX vendor does not include a CIFS solution with its products, you can still choose from several good freeware and third-party products.

At the inexpensive end of the equation is the freeware product Samba. Available in source-code form over the Internet, Samba is perhaps the best CIFS-enabling software product available. You can configure Samba to act as a Primary Domain Controller (PDC) for your NT domain. When a UNIX user connects to the domain, Samba automatically executes an NT logon script. Alternatively, Samba lets you share UNIX directories and printers as shares, as any NT host would. (For more information about Samba, see Mark Joseph Edwards, "Samba," March 1997.)

If freeware doesn't excite you, you can opt for a commercial product. Perhaps the predominant CIFS-enabling UNIX product on the market today is SCO VisionFS. SCO VisionFS offers full CIFS capabilities, including file and printer sharing. Unfortunately, SCO VisionFS doesn't offer any of the advanced domain capabilities Samba offers; however, SCO VisionFS lets you verify user security against an NT domain controller. A version of SCO VisionFS exists for virtually every major UNIX system, including AIX, HP-UX, and SunOS. The downside to SCO VisionFS is its cost: You need to purchase a client access license for each user who will use the product to share files.

Operating either Samba or SCO VisionFS on your UNIX host requires NetBIOS enabled over TCP/IP. Because most UNIX OSs don't have a NetBIOS over TCP/IP driver, SCO VisionFS contains a self-contained NetBIOS driver that provides this capability. (Samba includes a NetBIOS daemon, nbd, that enables NetBIOS over TCP/IP.) Setting up and administering both SCO VisionFS and Samba is easy, although both products require a thorough knowledge of the UNIX OS you install them on.

The most difficult part of administering SCO VisionFS or Samba might be creating user accounts on NT and UNIX systems that have access to files on both systems. For example, on an NT domain Mike's logon might be mdeignan, whereas on a UNIX machine it might be mpd. If Mike tries to access resources on the UNIX machine from an NT domain, no mdeignan logon exists to let him do so. CIFS software needs to know how to translate NT logon names to UNIX account names. In most instances, cross-system file-sharing software packages have a manual translation table, but you need to configure the software to tell it how to perform the translation. In general, using the same username on both platforms is easiest--even if you experience some short-term pain in converting all your usernames to a new standard.

NFS on NT. Sun Microsystems developed NFS to facilitate file sharing between UNIX systems in large decentralized computing environments. You can implement NFS capabilities in two ways: by using either an NFS client or an NFS server. The NFS client lets you mount UNIX file systems the UNIX server exports (equivalent to an NT share) on NT host machines. The NFS server lets you export file systems from your NT hosts to UNIX machines. UNIX machines can access these file systems as if they were file systems on other UNIX machines running NFS.

No freeware NFS server or client is currently available for NT systems--your choices are limited to commercial products. Fortunately, many vendors offer NFS connectivity, including Sun Microsystems, NetManage, WRQ, Intergraph, and Hummingbird Communications.

Sun Microsystems' NFS client software is Solstice NFS Client. You can download a 30-day evaluation version from Sun's Web site. NetManage offers an NFS server and client software package as part of its UNIX Link Internet applications suite. WRQ's Reflection NFS Gateway lets NT clients on your network access NFS file systems through your NT server without requiring you to install additional networking software on each workstation.

Intergraph offers AccessNFS, a series of NFS-enabling products. DiskAccess provides full NFS client capabilities for NT or Win95 systems. DiskShare is an NFS server product. AccessNFS Gateway lets you mount NFS file systems on your NT server and share them with other clients on your network. Microsoft licensed AccessNFS for inclusion in NT 5.0.

Hummingbird Communications' NFS Maestro provides both client and server NFS capabilities for your NT host. NFS Maestro lets NT hosts either export file systems to UNIX machines or mount file systems from UNIX hosts as local file systems.

File Sharing and Security
Two major problems have slowed the acceptance of NFS as a file-sharing mechanism in the NT world. First, NFS usually requires a great deal of administrative overhead, in terms of both administration and software maintenance. If yours is a smaller networking environment and you use a networking protocol other than TCP/IP, you must install TCP/IP so NFS can function. If you install NFS, you can no longer use NetBEUI. The second and perhaps larger problem is NFS's lack of comprehensive file- and directory-level security. UNIX implementations, and consequently NFS implementations, lack the comprehensive file- and directory-level security capabilities that NT offers.

CIFS-based solutions on UNIX systems suffer from similar security problems, and depending on the CIFS-enabling technology you use, you might have the same security problems with CIFS that you have with NFS. But if you understand the implications of file and directory security in a CIFS or NFS world, you can implement an effective security solution that lets your users share files without compromising the integrity of your system's data. Let's take a moment to explore NT's and UNIX 's security structures. When you understand how they compare, you will be better able to formulate an effective cross-system security strategy.

NT: The Janitor's Key Ring
When Jim was in grade school, his school's janitor had a huge key ring attached to his belt. The thing must have had a thousand keys on it, and it didn't jingle but thunked as the janitor walked down the halls. Security on an NT system reminds us of that key ring. You can have thousands of keys on your system, and each door can have multiple locks. Which locks you can open on which doors depends on your keys.

Permissions in NT give users special keys. One key gives you read access to a particular resource, whereas another key gives you write access to a different resource. Because users can be members of various groups, they have keys for those groups, as well. One important NT functionality is the ability to create groups within groups. Group membership in NT is transitive, so a user in Group A is automatically a member of all the groups that contain Group A. For example, the local Administrators group contains the global Domain Admins group. Because of this transitivity, members of the Domain Admins group are automatically members of the local Administrators group. Transitivity often makes things easier for NT-only administrators, but it presents problems in a mixed network.

Another important aspect of NT security is the trust relationship. Administrators can configure two domains to trust each other, which lets administrators in one domain give access permissions to users in the other domain. This trust relationship lets two domains share resources without the need for a common user database.

From a security perspective, NTFS's most significant feature is that you define access to a resource by using an access control list (ACL). As its name implies, an ACL is a list associated with a file of the users and groups who have permission to access or modify the file. However, if you use FAT on your NT system, you can't use the security features NTFS provides.

UNIX: Fewer Keys to Fewer Locks
Gaining access to a UNIX system is essentially the same as accessing NT. Users have a user account and password to identify themselves to the system. When users log on to the UNIX system, their identity determines their access to resources. Like NT, UNIX designates users and groups to determine resource access. Unlike NT, however, UNIX stores lists of users and groups in text files (/etc/passwd for users and /etc/group for groups). These text files contain all the information about the user's initial environment, including home directory, startup shell, user ID (UID), group ID (GID), and on some systems the encrypted user password. Most recent versions of UNIX can store encrypted user passwords in a separate file (usually the file /etc/shadow), so it is not accessible to users of those versions.

Like NT, current versions of UNIX let users belong to multiple groups. However, many UNIX systems don't allow groups within groups. You can add this functionality to your UNIX system by using Network Information Service (NIS), the most recent version of which is NIS+. NIS is a database containing user and group information that is similar to the user database in NT. NIS manages this information with a single server (the master server) in a domain, which replicates the information to the computers in the domain. (An NIS domain is not necessarily the same as either an Internet domain or an NT domain.)

As in NT, in UNIX a user's UID and GID determine access to resources. However, UNIX allows only three kinds of permission: read, write, and execute. Special permissions, such as take ownership or change permissions, do not exist in UNIX. UNIX systems do not use ACLs, defining access through three designations: owner, group, and world/other. (The world/other designation is similar to NT's Everyone group).

When you use the ls ­l command on a UNIX system (the syntax varies slightly depending on the specific UNIX system) to list files, a list of access permissions for several files appears. This list is similar to Table 1. Each line of the table consists of four columns. The first column identifies the file's access permissions. The second column identifies the file's owner. The third column identifies the file's group membership. The fourth column lists the file's size, creation date and time, and name. Let's look more closely at the first column--the file's access permissions.

In the sample file access permissions

-rw-r----- 1 jimmo admin 12709 15 Sep 98 12:04 security.txt

the access permissions list consists of 10 characters. The first character is usually either a d, which identifies a directory, or a hyphen (-), identifying a file. The following nine characters break out into three sets of three characters each. An r signifies read permission, a w signifies write permission, and an x signifies execute permission. A hyphen (-) stands for the absence of a specific permission. The first set of three characters represents the file owner's permissions, the second set of three characters represents the file's group permissions, and the third set of three characters represents the file's world/other permissions.

UNIX associates files with an owner and a group. If you are not the file's owner and not in the file's group, UNIX determines access by the world/other access. UNIX has no permission to explicitly deny a user or group access to a file. Therefore, if a UNIX user is a member of a group with access permission to a file or directory, the user has access to that file or directory. In the sample file access permissions printed above, the file's owner has read and write permission but not execute permission to the file. The file's group has only read permission to the file, and the world/everyone group has no access to the file.

As we mentioned, UNIX systems use NFS to share files. The NFS server keeps a list of file directories, and UNIX administrators can define access to those directories for specific users and also for specific machines. So, although a user might have permission to access a particular file, that user can't open the file on a machine that doesn't have access permission. A key difference between NT and UNIX is that NFS access in UNIX is usually defined on a per-machine--not per-user--basis.

As in NT, you run into problems in UNIX when you want to share resources between machines. Because UNIX users can exist on the NFS server but not on the client machine, UNIX administrators face the question of how to determine appropriate machine access. By default, UNIX treats the UID on a client the same way it treats the UID on the server. This default behavior requires a user to have matching UIDs on client and server. Although maintaining matching client and server UIDs is a straightforward task in UNIX, the possibility still exists that a user's client and server UIDs won't match. UNIX systems that employ NIS have a common user database where all UIDs are consistent. However, such a one-to-one mapping between client and server is not always desirable: for example, in the case of root users. A number of UNIX versions, such as DEC UNIX, enable the mapping of root users by default; that is, the root on one machine is the root on another. (In the NT world, default mapping of root users would be as if a Local Administrator had rights on every NT machine in the domain.)

In addition to employing NFS mapping, UNIX administrators can map users on different machines through user equivalence. In user equivalence, you define two machines as equivalent (i.e., users with a particular ID can access both machines), or you can define equivalence on a per-user basis. When you define equivalence on a per-user basis, you can define equivalence between multiple users. For example, you can define multiple users on a remote machine as equivalent to a single user on the local machine. User equivalence functions similarly to a trust relationship in NT, in that users don't need to authenticate themselves on all the machines they connect to.

When the Keys Don't Fit the Locks
Although security problems can occur when like systems connect (e.g., NT to NT or UNIX to UNIX), the problems increase dramatically when different systems connect. The keys no longer fit the locks; that is, no standard mechanism is available for sharing user information between the two systems. The two obvious problems that result are difficult to overcome. The first problem is the difference in the way each system defines access to particular resources: No simple one-to-one relationship exists between these definitions. The second problem is that each system stores and manages user information differently. Thus, sharing user information between systems is extremely difficult.

NT 5.0 addresses the second problem to some extent with the Kerberos authentication protocol, which provides authentication services from one database. To use Kerberos, clients encrypt passwords, which increases security. Administration is easier because Kerberos provides a central user database for NT and UNIX. Many applications are already Kerberos-aware.

If you provide UNIX resources to NT clients with NFS, your NT machines need an NFS client and must convert from an NT username to a UNIX username. Some connectivity products provide a separate logon program for connecting NT clients to the NFS server. Often, these tools save the separate password on the local machine, providing an invisible connection from the NT computer to the NFS server. Doing so provides a single logon and one-to-one mapping between an NT user and a UNIX user. In addition, some connectivity products support NIS. With NIS, when users log on to an NT computer, the NIS server can automatically authenticate them. Many connectivity products have mapping tables, so multiple users who log on to one NT machine map to the correct UNIX user. With these products, if the UNIX server is running the pcnfsd daemon, NT users might need only to type in their NT username and password. The UNIX server can then log them in, supplying a UID and GID. If the UNIX server is not running the daemon, NT users must manually input a UID and GID.

Although the problem of sharing user information between systems is the same when a UNIX machine provides connectivity via CIFS, the situation can be different. With NFS, a UNIX server almost exclusively provides connectivity service. However, when a UNIX server uses CIFS to provide connectivity, an NT server in the network might provide authentication.

Different connectivity products take different approaches to this situation. For example, SCO's product OpenServer's Advanced File and Print Server (AFPS) can take over the functions of an NT PDC or backup domain controller (BDC). AFPS maintains a complete user database, as you would find on an NT server, and doesn't map users, because it considers NT and UNIX users identical. When users log on to the domain from an NT workstation, the AFPS server authenticates them, even if the AFPS server functions as a BDC.

AFPS has two added advantages. First, AFPS provides server tools that are identical to the tools on an NT machine (e.g., User Manager, Server Manager) and that you can install on clients. AFPS User Manager can create users, just as NT's User Manager can do. Second, when you create users with the OpenServer interface, they automatically become AFPS users. AFPS gives users access to UNIX resources via NFS and to NT resources via CIFS.

Samba can take over many NT PDC functions. For example, Samba can provide authentication services and logon scripts. When you use Samba you must create users on the local UNIX machine, and Samba does not support the ACL on NT files. However, with Samba, you can designate another server (e.g., NT or AFPS) to provide authentication. Samba also accomplishes one-to-one mappings between NT and UNIX users and can map to multiple users and groups of users. For example, from one machine you can map the NT administrator to the UNIX root user. Doing so gives you root access to all the files on the server. You can also create a group of NT users that need access to one directory and map them to one UNIX user.

Open the Door
Supporting your users sometimes means giving them access to resources on a different OS, whether NT to UNIX or UNIX to NT. If you've been taking the sledgehammer approach and making copies of all your data for both OSs, you need no longer do so. Now that you know which keys fit your NT and UNIX locks, you can open the door to easier and more effective NT-UNIX administration.