Cross-Platform Remote NT Administration

The good newsis that you can remotely administer NT tasks from non-Windows systems. The better news is that a variety of methods exist to do so. Here's a sampling.

Vijay Sankar

July 31, 1999

12 Min Read
ITPro Today logo in a gray background | ITPro Today

Choose your solution

Much of the work we do involves interoperability and security, and the sites that call on us usually mix UNIX, VMS, and AS/400 systems with Windows NT. These sites frequently request help in administering NT networks remotely from UNIX or AS/400 systems. The site administrators typically control or manage remote systems with Telnet sessions, applications that run on X terminals, mechanisms such as NIS/NIS+, or tools such as Network Shell. Although NT provides excellent management mechanisms through administration tools and wizards, the Microsoft Management Console (MMC), and the NT domain structure, these approaches work seamlessly only if you have a homogeneous NT network. In addition, most of the Microsoft documentation seems to focus on managing networked PCs.

So what can you do remotely—for example, from a Telnet session—on an NT computer from a UNIX or an AS/400 system if you don't want to load extra software on your UNIX and AS/400 machines? What can you do remotely with a regular TCP/IP connection and normal TCP/IP-based services such as remote procedure call (RPC), Telnet, or the r-command utilities? Can you run any useful commands remotely? Microsoft designed NT to be a single-user multitasking system, so can you perform remotely on NT the kinds of operations that are common on a UNIX or AS/400 machine? The answer to all these questions is anything that you can do remotely on UNIX and OS/400 from a UNIX or an AS/400 system you can also do on NT. Installing third-party software on UNIX or AS/400 systems is not necessary. NT's support for standard protocols lets you accomplish a comprehensive set of administrative tasks on NT systems remotely from other OSs.

In this article, we examine the types of NT tasks that you can administer remotely from non-Windows systems using a variety of methods, none of which require you to install software on your non-Windows systems. We describe how to use Telnet Server on NT and Net commands, the Remote Shell service from the Web Administrator for NT Server 4.0, and the third-party Network Shell tool.

