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 adminis- trators 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.
Options
authsrv takes no command-line options, reading its configuration information from the firewall Toolkit configuration file netperm-table(5). All configuration rules in netperm-table for application “authsrv” are read, and the following clauses and parameters are recognized: database pathname
This command specifies the pathname of the authsrv database. The database is stored as a dbm(3) file with a third file used for locking. If the software is built with a compiled-in database name, this option need not be set, otherwise it is mandatory.
The following command indicates that authsrv should return “user-friendly” error messages when users attempt to authenticate and fail:
nobogus true
The default message is simply to respond, “Permission Denied,” or to return a bogus challenge. If nobogus is set, attempts to log in will return more explicit error messages. Site administra- tors concerned about attempts to probe the authentication server should leave this option disabled.
The following command establishes a “sleep time” for repeated bad logins: badsleep seconds
If a user attempts to authenticate five times and fails, their user record is marked as suspicious, and they cannot log in again. If the badsleep value is set, the user may attempt to log in again after that many seconds has expired. If the badsleep value is 0, users may attempt (and fail) to log in as many times as they would like. The default value is to effectively disable the account until an administrator re-enables it manually.
To specify the userid that authsrv should run under, use a name from the password database, or a numeric userid in the command:
userid name
To specify that authsrv should permit the named host or addresses to use the service, add this command:
hosts host-pattern [key]
Hosts that do not have a matching entry are denied use of the service. If the optional key is specified, and the software is compiled with DES-encrypted communications, all traffic with that client will be encrypted and decrypted with the specified key.
Commands
The following command implements the first part of the authentication sequence: authorize username
If the authorize command is issued after a user has already authenticated to the authentication server, their current authentication is cleared.
To implement the second part of the authentication sequence, the following command is used. This is returned in response to a password or challenge query from the authentication server: response <text>
To disconnect from the authentication server, issue: quit or exit
To display the status, authentication protocol, and last login of the specified user, issue the command:
display username
Before the authentication server permits the use of this command, the user must first be authenticated to the server as the administrator, or the group administrator of the group to which the user belongs.
To add a user to the authentication database, enter the command: adduser username [longname]
Before the authentication server permits the use of this command, the user must first be authenticated to the server as the administrator or as a group administrator. If the user is a group administrator, the newly created user is automatically initialized as a member of that group. When a user is added, he or she is initially disabled. If a long name is provided, it will be stored in the database. Long names should be quoted if they contain white space, as in this example:
adduser mjr “Marcus J. Ranum”
To delete the specified user from the authentication database, use the command: deluser username
Before this command can be used, the user must first be authenticated to the server as the administrator or group administrator of the group to which the user being deleted belongs. The following commands enable and disable the specified user’s account for login:
enable username
disable username
Before this command can be used, the user must first be authenticated to the server as the administrator or group administrator of the group to which the user being enabled or disabled belongs.
To set the password for the current user, issue: password [username] text
If an optional username is given and the authenticated user is the administrator or group administrator, the password for the specified user is changed. The password command is polymorphic depending on the user’s specified authentication protocol. For example, if the user’s authentication protocol is plaintext passwords, the command will update the plaintext password. If the authentication protocol is SecurID with PINs, it will update the PIN. The following command sets the authentication protocol for the specified user to the named protocol:
proto user protoname
Available protocols depend on the compiled-in support within authsrv. To change a user’s authentication protocol, the user must be authenticated to the server either as the administra- tor or group administrator of the user’s group. To set the specified user’s group, use the command:
To use this command, a user must first be authenticated to the server as the administrator. Group administrators do not have the power to “adopt” members.
The following commands set and unset the group administrator flag on the specified user. To issue this command, a user must be authenticated to the server as the administrator.
wiz user
unwiz user
This command sets the specified user as a global administrator: superwiz user
The superwiz command should be used with caution. Usually the group mechanism is powerful enough for most system maintenance. For this reason, global administrative privileges are seldom used.
To list all users that are known to the system, or the members of the specified group, use the command:
list [group]
Group administrators may list their own groups, but not the entire database. The list displays several fields, including:
■ user. The login ID of the user.
■ group. The group membership of the user. If none is listed, the user is in no group. ■ longname. The user’s full name. This may be left blank.
■ status. Contains codes indicating the user’s status. If this field is marked “y” the user is enabled and may log in. If marked “n” the user’s login is disabled. If marked “b” the users login is temporarily disabled because of too many bad login attempts. Users flagged with a “W” have the administrator bit set; users flagged with a “G” have the group administrator bit set.
■ proto. Indicates the form of authentication in use for the login.
■ last. Indicates the time of the last successful or unsuccessful login attempt. To list a short synopsis of available commands, use this command:
? or help
To determine if the named user is allowed to perform the specified service, use the command: operation user username service dest [other tokens] [time low# high#]
The service might be any one of the application gateway such as telnet-gw, ftp-gw, or rlogin- gw. The destination is any valid IP domain. The optional tokens are matched as wildcards to permit a proxy to specify more detailed operations. If a matching rule is found, the appropriate response is returned to the client. If no match is found, a message indicating that no match was found is returned to the client program. Here is an example:
operation user mjr telnet-gw relay.tis.com operation user mjr ftp-gw relay.tis.com ➥put
Operation rules are stored in netperm-table. For each user/group the name is specified followed by the service destination [optional tokens] [time start end]. The user/group field indicates whether the record is for a user or a group. The name is either the username or the group name. The service can be any service specified by the proxy (usually ftp-gw, tn-gw, or rlogin-gw); the destination can be any valid domain name. The optional tokens are checked for a match, permitting a proxy to send a specific operation check to the authentication server. The time field is optional and must be specified time start_time end_time. The start_time and end_time parameters can be in the range 00:00 to 23:59. Here are a string of commands that specify who can use a service and when:
authsrv permit-operation user mjr telnet-gw relay.tis.com time 08:00 17:00 authsrv deny-operation user mjr telnet-gw relay.tis.com time 17:01 07:59 authsrv permit-operation group admin telnet-gw * time 08:00 17:00 authsrv deny-operation user mjr telnet-gw relay.tis.com time 17:01 07:59 authsrv permit-operation group admin telnet-gw *.com
authsrv deny-operation group admin ftp-gw *.com put time 00:00 23:59
Installation
To install authsrv, configure the database option in netperm-table and initialize the database. To initialize the database, use the command su to go to the root directory, run authsrv at the command line, then issue the following commands:
#
# authsrv
-administrator mode- authsrv# list
Report for users in database
user group longname ok? proto last ---- --- --- --- --- ---- authsrv# adduser admin ‘Auth DBA’
ok - user added initially disabled authsrv# ena admin
enabled
authsrv# proto admin Snk changed
authsrv# pass ‘160 270 203 065 022 034 232 162’ admin Secret key changed
Report for users in database
user group longname ok? proto last ---- --- --- --- --- ---- admin Auth DBA ena Snk never authsrv# quit
#
In this example, the administrator account is established, then enabled, a protocol is assigned, and the initial password is set. The format of the set password depends on the authentication protocol used for the record. In this example, the administrator record is using a SecureNet Key, so the password record consists of the shared secret key used by the device.
After the database is initialized, add necessary hosts entries to netperm-table, install authsrv in inetd.conf, then restart inetd. Verify that authsrv is running by telnetting to the service port.
Note Ensure that the database is protected against casual perusal by checking its file
permissions.