HostedDB - Dedicated UNIX Servers

-->
Internet Security Professional Reference:How to Build a Firewall
Previous Table of Contents Next


Manual Reference Pages

The following manual pages are taken from the TIS Toolkit and modified to fit within the formatting of this book. Many sections that have been empty were omitted, and should not be construed to replace the actual manual pages included with the Toolkit. The sections not generally included are BUGS, SEE ALSO, and FILES.

These manual pages have been formatted to make reading and referencing them easier. Each manual page includes the following sections:

  Synopsis
  Description
  Options
  Installation

Command-specific sections are also included. While setting up and configuring your firewall, this section will prove to be an invaluable aid.

Authmgr—Network Authentication Client Program

Synopsis

authmgr

Description

authmgr is a client-side interface to the authentication daemon authsrv. authmgr is useful if an administrator wants to access the authentication server over a network, or wants to encrypt the connection. The authmgr program passes most of its commands directly over a network to authsrv. All commands supported by authsrv are supported by authmgr with the same syntax; authmgr also accepts the login [username] command, which automates authentication to authsrv.

Options

authmgr takes no command-line options, reading its configuration information from the firewall Toolkit configuration file netperm-table. All configuration rules in netperm-table for application “authmgr” are read, and the following clauses and parameters are recognized:

authserver hostname [port] [key]

This command specifies the hostname or network address where the authentication server is running. If the optional port is specified, it is used as a numeric service port value. If the optional key is specified, all traffic with the server is DES-encrypted using the shared key. Keys must match between client and server.

If compiled-in values for authserver and port are provided, they will be used as a default if there are none specified in netperm-table.

Installation

To install authmgr, configure the authserver option in netperm-table to contain the address of the authentication server system. Check connectivity by attempting to log in.

authsrv—Network Authentication Third Party Daemon

Synopsis

authsrv via inetd

Description

authsrv functions as a simple third party authentication server, and provides an integrated interface for multiple forms of authentication, such as passwords, one-time passwords, and token authentication systems. authsrv maintains a database of user and group records with a simple administrative interface that permits an authenticated administrator to manage user records locally or over a network. authsrv maintains extensive logs of transactions, authentication failures and successes, and all changes to its database. authsrv also can be configured to perform basic security operations such as disabling user accounts automatically when there are more than a set number of failed login attempts.

Many commercial products for authentication include their own programming interface; for this reason, the simultaneous support of multiple forms of authentication within a single piece of software is cumbersome. authsrv multiplexes authentication schemes and uses a simple protocol with the client software, permitting administrators to add or drop authentication schemes easily without the need to modify client code. Currently authsrv contains support for Digital Pathways Secure Net Key, Security Dynamics SecurID, Bellcore S/Key, and plaintext passwords.

authsrv’s basic authentication protocol uses ASCII text, with newline indicating the end of a line. When a client connects to the authentication server, it issues a request to authenticate a user:

authorize userID

authenticate userID

To which the server will respond with one of two options:

password

challenge challengestring

The client program should prompt the user for a (non-echoing) password if it receives the “password” response, or it should prompt the user with the returned challenge string if it receives the “challenge” response. The client program should forward the user’s password or challenge response to which the server will either respond “OK” or respond with an arbitrary text string that should be returned to the user. The client program forwards the response in the form of:

response responsestring

In some cases, the server may respond with “OK” followed by additional text on the same line. Additional text may contain information of interest to the user (such as, “OK. Change your password soon”).

authsrv can also be invoked from the terminal directly for administrative purposes. If it is invoked from a terminal with the current user-id being 0 (“root”) it will automatically grant administrative privileges to the session. This is based on the pragmatic realization that if someone has system privileges on the host serving the authentication database, they already effectively have administrative privileges.

Generally, authsrv is designed to run on a secured system that is relatively restricted to users. In a firewall environment, the firewall host itself is a good candidate for running authsrv because typically the bastion host is secured, and is where the client software that uses authsrv is running. To ease administration, authsrv can be managed remotely using a client program with optional DES-encrypted communications between the client and server.

Groups and Users

authsrv supports a group and user configuration. Each user may be assigned to a group, consisting of a short arbitrary string name. Two levels of permissions are used in authsrv: administrator and group administrator. A group administrator can create, enable, disable, and delete users from that group, but may not create additional group administrators or groups. The overall system administrator can create new groups (by simply assigning someone to a group that previously did not exist) and can hand out group administration privileges. This setup provides a flexible management environment—a variety of management schemes can be implemented. To implement a monolithic management scheme, simply create several administrators and have them manage the database. To implement a hierarchical management scheme, create several group administrators and let each manage a group separately. Another setup can be used that eliminates the administrator user-id. All operations can be performed at a group level, and new groups can be created by running authsrv in administrator mode on the system where the database resides.


Previous Table of Contents Next