Browse Prior Art Database

Remote System Administration through a firewall or on a Private Network Disclosure Number: IPCOM000030881D
Original Publication Date: 2004-Aug-31
Included in the Prior Art Database: 2004-Aug-31
Document File: 3 page(s) / 125K

Publishing Venue



Unix system administration is carried out directly on the machine to be administered. This is done through a network login or via an attached console/terminal. Administration is done by the 'root' (superuser) id, with some activities delegated via Unix groups, and others via the optional Open Source program 'sudo' (Super User DO). This new program allows for an individual to specify a machine and a command to be executed on the machine remotely. The key is that all attempts to modify the system are logged and the user never establishes a direct connection to the machine that is being administered. Without the requirement of a direct connection by the administrator, administration tasks can now be executed on machines that are either behind a firewall or on a private (non-routable) network.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 61% of the total text.

Page 1 of 3

Remote System Administration through a firewall or on a Private Network

This invention describes the concept of a 'gatekeeper' machine that acts as both an authentication agent and as a command router. The gatekeeper is a dual homed device (sits on two distinct networks) straddling either a production domain and a firewalled domain, or any domain and a private, non-routable network (example: 192.168.x.x), and supports no local user ids beyond that of the system administrator (root). This gatekeeper accepts connections from anywhere on one production domain, using a specified port and then validates that the user/machine combination is allowed to issue commands. If the user isn't allowed, then the user/machine pair is logged to an error file - otherwise the next check is done. The request is then checked to see if the user issuing the command can access the machine specified AND is allowed to execute the command. If those things are all true, then the tuple of user, machine, target, command are logged and the command is forwarded to the target machine for execution. All validations are done via a database (described below). Execution of the command is then logged on the target, and all output is routed back to the gatekeeper, and then back to the requesting user/machine. It is important to note that interactive commands like 'vi'ing a file can also be run via this mechanism.

Alternative solutions that have been attempted usually include remote access to the machine - via telnet, rsh, rlogin, ssh, or other login capacity. One tool that has been utilized to control who can execute what administrative command is called sudo and information on it can be found at: This is the most commonly used way to split system administration tasks among many admins, but still requires that a) the configuration file be local to each machine being administered; b) local user login - as authentication is done via the encrypted password stored on the system.

Unix vendors have attempted to solve the remote administration problem using Graphical User Interfaces (GUIs), but SCOAdmin (UnixWare admin tool), SAM (HPUX admin tool), and others that support the capability assume a homogeneous and the ability to directly connect to the remote machine.

The Authentication database:

Unix file system directory hierarchy is used for validation. All kdsudo authorizations can be found in: /var/adm/kdadmin/authorizations/<userid>/<host>/<target>/ with the commands stored as text files and options stored within the file.


















Page 2 of 3

Example: userid is jerry, hostname is, target is, command is "ls -l"

Validation would occur aga...