Nancy L. Gilman's changes for Beta 4

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@3778 dc483132-0cff-0310-8789-dd5450dbe970

7 files changed, 284 insertions, 190 deletions

diff --git a/src/appl/bsd/krlogind.M b/src/appl/bsd/krlogind.M
index 4ceebd773..9d6916c5d 100644
--- a/src/appl/bsd/krlogind.M
+++ b/src/appl/bsd/krlogind.M
@@ -4,67 +4,86 @@
 .\"
 .\"	@(#)rlogind.8c	6.3 (Berkeley) 5/24/86
 .\"
-.TH RLOGIND 8C "May 24, 1986"
-.UC 5
+.TH KRLOGIND 8C "Kerberos Version 5.0" "MIT Project Athena"
 .SH NAME
-rlogind \- remote login server
+krlogind \- remote login server
 .SH SYNOPSIS
 .B /etc/rlogind
 [
-.B \-d
+.B \-kKrRpPex
 ]
 .SH DESCRIPTION
-.I Rlogind
+.I Krlogind
 is the server for the 
 .IR rlogin (1C)
-program.  The server provides a remote login facility
-with authentication based on privileged port numbers from trusted hosts.
+program.  The server is 
+based on rlogind(8C) but uses kerberos authentication.
 .PP
-.I Rlogind
-listens for service requests at the port indicated in
-the ``login'' service specification; see
-.IR services (5).
-When a service request is received the following protocol
-is initiated:
+The 
+.I krlogind
+server is invoked by \fIinetd(8c)\fP when it receives a
+connection on the port indicated in /etc/inetd.conf.  A typical
+/etc/inetd.conf configuration line for \fIkrlogind\fP might be:
+
+klogin	stream	tcp	nowait	root	/krb5/sbin/krlogind krlogind -K
+
+When a service request is received, the follow protocol is initiated:
+
 .IP 1)
-The server checks the client's source port.
-If the port is not in the range 0-1023, the server
-aborts the connection.
+Check authentication.
 .IP 2)
-The server checks the client's source address
-and requests the corresponding host name (see
-.IR gethostbyaddr (3N),
-.IR hosts (5)
-and
-.IR named (8)).
-If the hostname cannot be determined,
-the dot-notation representation of the host address is used.
+Check authorization via the access-control files \fI.k5login\fP 
+and \fI.rhosts\fP in the user's home directory.
+.IP 3)
+Prompt for password if any checks fail.
 .PP
-Once the source port and address have been checked, 
-.I rlogind
-allocates a pseudo terminal (see 
-.IR pty (4)),
-and manipulates file descriptors so that the slave
-half of the pseudo terminal becomes the 
-.B stdin ,
-.B stdout ,
-and
-.B stderr 
-for a login process.
-The login process is an instance of the
-.IR login (1)
-program, invoked with the
-.B \-r
-option.  The login process then proceeds with the authentication
-process as described in
-.IR rshd (8C),
-but if automatic authentication fails, it reprompts the user
-to login as one finds on a standard terminal line.
+If the authentication succeeds, login the user by calling the accompanying 
+login.krb5 or /bin/login, according to the definition of 
+DO_NOT_USE_K_LOGIN.  
+.PP 
+The configuration of \fIkrlogind\fP is done
+either by command-line arguments passed by
+inetd, or by the name of the daemon. If command-line arguments are
+present, they  take priority. The options are:
+.IP \fB\-k\fP 10
+Check authorization in ~/.k5login.
+
+.IP \fB\-K\fP
+Similar to \fb\-k\fP except that the authorization check must succeed
+inorder for the login to succeed.
+
+.IP \fB\-r\fP 
+Check authorization in ~/.rhosts.
+
+.IP \fB\-K\fP
+Similar to \fb\-r\fP except that the authorization check must succeed
+inorder for the login to succeed.
+
+.IP \fB\-p\fP 
+Prompt the user for a password.  If \fB-r\fP or \fB-k\fP
+is passed \fB-p\fP is necessary to allow password authentication.
+Otherwise, if all previous checks fail, login permission is denied
+
+.IP \fB\-P\fP
+Prompt the user for a password.  If the -P option is passed, then the
+password is verified in addition to all other checks.
+.IP \fB\-e\fP
+Create an encrypted session.
+.IP \fB\-x\fP
+Create an encrypted session.
+.PP
+If no command-line arguments are present, then the presence of the 
+letters kKrRpPex in the program-name before "logind" determine the 
+behaviour of the program exactly as with the command-line arguments.
+.PP
+If the ~/.rhosts check is to be used, then the program verifies that
+the client is connecting
+from a privileged port, before allowing login.
 .PP
 The parent of the login process manipulates the master side of
 the pseduo terminal, operating as an intermediary
 between the login process and the client instance of the
