If an unknown protocol is used when you set the protocol type, authsrv lists the available authentication protocols. In this instance, the only options available are none and password. After the authentication protocol is set, the user chris is enabled. At this point, the user chris can authenticate him- or herself using the authentication server.

Before you give the user free rein, however, establish for this user the wizard for group administrator privileges, and superwiz, which grants global administrator privileges. Normally this wouldn’t be done because global administrative privileges supersede the privileges of the group administrator.

authsrv# wiz chrish
set group-wizard
authsrv# superwiz chrish
set wizard

With these additional privileges set, you can list the information from the authsrv database using the list command.

authsrv# list
Report for users in database
user       group      longname      status proto      last
----       -----      --------      ------ -----      ----
chrish     production Chris Hare      y G  passw      never
authsrv#

This output shows the username, the group that the user belongs to, the long name, the status flags, authentication protocol, and when the user last authenticated. The status field includes the following information:

The list command displays information for all the users; the display command shows more information for a given user.

authsrv# display chrish
Report for user chrish, group production (Chris Hare)
Authentication protocol: password
Flags: WIZARD GROUP-WIZARD
authsrv#

As you can see, this command provides information similar to the list command, but includes a text explanation of the flags set for this user.

As many users as needed can be added in this manner, although you can see that this is a tedious job for even a small organization.

The Authentication Shell—authmgr

The authsrv command enables a local user access to the firewall host to manipulate the database; the authmgr program also allows users to manipulate the database such access, but from a trusted host on the network or through the local host. Unlike the authsrv command, the authmgr program requires that the user log in to authenticate him- or herself to the database. If the user is not enabled or in the database, the connection is refused. Here is a short authmgr session.

pc# ./authmgr
Connected to server
authmgr-> login
Username: admin
Password:
Logged in
authmgr-> list
Report for users in database
user       group      longname   status  proto   last
----       -----      --------   ------  -----   ----
paulp      copy                    n G   passw   never
chrish     production Chris Hare   y W   passw   never
admin      manager    Auth DBA     y W   passw   Fri Oct 27 23:47:04 1995
authmgr-> quit
pc#

All the commands and functionality that are part of the authsrv command are also part of authmgr. This may be apparent, but keep in mind that the authmgr command actually established a TCP session to the authsrv program.

Database Management

Two more commands are available for manipulating the authentication database: authload and authdump. The authload command manipulates individual records in the database; it does not truncate an existing database. It is useful when you need to add a bunch of new entries to the database, or when you need to share databases between sites. If you have users who share similar information between sites, the existing records will be overwritten with newer information when this information is loaded by the authload command.

The authdump command creates an ASCII backup copy of the information in the database. This ASCII copy contains all the information regarding the user account. The passwords however, are encrypted, so that they cannot be read and used to circumvent the security provided by the Toolkit.

The authdump command reads the contents of the authentication database and writes the ASCII text. A sample execution of the command is here:

pc# ./authdump

user=chrish
longname=Chris Hare
group=production
pass=cY8IDuONJDQRA
flags=2
bad_count=0
proto=p
last=0

user=admin
longname=Auth DBA
group=manager
pass=tx6mxx/lUy2Mw
flags=2

If the command is executed and the output is redirected to a file, the program prints a dot for each record dumped, along with a report of the total records processed:

pc# ./authdump > /tmp/auth
…
3 records dumped
pc#

If you have this information stored somewhere else in a human-readable form (except for the passwords), you can re-create the user database if the firewall ever needs to be rebuilt.

The authload program can take the output of the authdump program and reload the database. The authload command is valuable if the user database was destroyed, or you have a large number of users to add at once. In this manner, new records can be added to the ASCII file and only the new records will be loaded into the authentication database. Consider the new entry added to this ASCII dump file:

user=terrih
longname=Terri Hare
group=production
pass=
flags=0
bad_count=0
proto=p
last=

Now you can load the records into the database, using input redirection because the information is in the ASCII dump file:

pc# ./authload > /tmp/auth
....
4 records loaded
pc#

This results in a report showing the number of records that have been loaded. You can then verify the status of the additional records using the authmgr “list” command:

pc# ./authmgr
Connected to server
authmgr-> login
Username: admin
Password:
Logged in
authmgr-> list
Report for users in database
user       group      longname    status proto    last
----       -----      --------    ------ -----    ----
paulp      copy                     n G  passw    never
terrih     production Terri Hare    y    passw    never
chrish     production Chris Hare    y W  passw    never
admin      manager    Auth DBA      y W  passw    Sat Oct 28 01:45:32 1995
authmgr->