Administering REXEC

Overview of REXEC administration

Although REXEC is independent of other network applications, it uses components of the Network Application Architecture (NAA), specifically ID mapping and the Service Access Facility (SAF) on the server side, the connection server on the client side, and the Identification and Authentication Facility (IAF) scheme on both the server and client. The client also uses name-to-address mapping.

This section describes the components of the NAA that need to be administered before you set up REXEC. An overview of the steps that are specifically part of REXEC administration is then given.

Prior to setting up REXEC on the server, you must:

Install an authentication scheme.
Set up ID mapping.
Set up the connection server.

The authentication scheme, cr1, will be used to protect the REXEC service from unauthorized remote access. Setting up the authentication scheme will include the use of the cr1 administrative commands to control the key management daemon and to administer the key database.

Using the ID mapping facility, map the logins of users on a client to logins on the server. Before client logins can be mapped, the server logins to which client logins will be mapped must exist on the server system with valid entries in the server's /etc/passwd file. When this is done, use the ID mapping administrative commands with a cr1 mapping scheme specification to complete the set up of the facility.

NOTE: Currently, cr1 is the only authentication provided with UnixWare 7 that uses ID mapping. cr1 administration involves setting up and maintaining the cr1 key database, as described in ``cr1 Bilateral Authentication Scheme''.

Setting up the connection server on the server includes the installation of the reportscheme service for each port monitor being used to offer the REXEC service.

Before you use REXEC from a client, you must do the following:

Set up a host address database.
Install the same authentication scheme used on the server to protect REXEC.
Set up the connection server.

How you set up a host address database depends on your network. Host addresses are stored in any of several databases, depending on the type of network connection the client has to the server. If a client can reach a server over a TCP/IP transport, for example, then that client should have the server's name and address in its /etc/hosts file. See ``Administering name-to-address mapping'' for information about setting up a host address database for your network.

Setting up the authentication scheme on the client includes the use of the cr1 administration command cryptkey to specify the key to be shared between the server and the client.

Setting up the connection server on the client will include the specification of the authentication scheme to be used. For example, cr1 needs to be specified in /etc/iaf/serve.allow. This will help ensure enforcement of bilateral authentication.

Instructions for setting up and administering name-to-address mapping, the cr1 Bilateral Authentication Scheme, ID mapping, and the connection server appear in ``Administering name-to-address mapping'', ``cr1 Bilateral Authentication Scheme'', ``Administering ID mapping'', and ``Administering the connection server'' respectively, and should be consulted for more details.

Once you've set up the network services on which REXEC depends, you're ready to set up REXEC itself. Administering the REXEC facility on a server involves the following tasks:

Registering REXEC with a port monitor under the SAF.
Maintaining a database of services available for remote execution through REXEC.

Administering REXEC on a client is just a matter of installing the REXEC software. However, the client administrator may choose to create links from REXEC services to the REXEC command interface to improve the ease with which local users can execute remote services.