-.I rlogin
+.I rlogin(1C)
 program.  In normal operation, the packet protocol described
 in
 .IR pty (4)
@@ -91,12 +110,7 @@ by the server failed.
 .B ``/bin/sh: ...''
 .br
 The user's login shell could not be started.
+.SH SEE ALSO
+rlogind(8C), rlogin(1C)
 .SH BUGS
-The authentication procedure used here assumes the integrity
-of each client machine and the connecting medium.  This is
-insecure, but is useful in an ``open'' environment.
-.PP
-A facility to allow all data exchanges to be encrypted should be
-present.
-.PP
 A more extensible protocol should be used.
diff --git a/src/appl/bsd/krshd.M b/src/appl/bsd/krshd.M
index e02480dc1..fc5f801bc 100644
--- a/src/appl/bsd/krshd.M
+++ b/src/appl/bsd/krshd.M
@@ -4,14 +4,13 @@
 .\"
 .\"	@(#)rshd.8c	6.3 (Berkeley) 5/24/86
 .\"
-.TH RSHD 8C "May 24, 1986"
-.UC 5
+.TH KRSHD 8C "Kerberos Version 5.0" "MIT Project Athena"
 .SH NAME
-rshd \- remote shell server
+krshd \- kerberized remote shell server
 .SH SYNOPSIS
-.B /usr/etc/rshd
+.B /usr/etc/krshd -kKrR
 .SH DESCRIPTION
-.I Rshd
+.I Krshd
 is the server for the 
 .IR rcmd (3X)
 routine and, consequently, for the
@@ -19,88 +18,62 @@ routine and, consequently, for the
 program.  The server provides remote execution facilities
 with authentication based on privileged port numbers from trusted hosts.
 .PP
-.I Rshd
-listens for service requests at the port indicated in
-the ``cmd'' service specification; see
-.IR services (5).
-When a service request is received the following protocol
-is initiated:
-.IP 1)
-The server checks the client's source port.
-If the port is not in the range 0-1023, the server
-aborts the connection.
+The
+.I krshd
+server is invoked by \fIinetd(8c)\fP when it receives a connection
+on the port indicated in /etc/inetd.conf.  A typical /etc/inetd.conf
+configuration line for \fIkrshd\fP might be:
+
+kshell	stream	tcp	nowait	root	/krb5/sbin/krshd	krshd -K
+
+When a service request is received, the follow protocol is initiated:
+
+.IP 1) 
+Authentication is checked
 .IP 2)