Remote Administration Through Telnet
The first step in remotely managing an NT computer through Telnet is to install the Telnet daemon (Telnet Server) on an NT server. UNIX and AS/400 systems typically contain the Telnet client. You can install the version of Telnet Server that the Microsoft Windows NT Server 4.0 Resource Kit includes or the version that the Windows NT Services for UNIX Add-On Pack includes. Third-party Telnet daemons (e.g., InterAccess TelnetD 4.0 for Windows NT from Pragma Systems, http://www.pragmasys.com; SLnet 2.5 from Seattle Lab, http://www1.seattlelab.com/ slnet; and Ataman TCP Remote Logon Services from Ataman Software, http://www.ataman.com/ products.html#atrls) provide additional functionality, including better logging facilities and a more complete implementation of the Telnet protocol.

Let's begin by looking at what you can do with Telnet Server, and at the advantages and disadvantages of using Telnet to remotely administer NT. The ability to start and stop commands from a Telnet client on a UNIX or an AS/400 computer is helpful when you have a few NT servers in a predominantly UNIX environment. This solution precludes the necessity to install software on UNIX or AS/400 computers. Unfortunately, however, because you're using Telnet, you must accept the security vulnerabilities associated with Telnet (e.g., anyone with a protocol analyzer on your network can capture the usernames and passwords that transmit in the Telnet session).

The documentation that comes with the resource kit clearly describes the straightforward Telnet Server installation process. To install Telnet Server, log on to the NT server with administrator or server operator privileges, and select the Services tab in the Control Panel Network applet. Add a new service, but instead of selecting from the list of default services, click Have Disk. By default, NT will assign drive letter A to the disk. However, if you've installed the resource kit on another drive (e.g., the F drive), enter

F:treskittelnet 

at the prompt. Alternatively, you can copy the following files from the resource kit and keep them on a 3.5" disk: rsmsvc.exe, telnetd.exe, oemsetup.inf, and rsmlogin.cmd. Whether you choose to assign a drive or copy the files to a 3.5" disk, after you enter the path containing the files and click OK, you'll see the Select OEM Option dialog box, which Screen 1 shows.

If you do not see both Remote Session Manager and Telnetd Service Beta (Inbound Telnet) in the dialog box, you need an updated version of the oemsetup.inf file. You can download an updated file from ftp://ftp.microsoft.com/ bussys/winnt/winnt-public/ reskit/nt40/telnetd.

Click OK to install Remote Session Manager, then click OK to install the Telnetd service. Reboot after installing the Telnetd service.

If you want your Telnet users to run a login script, consider modifying the rsmlogin.cmd procedure. The rsmlogin.cmd file is the default global login script and has the following relevant commands:

cd %homedrive%%homepath% /d if exist %homepath%rsmlogin.cmd call %homepath%rsmlogin.cmd

If you're used to UNIX or AS/400 systems, notice the /d flag in the cd command. The /d flag lets you change the drive as well as the directory; %homedrive% and %homepath% are the drive and directory path, respectively. Also note that NT supports filenames with embedded spaces. For example, you can type

cd E:Program Files /d

to change the drive and directory path to E:Program Files from a different drive and directory.

When you enable command extensions, you can (among other things) run scripts with For loops and enable conditional processing. To see a complete list of the commands you can run on Telnet sessions, type

Help

after you're logged on to the NT system through the Telnet session. Although the MS-DOS command language in NT is not as rich as the various shells in UNIX environments, after you enable the command extensions, the old batch command language does have some real power. By default, NT enables command extensions and sets the extensions via the EnableExtensions (type REG_DWORD, value 1) Registry entry in HKEY_CURRENT_USER SoftwareMicrosoft Command Processor.

You can remotely enable and disable command extensions by using cmd /x and cmd /y, respectively. You can run any of the commands as if you are at the MS-DOS command prompt. For example, you can check the services running on an NT computer and start or stop any of them from a Telnet client running on a UNIX computer. You can also run commands such as Chkdsk and Tree. Figure 1 shows a Telnet session in which the administrator starts various NT services on an NT server from a UNIX computer.

Using Net Commands in Telnet Sessions
Table 1 lists the Net commands that you can invoke from the command line. You can run these commands through Telnet sessions from any computer. Let's look at each of the commands from Table 1 in more detail.

Net User. You can use the Net User command in several ways: to modify an existing user's properties, to add a new user, and to delete an existing user. Figure 2, page 106, shows Net User syntax and command output.

Net Accounts. You can use Net Accounts to set up many account policies, including forced logoff after account hours expire, minimum password length, maximum password age, minimum password age, and the number of passwords a user's password history can contain. In addition, Net Accounts provides options that are not directly available through the User Manager for Domains GUI.

For example, using the Forcelogoff option, you can send a warning message at a time interval you specify to users who must log off the domain. If you specify /forcelogoff:5, for example, NT sends a warning message to the specified user 5 minutes before the user must log off.

The Net Accounts Sync option seems to be the only way you can force the entire user account database to copy from the PDC to all the BDCs. This command will force a full synchronization; that is, all the user and group accounts will copy from the PDC to the BDCs. In contrast, the Synchronize Entire Domain command in Server Manager doesn't copy the entire security database.

The syntax of the Net Accounts command is

net accounts [/forcelogoff:{minutes | no}][/minpwlen:length][/maxpwage:{days | unlimited}] [/minpwage:days][/uniquepw:number] [/domain]net accounts [/sync]

Net Group. You have three options for specifying the Net Group command. The syntax that will bring up a list of group names is

net group [groupname [/comment:"text"]] [/domain]

The syntax for the option that lets you add or delete a global group is

net group groupname {/add [/comment:"text"] | /delete}  [/domain]

The syntax that lets you add new users or delete existing users from a global group is

net group groupname username [...] {/add | /delete} [/domain]

In the syntax for all three Net Group options, you must enclose in quotation marks any names (e.g., domain admins) that contain spaces.

Net Localgroup. The Net Localgroup command lists, adds, deletes, and modifies local groups on local workstations and servers and on domain controllers. The syntax

net localgroup [groupname [/comment:"text"]] [/domain] 

lists the groups or adds the text comments to the local group. The syntax

net localgroup groupname {/add [/comment:"text"] | /delete}  [/domain] 

adds a new local group or deletes an existing local group. Finally, the syntax

net localgroup groupname name [...] {/add | /delete} [/domain]

adds or deletes specific users from the local group.

Using Tools from the Resource Kit
If an NT server has the resource kit installed, you can use many of the tools and command-line utilities that the resource kit provides at the Telnet prompt from a UNIX or an AS/400 workstation. When you use any of the resource kit tools through a Telnet session from a UNIX or an AS/400 computer, the tools are really running locally on an NT computer. Thus, you can use the tools to manage an NT server remotely from a UNIX system. One benefit of doing so is you don't need to add more tools to your UNIX system. The resource kit includes many useful NT and Windows 9x systems administration tools that you might expect to be part of the OS. Microsoft updates these tools and utilities frequently, and you might find that subscribing to TechNet is the easiest way to get the latest version of the resource kit. Table 2, page 108, lists all the command-line utilities from the resource kit that you can administer remotely.

Using the Remote Shell Service
One alternative to using Telnet for remote administration is to use the Remote Shell service, which lets you use commands such as Rsh to remotely administer NT from non-Windows OSs. You'll find the Remote Shell service only in the resource kit; NT includes the Rsh client. When you use Rsh, you can execute batch commands or any of the commands that Tables 1 and 2 list.

Unfortunately, we've encountered too many problems with the Remote Shell service to recommend it with confidence. In addition to standard security concerns associated with using r-command utilities, the Remote Shell service doesn't seem to check usernames when it allows access. If the service doesn't check usernames, any user can run commands on the server. Also, TechNet articles refer to problems with memory leaks in the Remote Shell service, the only solution to which is to stop and restart the service periodically. Nevertheless, the Remote Shell service can be a useful tool when you want to perform a series of tasks on multiple NT servers without having to log on to each server individually.

If you want to try using the Remote Shell service to run r-command utilities remotely, here is the step-by-step procedure for doing so.

  1. Install the Remote Shell service on the NT computer you want to administer remotely. Copy rshsetup.exe, rshsvc.exe, and rshsvc.dll from the resource kit to the system32 folder (typically at C:winntsystem32). Change the current directory to the system32 folder using the command

    cd %systemroot%system32

    then execute the rshsetup.exe file as follows:

    C:winntsystem32>rshsetup %systemroot%system32rshsvc.exe %systemroot%system32rshsvc.dll

    Upon successful installation, you'll receive a message similar to RshSvc created with path C:winntsystem32rshsvc.exe.

  2. Now you can start or stop the Remote Shell service using Net Start Rshsvc and Net Stop Rshsvc, respectively.

  3. NT requires you to create an .rhosts file and place the file in the %systemroot%system32driversetc folder. This file is a text file with the names of computers and users who can use Rsh from their systems. In the following example, we use Rsh from a UNIX computer (corba1.foretell.ca), and the Remote Shell service is running on an NT server erver1.foretell.ca). Within the .rhosts file, the syntax to allow user accounts vsankar and ssankar from computers corba1.foretell.ca and corba2.foretell.ca is

    corba1 vsankar ssankarcorba2 vsankar ssankar

