Learning about other UNIX-oriented services Windows NT Server is ideally suited to move into UNIX environments--it offers features that rival even the most powerful UNIX servers. For example, Windows NT Server offers price/performance ratios that are similar to UNIX implementations; Windows NT Server is scalable, as is UNIX (although not to the same degree); and Windows NT Server supports a broad range of business applications and infrastructure tools (for example, systems management software, network management software, database managers, and so on). In addition, Windows NT Server's support for TCP/IP enables a Windows NT Server system to be easily inserted into any existing UNIX network.
Despite its attractiveness, Windows NT Server is rarely in a position to completely replace existing UNIX systems because it's not binary compatible with any UNIX version. This means that existing UNIX-based applications cannot be easily transferred to the Windows NT platform. Either new, Windows NT-based versions of those programs must be purchased or the programs must be ported to the Windows NT environment (assuming, of course, that the source code is available). This forces Windows NT Server to integrate with UNIX workstations and coexist with UNIX servers.
All of Microsoft's UNIX integration tools--as well as all the third-party UNIX integration tools--are built on top of Microsoft's TCP/IP implementation. Many UNIX-based tools and features are, in reality, services or protocols built on top of TCP/IP. In essence, TCP/IP is the middle ground for Windows NT/UNIX integration.
When you install the TCP/IP protocol under Windows NT, the installation process also includes the following client-side utilities:
Additional integration tools are available by installing optional services via the Network option in Control Panel. By using these optional services, you can implement:
NOTE: Printing using LPR/LPD is one of three ways to accommodate Windows NT/UNIX printing. The two other methods involve the NFS-based PCNFSD solution and running NetBIOS/SMB under UNIX. These technologies will be discussed later in this chapter.
The client-side aspect of Microsoft's standard Windows NT/UNIX tools provides essential utilities, but it is lackluster in nature. Similarly, the server-side aspect is missing many important services. Some of these limitations can be overcome by deploying the optional Windows NT Server Resource Kit. The CD that accompanies this kit includes a number of additional Windows NT/UNIX integration services, such as:
The rsh server enables a Windows NT Server to process character-mode commands issued from an rsh client system.
NOTE: Consider the Remote Shell service a potential security risk. The rsh specifications call for the originating system to authenticate the user and for the rsh server to trust that authentication. Most implementations of rsh server software do not re-validate the user/password of the requesting client. Rsh does, however, provide a way of limiting which systems and which users can use the rsh server (but again, the server does not authenticate those users).
Adding the resource kit clearly broadens the scope of Windows NT/UNIX interoperability, but it is still limited in many areas and several key services are notably absent. The remainder of this chapter examines third-party products that overcome the limitations of the Microsoft offerings, offer additional key services such as file sharing and enhanced terminal access, and provide a means of porting UNIX applications to the Windows NT environment.
Many third-party companies provide alternate products to those services included with Windows NT Server on the Resource Kit CD or for download from Microsoft. With this in mind, the following Web links provide information about alternate products to implement server-side services for: bootp/DHCP server, DNS, FTP, gopher, mail (SMTP), and rsh.
Alun Jones
ftp://ftp.simtel.net/pub/simtelnet/win95/winsock/32wfd233.zip
* FTP server
Arcane Software
http://vftpd.ebtech.net
* FTP server
Atrium Software
http://www.atrium.de
* Mail server
Cat Software
http://www.cat-soft.com
FTP server
CCnet
http://www.dropbox.com
* Mail server
Consensys Computers
http://www.consensys.com
* Mail server
Denicomp Systems
ftp://ftp.coast.net/Coast/nt/internet/rshdnt17.zip
* Rsh server
European Microsoft Windows NT Academic Center (EMWAC)
http://emwac.ed.ac.uk
* Mail server, gopher server
Ewan Kirk ftp://ftp.demon.co.uk/pub/ibmpc/win95/winsock/apps/windis/windis32.v3.1.zip * Mail server
FBL http://www.fbli.com
* DNS server
Floosietek Ltd.
http://www.demon.co.uk/floosietek/ftgate/download.htm
* Mail server
Hummingbird Communications
http://www.hummingbird.com
* Bootp server, FTP server, gopher server, LPD server
Internet Shopper Ltd.
http://www.net-shopper.co.uk
* Mail server
Ipswitch
http://www.ipswitch.com
* Mail server
IRISoft Works
http://www.irisoft.be
* Mail server
Jarle Aase
http://home.sol.no/jgaa/tftpd.htm
* FTP server
Krypton Communications http://www.winsite.com/info/pc/winnt/netutil/xkims10b.zip
* Mail server
Metainfo
http://www.metainfo.com
* DNS server, mail server
Rockliffe Systems
http://www.rockliffe.com
* Mail server
Seattle Lab
http://www.seattlelab.com
* Mail server
Silviu Marghescu
http://www.cs.umd.edu/~silviu
* Rsh server
SoftArc
http://www.softarc.com
* Mail server
Software.com
http://www.software.com
* Mail server
Tellurian Pty.
http://www.tellurian.com.au
* Bootp server
Viraj Bais, Laurence G. Kahn, and Greg Schueman
access@drcoffsite.com
* DNS server
Weird Solutions
http://www.mhi.se
* Bootp/DHCP server
Ymex Electronics AB
http://www.mailcoach.com
* Mail server
Using Windows NT Server as a file and print server for UNIX systems is often necessary in combined Windows NT/UNIX environments. Although LPR/LPD provides a means of performing print transfer, the Microsoft offerings for Windows NT/UNIX integration provide no reasonable solution for file sharing. Fortunately, the third-party market provides a number of solutions to this problem. The most popular file sharing solutions are based on the Network File System (NFS) model.
NFS is the grand matron of contemporary network-based file serving. NFS pre-dates Novell NetWare, Microsoft/3Com LAN Manager, IBM LAN Server, and all of the other PC-oriented file serving methodologies. NFS was developed by Sun Microsystems as the file-serving component in its Open Network Computer (ONC) architecture. ONC provides a broad range of TCP/IP-based networking services, but it is best known for its Remote Procedure Call (RPC) and NFS components. The "open" nature of Sun's ONC architecture enabled other UNIX vendors to port ONC components to their own unique environments, making NFS a de facto standard for file sharing in UNIX networks.
In a nutshell, NFS enables a system to access designated directories (including all files and subdirectory entries) on other systems over a TCP/IP network. Like Windows for Workgroups (WFW), Windows 95, and Windows NT Workstation, NFS is a peer-oriented solution that enables multiple systems to mount common directories and does not demand a dedicated server.
NFS clients and servers communicate with one another with Sun's RPC architecture, which operates over the TCP/IP User Datagram Protocol (UDP) transport. Under this architecture, NFS clients contact a "port mapper" program on the server, and the port mapper translates the RPC service requests into specific TCP/IP sockets serviced by the local NFS server. Also remember that under the peer-orientation of NFS, a given UNIX system is typically both an NFS client and an NFS server.
To access a directory over the network, the NFS server program must be informed which directories are available for network access, which client systems can access those directories, and what access rights are associated with the various client/directory combinations. The exact method of configuring this information varies from one UNIX implementation to another. For example, Sun systems use the share command to make directories available for network access, whereas most other UNIX implementations configure the directory information in a file named exports.
On the client side, an NFS client requests access to an NFS server directory during the boot process or through an interactive "mount" command. When the NFS server receives the request (via the port mapper program), it compares the requested directory to its list of available directories and authorized client systems. Based on the results of that comparison, the NFS server will either make that directory available to the client (under the control of the associated access rights) or reject the request.
As soon as the client request is satisfied, the client system can access the NFS directory as if it were a local directory entry. For example, an NFS client system named kirk could initiate the following command:
mount spock:/users /susers
If the NFS server system named spock were configured to enable kirk to mount its /users directory, the request would be satisfied. A user working on system kirk could then change to the /susers local directory and access the files and subdirectories that are stored in the user directory on system spock.
Access to specific files and subdirectories in a mounted directory is further controlled by the access rights assigned to the individual users. For example, even though system kirk can mount the /users directory on system spock, that doesn't necessarily mean that all of the users assigned to kirk can access the information in the mounted directory.
When enforcing user-level access control, NFS assumes that users have matching user and group accounts on both the client and server system, or that they share a common user directory database (such as Sun's Network Information System, or NIS). NFS client-side users are not forced to provide a user name and number when they make an NFS request; instead, the unique user-ID number (UID) and group-ID number (GID) are used to verify whether or not an individual user or group has access rights to a specific file. Again, this assumes that the same UID and GID definitions are shared among all systems participating in NFS sharing.
For years, NFS was a UNIX-only offering. In the late 1980s, Sun brought PCs into the NFS fold with the introduction of PC-NFS, a product developed and marketed by Sun Microsystems. The goal of PC-NFS is to enable PCs to participate in NFS networks as NFS clients. By using PC-NFS, PCs can access UNIX directories as if they were network drives. For example, the /users directory on NFS server system spock could be mounted on the PC as network drive s:.
Integration of PCs into NFS posed several problems for the PC-NFS developers. For one thing, the PC file system of that time (FAT16) did not support long file names; the eight-character file name and three-character extension was the law of the land. For another, PCs did not provide any means of user authentication or access control--anybody who sat down at a PC keyboard was, in essence, a "superuser."
The developers of PC-NFS solved both of these problems. First, an algorithm was developed to translate between UNIX names and legal DOS file names. Thus, DOS-based NFS clients could see and access UNIX files with long names, even though the file name might seem peculiar (for example, testin~1.tes instead of testingfile.test). This translation occurs on the PC side of the NFS connection, which enables PC-NFS to be compatible with existing NFS server software. A similar version of this translation is used when Windows 95 or Windows NT operates on a FAT16 volume.
Addressing the second problem--the potential security problem of PC-based users--resulted in the introduction of a new software component to the NFS server architecture. Specifically, Sun created a new server program called the PC-NFS daemon (PCNFSD). The PCNFSD program performs two important functions for PC-NFS:
The use of a PCNFSD approach has become almost ubiquitous in NFS client and server implementations. Virtually all NFS server implementations (including Windows NT-based implementations) optionally support PCNFSD, and virtually all Windows NT-based NFS client implementations support PCNFSD as a means for authentication and print handling.
NFS client and NFS server products are available for both Windows NT Workstation and Windows NT Server. NFS client-side products are clearly more workstation-oriented and are not nearly as critical to UNIX/Windows NT Server integration as NFS server products are. Therefore, the focus here is on NFS server considerations. Furthermore, because PCNFSD is rarely used by UNIX workstations as a client-side authentication system, this aspect of Windows NT-based NFS products is also ignored. Suffice it to say that virtually every Windows NT-based NFS server product supports both the standard UNIX-based authentication model and the PCNFSD model.
What, then, are the considerations for implementing an NFS server solution on a Windows NT Server platform? The first consideration is mapping UNIX users and groups to Windows NT users and groups. All NFS server products provide a means of translating UIDs and GIDs into local server-side user and group accounts. This enables you to leverage the standard Windows NT user/group security model against the UNIX connections. The various Windows NT-based NFS server products have different approaches to handling UID and GID mapping. Some enable you to import the definitions from an existing UNIX system, whereas others force you to set the UID and GID information manually. Figure 47.2 shows a configuration program that uses the manual approach. Most of the differences between the products are more cosmetic than architectural, but frankly speaking, some products are easier to work with than others. This is a key area to examine when you evaluate an NFS server product.
The NFS server product shown here enables you to select existing Windows NT user and group accounts and assign UNIX-side UID and GID numbers to them.
NOTE: Remember that UNIX users will not be required to log on to the Windows NT system--the Windows NT system is trusting the NFS client system to authenticate the user. If this poses a security risk to your site, you should find an NFS client implementation that supports PCNFSD authentication.
The second, and more obvious, consideration is the type of file system you run on the Windows NT Server hosting the NFS server product. The bottom line is simple: You should use NTFS for any NFS implementation. NTFS provides long file name support and supports the Windows NT user/group security model. FAT is not an appropriate file system for an NFS server for two reasons: It forces the NFS server to provide long-to-short name mappings, which affect performance; and it does not provide a level of security that matches the capabilities of the NFS client.
One final area of consideration is multi-threading. Like standard Windows NT file sharing, NFS file sharing is an intensive operation composed of lots of small, concurrent tasks. Any industrial-strength NFS server product must be multi-threaded and must be able to scale well in an SMP environment.
After an NFS server solution is installed, it's reasonably simple to manage--you simply identify which folders you want to share via the NFS server software. The actual administrative interface to do this differs from product to product. Some use an exports file, as used on UNIX systems; some provide a separate GUI interface; and some interface directly into the native Windows NT server environment. The native interface enables you to use the same procedure to share a folder via Microsoft networking or NFS. Figure 47.3 shows a configuration approach that relies on the maintenance of an exports file.
The NFS server product shown here uses an exports file to determine which directories should be shared. A GUI editor is included to manage the information contained in the file.
For additional information about NFS server products for Windows NT Server, see:
Intergraph Corporation
http://www.intergraph.com
NetManage
http://www.netmanage.com
Network Computing Devices
http://www.ncd.com
SOSS
ftp://ftp.winsite.com/pub/pc/winnt/netutil/sossntr4.zip
Tektronix
http://www.tek.com
Xlink Technology
http://www.xlink. com
Because NFS is one of the oldest file sharing methodologies, it does have certain limitations. In particular, it does not offer stellar performance, and it does not scale well in large environments. Two follow-on file-sharing techniques were developed in an effort to address some of the limitations of NFS:
Commercial, Windows NT-based versions of AFS and DFS are available. These products are often used in large, enterprise-oriented UNIX environments that are particularly sensitive to file-sharing performance. Note that these products are not backward compatible with NFS--you cannot use an AFS/DFS server product to handle both NFS and AFS/DFS clients.
NOTE: The Distributed File System (DFS) has no relationship to Microsoft's Distributed file system (Dfs) offering. DFS is a stand-alone file-sharing solution. Dfs is an additional organizational layer that sits on top of Windows NT Server's native file sharing system.
For additional information about AFS and DFS server products for Windows NT Server, see:
Implementing file sharing by using NFS, AFS, or DFS makes a Windows NT Server system look like a UNIX system to existing workstations. As an alternate approach, you can make a UNIX system look like a Microsoft client by implementing NetBIOS/SMB under UNIX. There are only a few products that provide this capability today--but they all implement NetBIOS over TCP/IP and provide bidirectional file sharing and printer sharing capabilities.
In the context of Windows NT Server, a UNIX system running NetBIOS/SMB software appears as another Microsoft client. A UNIX system can then offer file and print resources to the network for Microsoft clients to share, or it can access shared resources as a Microsoft client. When accessing a Windows NT Server as a client, the Windows NT Server validates the UNIX-based user/password information and access is controlled by using standard Windows NT Server security. This is an elegant solution from the Windows NT perspective, but often less-than-elegant from the UNIX perspective.
For additional information about NetBIOS/SMB products for UNIX, see:
FacetCorp
http://www.facetcorp.com
Santa Cruz Operation (SCO)
http://www.sco.com
In many UNIX environments, terminal access to Windows NT Server takes on two different meanings. In one context, terminal access can be defined as access from X Terminals to Windows NT-based graphical applications. In another context, however, terminal access can be defined as access from terminals or workstations using the character-based Telnet utility.
A Windows NT Server can, in fact, support both types of access, but the solutions to address these two different access types are radically different. X Terminal access to Windows NT Server requires multi-user extensions to enable multiple X Terminals to concurrently access Windows NT Server in different user contents. Character-mode Telnet access is less sophisticated technology than X Terminal access. In the context of Windows NT, Telnet access to a Windows NT Server enables a Telnet-based user to log on to Windows NT and access the command prompt environment. Of course, when it comes to Telnet access to Windows NT Server, the big question is always: "Why?" There are, in fact, several reasons why companies implement Telnet server products under Windows NT Server:
Surprisingly, several vendors (including Microsoft) offer Telnet servers for Windows NT. They all share the common purpose of accepting Telnet connections, but they differ on other features. Some of the factors you should weigh in evaluating a Telnet server include:
When you access a Windows NT Server through Telnet, the Telnet server performs the user, password, and domain validation.
CAUTION: In most cases, user authentication using Telnet consists of clear text passwords. This can result in serious exposure when using Telnet over a public network (such as the Internet). Although several standards exist for encrypting user/password information between a Telnet client and server, these standards are rarely available in Telnet client and server products.
The capabilities of the Telnet client also contribute to the usefulness of the Telnet server environment. For example, the standard Windows NT Telnet client is a poor choice for Telnet server access because it does not support color and has limited support for monochrome highlight attributes. A commercial VT340 or VT420 Telnet client, on the other hand, can deliver an environment that is remarkably close to a native Windows NT command-line window. Figure 47.5 shows the difference between the Microsoft Telnet client and a commercial VT340 Telnet client.
For additional information about Telnet server products for Windows NT Server, see:
Hummingbird Communications
http://www.hummingbird.com
Pragma Systems
http://www.pragmasys.com
Seattle Lab
http://www.seattlelab.com
Windows NT Server is often used as a platform for porting UNIX applications to the Windows NT environment. Porting character-mode applications is not a terribly difficult proposition--virtually any mainstream C/C++ compiler can handle that level of migration. Compilers also can be augmented by UNIX development tool kits that implement a UNIX-like development environment. For example, tool kits can provide support for the make utility, awk, and other common development tools.
The standard Microsoft Telnet client (foreground) only provides rudimentary capabilities. A more sophisticated Telnet product (background) offers a better look and feel.
Porting a graphical X Windows-based application from UNIX to Windows NT is a much more difficult proposition. Not only are the appearance and controls used by X Windows programs different, but the underlying Application Program Interfaces (APIs) are very different from the native WIN32 APIs. Two approaches are available to migrate X Windows applications:
Implementing X Windows APIs in the Windows NT Server environment takes a fair amount of overhead and results in products that don't run at optimal speed. After all, the underlying third-party product must not only emulate the entire set of X Windows APIs, but it also must provide an X Window terminal emulator to provide a user interface to the application itself. For this reason, very few commercial products are released to the Windows NT market as X Windows applications.
On the other hand, the direct port of a UNIX X Windows application to a Windows NT X Windows application is a faster and less error-prone process than performing a full port to the WIN32 APIs. As a result, many corporations take this approach for their proprietary or internal X Windows applications.
For additional information about UNIX-to-Windows NT application porting products, see:
DataFocus
http://www.datafocus.com
Mortice Kern Systems
http://www.mks.com
Softway Systems
http://www.softway.com
The UNIX environment includes additional TCP/IP-based services that are not delivered on the Windows NT Server distribution CD, not available for free download by Microsoft, and not included in the Windows NT Server 4.0 Resource Kit. Fortunately many of these services are available from third-party companies or well-intended individuals. In particular, the following services or utilities might be useful in a Windows NT/UNIX integration environment:
NOTE: A typical implementation of finger returns user-oriented information, as shown in Figure 47.6. Some vendors, however, use finger for a different purpose and return system environment information instead of user information, as shown in Figure 47.7.
A typical implementation of finger returns the user information stored in the user account definition and any information contained in an optional plan.txt file.
Some implementations of finger return detailed system information instead of user information.
For additional information about finger server, TFTP server, and UUCP products for Windows NT Server, please consult the following Web links:
European Microsoft Windows NT Academic Center (EMWAC)
http://emwac.ed.ac.uk
* Finger server
Ewan Kirk ftp://ftp.demon.co.uk/pub/ibmpc/win95/winsock/apps/windis/windis32.v3.1.zip * Finger server
Greyware Automation Products
http://www.greyware.com
* Finger server
Hummingbird Communications
http://www.hummingbird.com
* Finger server
Kendra Electronic Wonderworks
http://www.kew.com
* UUCP
Robert O'Callahan
ftp://ftp.coast.net/pub/Coast/nt/internet/ntfngd09.zip
* Finger server
Weird Solutions
http://www.mhi.se
* TFTP server
Ymex Electronics AB
http://www.mailcoach.com
* UUCP
© Copyright, Macmillan Computer Publishing. All rights reserved.