-The server reads characters from the socket up
-to a null (`\e0') byte.  The resultant string is
-interpreted as an ASCII number, base 10.
+Authorization is checked via the access-control files \fI.k5login\fP 
+and \fI.rhosts\fP in the user's home directory.
 .IP 3)
-If the number received in step 1 is non-zero,
-it is interpreted as the port number of a secondary
-stream to be used for the 
-.BR stderr .
-A second connection is then created to the specified
-port on the client's machine.  The source port of this
-second connection is also in the range 0-1023.
-.IP 4)
-The server checks the client's source address
-and requests the corresponding host name (see
-.IR gethostbyaddr (3N),
-.IR hosts (5)
-and
-.IR named (8)).
-If the hostname cannot be determined,
-the dot-notation representation of the host address is used.
-.IP 5)
-A null terminated user name of at most 16 characters
-is retrieved on the initial socket.  This user name
-is interpreted as the user identity on the
-.BR client 's
-machine.
-.IP 6)
-A null terminated user name of at most 16 characters
-is retrieved on the initial socket.  This user name
-is interpreted as a user identity to use on the
-.BR server 's
-machine.
-.IP 7)
-A null terminated command to be passed to a
-shell is retrieved on the initial socket.  The length of
-the command is limited by the upper bound on the size of
-the system's argument list.  
-.IP 8)
-.I Rshd
-then validates the user according to the following steps.
-The local (server-end) user name is looked up in the password file
-and a
-.I chdir
-is performed to the user's home directory.  If either
-the lookup or 
-.I chdir
-fail, the connection is terminated.
-If the user is not the super-user, (user id 0), the file 
-.I /etc/hosts.equiv
-is consulted for a list of hosts considered ``equivalent''.
-If the client's host name is present in this file, the
-authentication is considered successful.  If the lookup
-fails, or the user is the super-user, then the file
-.I .rhosts
-in the home directory of the remote user is checked for
-the machine name and identity of the user on the client's
-machine.  If this lookup fails, the connection is terminated.
-.IP 9)
 A null byte is returned on the initial socket
 and the command line is passed to the normal login
 shell of the user.  The
 shell inherits the network connections established
 by
-.IR rshd .
+.IR krshd .
+
+\fIKrshd\fP can be configured either by command-line arguments passed
+by \fIinetd(8)\fP,  
+or by the name of the daemon. If command-line arguments are present, they 
+take priority.  The options are:
+
+.IP \fB\-k\fP 10
+Check authorization in ~/.k5login.
+
+.IP \fB\-K\fP
+Similar to \fb\-k\fP except that the authorization check must succeed
+inorder for the login to succeed.
+
+.IP \fB\-r\fP 
+Check authorization in ~/.rhosts.
+
+.IP \fB\-K\fP
+Similar to \fb\-r\fP except that the authorization check must succeed
+inorder for the login to succeed.
+
+.PP
+If no command-line arguments are present, then the presence of the 
+letters kKrR in the program-name before "shd" determine the 
+behaviour of the program exactly as with the command-line arguments.
+.PP
+If the \fB\-r\fP or \fB\-R\fP options are used, the client must
+connect from a privileged port.
 .SH DIAGNOSTICS
 Except for the last one listed below,
 all diagnostic messages
 are returned on the initial socket,
 after which any network connections are closed.
 An error is indicated by a leading byte with a value of
-1 (0 is returned in step 9 above upon successful completion
+1 (0 is returned in step 3 above upon successful completion
 of all the steps prior to the execution of the login shell).
 .PP
 .B ``locuser too long''
@@ -151,13 +124,9 @@ on the connection associated with the
 .BR stderr ,
 and is not preceded by a flag byte.
 .SH SEE ALSO
-rsh(1C),
+rshd(8C), rsh(1C),
 rcmd(3X)
 .SH BUGS
-The authentication procedure used here assumes the integrity
-of each client machine and the connecting medium.  This is
-insecure, but is useful in an ``open'' environment.
-.PP
 A facility to allow all data exchanges to be encrypted should be
 present.
 .PP
diff --git a/src/appl/bsd/rcp.M b/src/appl/bsd/rcp.M
index ed3f872ca..7e826f345 100644
--- a/src/appl/bsd/rcp.M
+++ b/src/appl/bsd/rcp.M
@@ -19,8 +19,7 @@
 .\"
 .\"	@(#)rcp.1	6.6 (Berkeley) 9/20/88
 .\"
-.TH RCP 1 "Kerberos Version 4.0" "MIT Project Athena"
-.UC 5
+.TH RCP 1 "Kerberos Version 5.0" "MIT Project Athena"
 .SH NAME
 rcp \- remote file copy
 .SH SYNOPSIS
@@ -89,8 +88,17 @@ so that the metacharacters are interpreted remotely.
 does not prompt for passwords; it uses Kerberos authentication when
 connecting to
 .IR rhost .
-Authorization is as described in 
-.IR rlogin (1).
+Each user may have a private authorization list in a file \&.k5login
+in his login directory.  Each line in this file should contain a
+Kerberos principal name of the form 
+.IR principal/instance@realm .
+If there is a ~/.k5login file, then access is granted to the account if
+and only if the originater user is authenticated to one of the
+princiapls named in the ~/.k5login file.  Otherwise, the originating
+user will be granted access to the account if and only if the
+authenticated principal name of the user can be mapped to the local
+account name using the aname -> lname mapping rules (see \fIkrb5_anadd(8)\fP
+for more details).
 .PP
 The
 .B \-x
@@ -121,10 +129,6 @@ be a file in cases where only a directory should be legal.
 Is confused by any output generated by commands in a
 \&.login, \&.profile, or \&.cshrc file on the remote host.
 .PP
-The destination user and hostname may have to be specified as
-``rhost.rname'' when the destination machine is running the 4.2BSD
-version of \fIrcp\fP.
-.PP
 Kerberos is only used for the first connection of a third-party copy;
 the second connection uses the standard Berkeley rcp protocol.
 
diff --git a/src/appl/bsd/rlogin.M b/src/appl/bsd/rlogin.M
index c24ef85e0..eefde623d 100644
--- a/src/appl/bsd/rlogin.M
+++ b/src/appl/bsd/rlogin.M
@@ -19,8 +19,7 @@
 .\"
 .\"	@(#)rlogin.1	6.9 (Berkeley) 9/19/88
 .\"
-.TH RLOGIN 1 "Kerberos Version 4.0" "MIT Project Athena"
-.UC 5
+.TH RLOGIN 1 "Kerberos Version 5.0" "MIT Project Athena"
 .SH NAME
 rlogin \- remote login
 .SH SYNOPSIS
@@ -92,18 +91,20 @@ standard Berkeley rlogin(1), except that instead of the \fIrhosts\fP
 mechanism, it uses Kerberos authentication to determine the
 authorization to use a remote account.
 .PP
-Each user may have a private authorization list in a file \&.klogin
+Each user may have a private authorization list in a file \&.k5login
 in his login directory.  Each line in this file should contain a
 Kerberos principal name of the form 
-.IR principal.instance@realm .
+.IR principal/instance@realm .
 If the originating user is authenticated to one of the principals named
-in \&.klogin, access is granted to the account.  The principal
-\fIaccountname\fP.@\fIlocalrealm\fP is granted access if there is no
-\&.klogin file. 
+in \&.k5login, access is granted to the account.  If there is no
+/.k5login file, the principal will be granted access 
+to the account according to the aname\->lname mapping rules (see
+.IR krb5_anadd(8) 
+for more details) 
 Otherwise
 a login and password will be prompted for on the remote machine as in
 .IR login (1).
-To avoid some security problems, the \&.klogin file must be owned by
+To avoid some security problems, the \&.k5login file must be owned by
 the remote user.
 .PP
 If there is some problem in marshaling the Kerberos authentication
@@ -196,5 +197,7 @@ rsh(1), kerberos(3), krb_sendauth(3), krb_realmofhost(3),
 rlogin(1) [UCB version]
 .SH FILES
 /usr/hosts/*		for \fIrhost\fP version of the command
+.br
+\&.k5login		in the user's home directory
 .SH BUGS
 More of the environment should be propagated.
diff --git a/src/appl/bsd/rsh.M b/src/appl/bsd/rsh.M
index eda3328d4..b740729d5 100644
--- a/src/appl/bsd/rsh.M
+++ b/src/appl/bsd/rsh.M
@@ -19,8 +19,7 @@
 .\"
 .\"	@(#)rsh.1	6.2 (Berkeley) 9/20/88
 .\"
-.TH RSH 1 "Kerberos Version 4.0" "MIT Project Athena"
-.UC 5
+.TH RSH 1 "Kerberos Version 5.0" "MIT Project Athena"
 .SH NAME
 rsh \- remote shell
 .SH SYNOPSIS
@@ -64,8 +63,18 @@ The remote username used is the same as your local username,
 unless you specify a different remote name with the
 .B \-l
 option.
-Kerberos authentication is used, and authorization is determined as in
-rlogin(1).
+.PP
+Each user may have a private authorization list in a file \&.k5login
+in his login directory.  Each line in this file should contain a
+Kerberos principal name of the form 
+.IR principal/instance@realm .
+If there is a ~/.k5login file, then access is granted to the account if
+and only if the originater user is authenticated to one of the
+princiapls named in the ~/.k5login file.  Otherwise, the originating
+user will be granted access to the account if and only if the
+authenticated principal name of the user can be mapped to the local
+account name using the aname -> lname mapping rules (see \fIkrb5_anadd(8)\fP
+for more details).
 .PP
 The
 .B \-k
@@ -123,6 +132,8 @@ on the command line can be omitted.
 /etc/hosts
 .br
 /usr/hosts/*
+.br
+\&.k5login		in the user's home directory
 .DT
 .SH SEE ALSO
 rlogin(1), kerberos(3), krb_sendauth(3), krb_realmofhost(3)
diff --git a/src/appl/popper/popper.M b/src/appl/popper/popper.M
index 4270d0e63..bfd3b1d72 100644
--- a/src/appl/popper/popper.M
+++ b/src/appl/popper/popper.M
@@ -10,11 +10,9 @@
 .\"
 .\" @(#)popper.8    1.3    (CCS)   9/15/90     Copyright (c) 1990 Regents of the University of California.\nAll rights reserved.\n
 .\"
-.TH popper 8 "August 1990"
-.UC 6
-.ad
+.TH popper 8 "Kerberos Version 5.0" "MIT Project Athena"
 .SH NAME
-popper \- pop 3 server
+popper \- Kerberized Berkeley pop 3 server
 .SH SYNOPSIS
 .B /usr/etc/popper
 [ -d ]
@@ -26,7 +24,29 @@ variety of Unix computers to manage electronic mail for Macintosh
 and MS-DOS computers.  The server was developed at the University of
 California at Berkeley and conforms fully to the specifications in RFC
 1081 and RFC 1082.  The Berkeley server also has extensions to
-send electronic mail on behalf of a client.
+send electronic mail on behalf of a client.  
+
+This  Kerberized version of popper works like just like the Berkeley
+POP server, except
+that it expects the client to do a Kerberos authentication at the very
+beginning (using krb5_sendauth).  After the successful Kerberos
+exchange, the protocol reverts back to standard POP protocol, except
+that the username must match the Kerberos principal used in the initial
+authentication, and the password command is ignored, since the user has
+already authenticated using Kerberos. 
+.PP
+The kerberized version of popper is invoked out of 
+.IR inetd(8),
+using a
+line in /etc/inetd.conf like this:
+.PP
+kpop    stream  tcp     nowait  root    /usr/etc/popper popper
+.PP
+Since a Kerberos authentication is required at the beginning, the port
+used by the Kerberized POP protocol is different from the standard
+Berkeley POP
+protocol.  This port is kpop, and it is traditionally 1109 (where the
+official Berkely port is 110 for version 3 and 109 for version 2).
 .PP
 The 
 .B \-d
@@ -36,30 +56,26 @@ information is saved using syslog(8).  The
 flag turns on debugging and saves the trace information in
 .I trace\-file
 using fprintf(s).
-.SH HOW TO OBTAIN THE SERVER
-.PP
-The POP server is available via anonymous ftp from lilac.Berkeley.EDU
-(128.32.136.12).  It is in two files in the pub directory: a compressed
-tar file popper.tar.Z and a Macintosh StuffIt archive in BinHex format
-called MacPOP.sit.hqx.
+.\" .SH HOW TO OBTAIN THE SERVER
+.\" .PP
+.\" The POP server is available via anonymous ftp from lilac.Berkeley.EDU
+.\" (128.32.136.12).  It is in two files in the pub directory: a compressed
+.\" tar file popper.tar.Z and a Macintosh StuffIt archive in BinHex format
+.\" called MacPOP.sit.hqx.
+.\" 
 .SH THE POP TRANSACTION CYCLE
 .PP
-The Berkeley POP server is a single program (called popper) that is
-launched by inetd when it gets a service request on the POP TCP port.
-(The official port number specified in RFC 1081 for POP version 3 is
-port 110.  However, some POP3 clients attempt to contact the server at
-port 109, the POP version 2 port.  Unless you are running both POP2 and
-POP3 servers, you can simply define both ports for use by the POP3
-server.  This is explained in the installation instructions later on.)
+The Kerberized Berkeley POP server is a single program (called popper) that is
+launched by inetd when it gets a service request on the KPOP TCP port.
 The popper program initializes and verifies that the peer IP address is
 registered in the local domain, logging a warning message when a
 connection is made to a client whose IP address does not have a
 canonical name.  For systems using BSD 4.3 bind, it also checks to see
 if a cannonical name lookup for the client returns the same peer IP
 address, logging a warning message if it does not.  The the server
-enters the authorization state, during which the client must correctly
-identify itself by providing a valid Unix userid and password on the
-server's host machine.  No other exchanges are allowed during this
+enters the authorization state, during which the client sends the
+password command with a dummy password, since authentication is done
+with Kerberos credentials.  No other exchanges are allowed during this
 state (other than a request to quit.)  If authentication fails, a
 warning message is logged and the session ends.  Once the user is
 identified, popper changes its user and group ids to match that of the
@@ -90,18 +106,18 @@ be exercised in using this option since it generates considerable
 output in the syslog file.  Alternatively, the "-t <file-name>" option
 will place debugging information into file "<file-name>" using fprintf
 instead of syslog.
-.PP
-For SunOS version 3.5, the popper program is launched by inetd from
-/etc/servers.  This file does not allow you to specify command line
-arguments.  Therefore, if you want to enable debugging, you can specify
-a shell script in /etc/servers to be launched instead of popper and in
-this script call popper with the desired arguments.
+.\" .PP
+.\" For SunOS version 3.5, the popper program is launched by inetd from
+.\" /etc/servers.  This file does not allow you to specify command line
+.\" arguments.  Therefore, if you want to enable debugging, you can specify
+.\" a shell script in /etc/servers to be launched instead of popper and in
+.\" this script call popper with the desired arguments.
 .PP
 You can confirm that the POP server is running on Unix by telneting to
-port 110 (or 109 if you set it up that way).  For example:
+port 1109.  For example:
 .PP
 .nf
-%telnet myhost 110
+%telnet myhost 1109
 Trying...
 Connected to myhost.berkeley.edu.
 Escape character is '^]'.
diff --git a/src/appl/sample/sserver/sserver.M b/src/appl/sample/sserver/sserver.M
index 07901ee9b..2c7070a4d 100644
--- a/src/appl/sample/sserver/sserver.M
+++ b/src/appl/sample/sserver/sserver.M
@@ -30,16 +30,93 @@ sserver \- sample Kerberos version 5 server
 ]
 .br
 .SH DESCRIPTION
-.I sserver
-is usually executed from the internet daemon (\fIinetd\fR(8)) which
-listens on the \fBsample\fR TCP port when a connection from a sample
-client is established.  There is a compile-time option to allow it to
-run without intervention of the internet daemon.
+
+\fIsserver\fP and \fIsclient\fP are a simple demonstration
+client/server application.  When \fIsclient\fP connects to
+\fIsserver\fP, it performs a Kerberos authentication, and then
+\fIsserver\fP returns to \fIsclient\fP the Kerberos
+principal which was used for the Kerberos authentication.  It makes a
+good test that Kerberos has been successfully installed on a machine.
 .PP
-.I server_port
-is an optional argument; if specified, 
-.I sserver
-will listen on the specified port and wait for a connection.  It is used for
-debugging when it is inconvenient to run the sample server out of inetd.
+The service name used by \fIsserver\fP and \fIsclient\fP is
+\fBsample\fP.  Hence, \fIsserver\fP will require that there be a srvtab entry for the service
+"sample/hostname.mit.edu@REALM.NAME".  This srvtab is generated using
+the 
+.IR krb5_edit(8)
+program.  The srvtab file is installed in whatever
+directory is defined by V5Srvtabdir (usually /etc) as "v5srvtab".
+.PP
+\fIsserver\fP is normally invoked out of 
+.IR inetd(8), 
+using a line in
+/etc/inetd.conf that looks like this:
+.PP
+sample  stream  tcp     nowait  root /krb5/sbin/sserver	sserver
+.PP
+Since \fBsample\fP is normally not a port defined in /etc/services, you will
+usually have to add a line to /etc/services which looks like this:
+.PP
+sample          13135/tcp
+.PP
+When using \fIsclient,\fP you will first have to have an entry in the Kerberos
+database, by using 
+.IR kdb5_edit(8),
+and then you have to get Kerberos
+tickets, by using 
+.IR kinit(8).  
+Also, if you are running the \fIsclient\fP
+program on a different host than the \fIsserver\fP it will be
+connecting to, be
+sure that both hosts have an entry in /etc/services for the \fBsample\fP tcp
+port, and that the same port number is in both files.
+.PP
+When you run sclient you should see something like this:
+.PP
+sendauth succeeded, reply is:
+.br
+reply len 32, contents:
+.br
+You are nlgilman@JIMI.MIT.EDU
+.br
+.SH COMMON ERROR MESSAGES
+
+1)  \fIkinit\fP returns the error:
+.PP
+kinit: Client not found in Kerberos database while getting initial credentials
+.PP
+This means that you didn't create an entry for your username in the
+Kerberos database.
+.PP
+2)  \fIsclient\fP returns the error:
+.PP
+unknown service sample/tcp; check /etc/services
+.PP
+This means that you don't have an entry in /etc/services for the
+\fBsample\fP tcp port.
+.PP
+3)  \fIsclient\fP returns the error:
+.PP
+connect: Connection refused
+.PP
+This probably means you didn't edit /etc/inetd.conf correctly, or you
+didn't restart \fIinetd\fP after editing inetd.conf.
+.PP
+4)  \fIsclient\fP returns the error:
+.PP
+/krb5/bin/sclient: Server not found in Kerberos database while using sendauth
+.PP
+This means that the "sample/hostname@LOCAL.REALM" service was not
+defined in the Kerberos database; it should be created using \fIkdb5_edit,\fP
+and a srvtab file needs to be generated to make the key for that service
+principal available for \fIssclient\fP.
+.PP
+5)  \fIsclient\fP returns the error:
+.PP
+sendauth rejected, error reply is:
+        " No such file or directory"
+.PP
+This probably means \fIsserver\fP couldn't find the srvtab file.  It was
+probably not installed in the proper directory.
+.br
 .SH SEE ALSO
 sclient(1), services(5), inetd(8)