Adding R* to Windows NT
Robert Flannigan
Adding Windows NT servers to an existing UNIX or heterogeneous environment does not necessarily mean giving up familiar distributed computing tools used by UNIX administrators. With a minimal investment in an NFS package for Windows NT and adding the free RSHSVC included in the Windows NT Resource Kit from Microsoft, system managers can leverage their existing knowledge of the Berkeley "R" command family (rsh or remsh in particular) to make Windows NT a bit more UNIX-friendly. Access to UNIX and other legacy data and the ability to coordinate processing between UNIX and NT allows automation of tasks by stringing together UNIX processes with NT batch files, executables, or any other non-interactive scripts that can be executed by Windows NT. By using this method my employer, Jacobson Stores, has achieved a reliable decision support database batch update of daily sales information from mainframe and UNIX transactions that are processed into "cleansed" files by UNIX systems, then ultimately loaded in parallel to their final destination of an ESSBASE database engine running under Windows NT server. This tight coupling of the two operating systems can be a cost-effective way of integrating two very different computing platforms. Security Issues As with installing other services such as ftp, activating RSHSVC on a particular machine will inherently weaken built-in security and is not recommended for any system that is connected to an untrusted network, acting as a firewall, bastion host, or aspiring to achieve C2 level security. Inside a properly configured firewall (one not accepting connections to SHELL / EXEC TCP ports) or any other relatively secure corporate intranet, the benefits of having the service available usually outweigh the perceived risks. As a side note, on the same Technet CD that contains the distribution files for RSHSVC, Microsoft also indicates that it is only available via third parties, citing a "security loophole" [1]. From what I've gathered, this service, which is similar to a UNIX daemon, was written by Microsoft but remains unsupported. All of my emails sent over the past year to the microsoft.com address listed in the installation documentation have gone unanswered. The main security risk in running RSHSVC under Windows NT involves setting up trusted hosts using .rhosts files. Please note that this trust relationship deals only with remote command configurations. Domain trust relationships between Windows NT Server Domain Controllers are a completely separate subject. Using "equivalent" or "trusted" hosts involves granting the right for remote systems to execute commands on a given server without going through a login process. Utilizing this "blind" trust, it may be possible for an intruder to forge a .rhosts entry and gain access to a system using a few different methods. For example, if the C: drive on the NT server is a FAT filesystem (without NTFS file level security) and the default \\<server>\C$ administrative share is able to be accessed remotely, then a cracker could edit the .rhosts file directly on the host system. A second method involves physical access to the server, whereby a malicious user could directly edit or copy in a version of .rhosts that would grant access to his or her chosen servers and user IDs. A second security risk associated with rsh (or rcp, rexec, rlogin, telnet, ftp, et al.) is password authentication being passed between machines without being encrypted between endpoints. A packet analyzer running on a particular network segment can capture and forward plaintext password information, presumably to a malicious user. Passing unencrypted passwords across a LAN/WAN will not qualify your installation for "bulletproof" security certification, but there are ways of configuring trusted hosts and user accounts that can minimize risk should this information become compromised. As a good rule of thumb, if your security policy allows for R* command activity on your existing network of UNIX machines, then installing the service under Windows NT should not violate this policy. A properly configured NTFS filesystem that contains the %SystemRoot% subtree, with read-only access granted to the owner of RSHSVC via the .rhosts file, should go a long way toward patching the known security holes common to the R* commands under UNIX. NFS security is fairly well documented. If your NT systems will only be acting as NFS clients, then most security risks with NFS are minimal. If you plan to deploy NFS server configurations under NT, please refer to the many available materials on the subject [2] and read to the appropriate vendor's documentation supplied with the NFS software. Making UNIX Data Available to NT Before UNIX servers can execute Windows NT commands remotely, a standard method of sharing data among the machines is essential. Methods abound to achieve this goal, including ftp, rcp, stdin, and many others. At Jacobson's, we chose to implement an NFS package for Windows NT because of its wide availability, ease of use, and adherence to standards. We installed Chameleon32 NFS from NetManage, although there are other comparable packages on the market [3]. The documentation was good, and installation was a snap. After the software was installed and the NFS client properly configured, a separate ChameleonNFS Network Share came up under the "Connect Network Drive" dialog box in File Manager under NT 3.51. Similar facilities exist in Explorer under NT 4.0, which allow the user to browse NFS-shared volumes in much the same manner that standard Windows-shared resources are browsed. Another feature of this package is that the net use command line can be used to address UNIX systems in UNC (\\nfs_server\nfs_share) format from Perl scripts, .bat and .exe files, along with the command prompt. I mounted the company standard /pub NFS volume as a logical drive P: under Windows NT. Thus, any UNIX process that puts data under /pub makes the data immediately available to Windows NT client systems. Additionally, NFS provides automatic, user-transparent CR/LF mappings between UNIX and Microsoft filesystems. So, with seamless data access available, the systems can now interact. Windows NT Remote Shell Service Remote command execution has been a mainstay of UNIX systems since the earliest BSD releases containing the R command utilities. Almost every modern UNIX dialect has adopted this comand set, which features the rlogin, rcp, rexec, rsh (remsh), rcmd, rwho, and other remote commands. SVR4 variants that had already implemented the rsh command for restricted shell use the remsh nomenclature, but rsh and remsh functionally are equivalent. The inner workings of the client and server processes are well documented in the man pages for each OS [4] and in many UNIX system administration books. Specifically considering remote shell services under Windows NT, there are many similarities between the NT version and the UNIX implementation: RSHSVC installs as an NT "service," akin to the UNIX remshd daemon (see Figure 1). The familiar .rhosts file is used for authentication, but there is no support for hosts.equiv (see Listing 1). RSHSVC uses the same "well known" TCP port of 514 to accept client connections for the shell service, as specified by the %SystemRoot%\System32\drivers\etc\services file. Once the service is started, it listens for inbound connect requests on the "shell" port and dispatches processes to handle each client request (see Listing 2). Installing Remote Shell Service Getting RSHSVC to run on Windows NT is quite simple, once the distribution files have been located. The three files needed for the install are named rshsetup.exe, rshsvc.dll, and rshsvc.exe. If you have installed the Windows NT Server Resource Kit [5], then these files should be located in the root directory of your Resource Kit installation, usually C:\reskit. If you are a Technet CD subscriber [6], the files can be located on the Supplemental Drivers and Patches CD under the Path \samples\boes\winnt\ntrk351\<arch>\inet, where <arch> is i386, MIPS, Alpha, or PowerPC. The piece of documentation that will help you through the install is named rshsvc.txt and is located in \samples\boes\winnt\ntrk351\common\inet\ on the Technet Supplemental CD. The instructions are fairly straightforward and consist of: 1. Copying rshsetup.exe, rshsvc.exe, and rshsvc.dll to %SystemRoot%\System32\ 2. Executing rshsetup %SystemRoot%\System32\rshsvc.exe %SystemRoot%\System32\rshsvc.dll This command should return a message of:
The Remote Shell Service was successfully installed.
3. Executing net start rshsvc This command should return a message of:
The remote shell service is starting. The remote shell service started successfully.
You do not need to reboot in order to begin using this service. 4. Create your .rhosts file to give access to your UNIX systems (see Listing 1). This file must be stored under %SystemRoot%\system32\drivers\etc. The entries for .rhosts are the same as the standard UNIX entries: Client1 User1 [User2 à UserN] This whitespace delimited list begins with a remote client hostname that can be resolved by gethostbyname() on the server machine, and then lists one or more trusted users on that host. 5. Set the service to automatically start upon reboot, if desired (see Figure 1). To have the service start automatically, open the Services applet in the Control Panel. Scroll down until you see the "Remote Shell Service" line. Highlight this line, and click Startup to bring up the Services startup dialog box. If you wish this "daemon" to start each time the machine boots, select Automatic and click OK. Using Remote Shell Service The possible applications of Remote Shell Service with Windows NT are limited only by the creativity and imagination of system administrators, and of course by necessity. The role your NT server(s) plays relative to other systems determines what use your UNIX systems will have for the service. The primary NT server used at our data processing center acts as a Decision Support server for approximately 100 end users. The platform hardware is an NCR S40 4-way P133 with a 24 GB RAID unit, holding multiple instances of ESSBASE multidimensional database engines. This machine is currently running Windows NT Server 3.51 SP5. To load the databases with timely information on a daily basis, we needed a way for mainframe batch jobs to remotely call a UNIX shell script after completion (a custom daemon was written for this purpose). The shell script pulls the transaction file from the mainframe, and then splits the transaction file into three separate load files for the NT databases. After the shell script copies the three files to an NFS volume accessible from the NT server, it then launches three simultaneous remsh commands to the NT server. These commands run batch files containing ESSBASE script commands to load, calculate, and commit the data (see Listing 3). With this "chaining together" of Mainframe to UNIX to NT processing, we can provide timely decision support information to users at corporate headquarters and remote users in each retail store or through dialup access. The logic of this process could be adopted to fit other vendor's database engines running under NT Server with little modification. Other utility examples and ideas for using RSHSVC with UNIX might be: To read server statistics from Windows NT and log them on an HP-UX client, you could execute:
remsh ntserver "net statistics server" >> /var/adm/foo.log
From a Solaris Korn shell-based script that monitors UNIX system health around the network, the ability to watch over NT disk space utilization for a particular logical drive volume could be added with:
box=ntserver drive="c:" threshold=10000000 available=`rsh $box dir $drive | grep -w "bytes free" | tr -s ' ' | cut -d' ' -f2 | \ tr -d ','` if [ $available -lt $threshold ] then mailx -s "WARNING: $box - low disk space on $drive" sysadmin < /dev/null fi
The "cron" facility that comes with Windows NT is called at.exe. The graphical version that we installed sometimes mysteriously does not execute scheduled tasks properly. If you do not wish to purchase more robust schedulers for NT, or if you like to consolidate cron functions under one "master" UNIX system, then RSHSVC might be used to periodically reboot systems with the shutdown.exe, or perhaps perform nightly backups with ntbackup.exe. NCR MP-RAS SVR4 examples follow:
# reboot ntserver at 1am every Sunday 0 1 * * 0 remsh ntserver "shutdown /L/R/Y/C/T:60" # verified backup ntserver to tape every day at 3am, with# Registry backup and hardware compress 0 3 * * * remsh ntserver \ "c:\\winnt35\\system32\\ntbackup.exe backup \ c: e: f: g: h: /l \ c:\\users\\default\\etc\\backup.log /b /v /hc:on"
Odds and Ends Because this service, for all intents, appears to be unsupported by Microsoft, it comes under the realm of "as is" software. We have been running this successfully at Jacobson's for well over 18 months without incident, and use it many times daily. However, there are a few implementation details that users should be aware of, namely: rshsvc.txt indicates that the connection will timeout after 10 minutes for commands that have not completed executing and that commands taking more than 10 minutes will not execute properly. We have not found that to be the case. As long as you are not launching interactive sessions requiring input on stdin, then most commands should work regardless of the time span. One by-product I noticed is that stdout from commands taking more than 10 minutes to execute gets redirected into a file at the root of the C: drive named rsh$xxx.000, where xxx is a sequence number. These files periodically need to be cleaned, or they will accumulate over time. When editing the .rhosts file, it is a good idea to use the Notepad or other comparable editor. NT's vestiges of DOS do not allow you to use EDIT with a filename that begins with a dot. Also, it is a very good idea to stop/start the Remote Shell Service after changing the .rhosts file for the changes to take effect. Absolute pathnames are good to use in referencing all commands that are executable files. Protect backslash characters by using proper quoting or \\ to keep UNIX shells from interpreting DOS pathnames as escape sequences. In an environment with multiple NT servers connected, the rsh.exe command can be used for NT to NT remote execution. Client and Server configuration for this is the same as using UNIX clients to execute remote commands. Rsh.exe can also be used from a Windows NT client to access UNIX servers, if permissions are set correctly in .rhosts on the target UNIX server. There are also third party products available for Windows 95 allowing a PC to use remote shell client services on either UNIX or NT servers. Some third party software vendors also offer "production grade" versions of remote shell services, along with telnet, Rexec, X, and other products [1,3,6]. Please use the references at the end of the article or contact your Microsoft representative for more details. With POSIX-conforming utilities becoming available for NT, integrating NT with UNIX should become easier in the near future. There are many published references in print and available as hypertext. I encourage system administrators adding NT servers to their existing UNIX environments to check out the books listed at the end of this article and to check Microsoft's knowledge base available at their Web site (and on CD). Using RSHSVC and NFS with NT is only one of many methods to achieve tight integration using today's technology. By adhering to the "there's more than one way to do it" credo, many more practical UNIX/NT solutions will continue to be built . Bibliography [1] http://www.microsoft.com/syspro/technet/boes/bo/winntas/technote/nt204.htmhttp://www.somarsoft.com/security.htm [2] http://dune.mcs.kent.edu/~farrell/sa96/notes/nfs/sunnfs/nfs_15.html [3] http://www.xlink.com/xl06004.htmlhttp://www.interwork.com/products/Interop-opensystems/interdr2.html [4] http://wsspinfo.cern.ch/man-hp/remshd(1M) [5] Microsoft Corp, Microsoft Windows NT Server Resource Kit, Microsoft Press, 1996 [6] Microsoft Corp, February 1997 Technet CD, Microsoft, 1997 [7] http://www.ntinternals.com/
Cox, J., and Goodheart, B. The Magic Garden Explained: The Internals of UNIX System V Release 4: An Open Systems Design, Prentice Hall, 1994. Leffler, S. J., McKusick, M. K., and Karels, M. J., The Design and Implementation of the 4.3BSD UNIX Operating System, Addison-Wesley, 1989. Stevens, D.L., and Comer, D.E. Internetworking With Tcp/Ip: Client-Server Programming and Applications: Bsd Socket Version, Prentice Hall, 1996.
About the AuthorRobert Flannigan holds a BSCS from the College of Engineering, Michigan State University (1994). He has been working creatively with computers since the early 1980s and has spent the greater part of the past 9 years working with Unix. His current work for Jacobson Stores Inc. involves system administration of Unix and Windows NT systems and database administration. Robert can be reached at: flannigan.robert@infoband.com.
|