Make sure to press Enter after typing in each line: A carriage-return, linefeed character is necessary at the end of each line.

You can now execute commands such as

rsh server1.foretell.ca net start 

from a UNIX system to start services on the NT machine. You can also run batch files and most of the commands and utilities that Tables 1 and 2 list.

Using Web Administrator for NT Server
Web Administrator 2.0 for NT Server 4.0 is a tool that lets you administer NT 4.0 servers from any browser that supports basic NT authentication. Microsoft designed Web Administrator for standard administration tasks related to managing users and computers. Web Administrator lets you manage user accounts, configure remote access permissions, manage shares and printers, control sessions, and manage a server computer (e.g., reboot, start and stop services, view events).

If you want to use Web Administrator, you must have Microsoft Internet Information Server (IIS) 4.0 installed on the NT computer you want to administer remotely. Because of this requirement, you might not be able to use Web Administrator on all your application servers. Because you will be using IIS, make sure to handle authentication using NT challenge/response or certificates with Secure Sockets Layer (SSL) 3.0. If you're not too worried about security, you can use Web Administrator without any additional security configuration. You can download a copy of Web Administrator 2.0 from Microsoft at http://www.microsoft.com/ ntserver/all/downloads.asp.

Using Third-Party Tools
If you're a typical systems administrator, you might scoff at performing remote administration with third-party tools, but at least one such tool merits consideration. Network Shell, from Shpink Software (http://www.shpink.com) runs on Windows and UNIX platforms, and you can use this tool to manage Windows and UNIX systems simultaneously through shell scripts. Network Shell doesn't require the use of the r-command utilities or individual Telnet sessions.

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like