% This is a LaTeX document.  The files preamble.tex, intro.tex, and
% references.tex must also be in this directory.
% The command "latex admin" should be used to process the document
% in this directory.

%\input{preamble}
% article style
%\documentstyle[twocolumn,titlepage]{article}		% two column
\documentstyle[11pt,titlepage]{article}			% one column
% page headings include section name and page number
\pagestyle{headings}

%% The following set of commands should give a 1.25in top and bottom
%% margin and a 0.75in left and right margin.
% 1.25in top margin
\topmargin 0.25in
%\textheight 8in					% two column
\textheight 8.5in				% one column
% 0.75in left margin
%\oddsidemargin -0.25in \evensidemargin -0.25in	% two column
\oddsidemargin 0in \evensidemargin 0in		% one column
%\textwidth 6.875in				% two column
\textwidth 6.375in				% one column

% no paragraph indentation and skip a line between paragraphs
\parindent 0in
\parskip \bigskipamount

%% Define some macros for highlighting text in a consistent manner.
\newcommand{\idea}[1]{\mbox{\em #1}}
\newcommand{\id}[1]{\mbox{\it #1}}
\newcommand{\key}[1]{\mbox{\bf{#1}}}
\newcommand{\lit}[1]{{\tt #1}}
\newcommand{\q}[1]{``#1''}
\newcommand{\qt}[1]{\q{\lit{#1}}}
\newcommand{\home}[1]{\mbox{\lit{\~{\ }\hspace{-0.5em}/#1}}}

\newcommand{\Kerberos}{$K\epsilon\rho\beta\epsilon\rho o\varsigma$}

\newcommand{\master}{\idea{master\_server}}
\newcommand{\slave}{\idea{slave\_server}}
\newcommand{\cluster}{\idea{cluster\_nodes}}

\title{Caring and Feeding of Your Three-Headed Dog}
\author{Document Number IAG-90-011 \\ \\ \\ \\
Tai Jin \\ tai@IAG.HP.COM}
\date{May 22, 1990}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\maketitle

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Now that you have a three-headed dog, what will it take to care for
and feed him?  Well, you can count on the fact that with three-heads
he can eat three times as fast, but he doesn't need three times as
much food as a one-headed dog.

%\input{intro}
In a distributed computing environment, the network poses new problems
for security.  \key{Kerberos} is one system which provides the
necessary protection for users and services in this kind of
environment.  The goal at the Information Architecture Group (IAG) is
to incorporate Kerberos\footnote{We will use whatever security system
that the standards bodies embrace.  Currently, Kerberos is the only
one that is already implemented and is widely available, and it has
been selected by the OSF.  It currently uses the \key{DES} symmetric
cryptosystem.  However, the next version of Kerberos will be able to
support different types of cryptosystems.  ISO has defined X.509, and
they are considering the use of a public key cryptosystem (such as
\key{RSA}) in the implementation.} as an integral part of our
computing environment.  This is an on-going process since new commands
and services will have to be
\idea{Kerberized}.

The Kerberos environment described in this document has been modified
from the original MIT distribution.  The intent has been to improve
the ease of use and administration.  Some changes were also made to
eliminate the need for creating context dependent files on diskless
systems.

This document describes the administrative aspect of Kerberos.  You
should read \cite{tai:user} to understand the user aspect of Kerberos
before reading this document.  No effort has been made to describe the
technical details of the Kerberos design---the \cite{usenix} and
\cite{techplan} references can provide you with all the technical
details and explanations.  I would recommend that you at least read
\cite{dialogue} for an entertaining look at the issues involved in
designing such a system.

This document contains two major sections.  The first section
describes how to install Kerberos, and the second section describes
the caring and feeding of Kerberos.  The appendix contains a summary
of the installation and administration procedures, a list of files and
their descriptions, and some administration examples.

The following terminology is used throughout the remainder of the
document:
\begin{list}{}{\itemindent 0in \labelsep 0.25in
\listparindent 0in \itemsep 0in
\setlength{\labelwidth}{1.5in} \setlength{\leftmargin}{1.75in}
\setlength{\rightmargin}{0in}}
\item[\master\hfill] The Kerberos master server host.
\item[\slave\hfill] A Kerberos slave server host.
\end{list}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Installing Kerberos}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Current regulations state that software containing DES encryption used
for the purposes of authentication can be exported from the United
States.  However, since the Kerberos software distribution contains
more than just an authentication system (eg. it allows you to encrypt
data), it cannot be exported without an appropriate license.  If you
are thinking of installing the software, the responsibility is yours.

Kerberos is available via \id{ninstall} from
\key{aspen.iag.hp.com}.\footnote{If you do not already have
\id{ninstall} then you can anonymously \id{ftp} it from
\key{aspen.iag.hp.com}.  Various binary versions are available in the
\lit{pub/ninstall} directory.}  The following components are available:
binaries for \key{HP-UX 7.0}, documentation, libraries and include
files.

Different components of the Kerberos package will be installed on
master servers, slave servers and other systems.  It is highly
recommended that any open-subnet system which you may have be
configured as a client and server of Kerberized services.  This allows
you to use Kerberized versions of \id{rlogin}, \id{remsh}, and
\id{rcp} to and from your open-subnet system without compromising its
security.\footnote{The HP Corporate security guidelines state that the
\id{rlogin}, \id{remsh}, and \id{rcp} services must be disabled on
open-subnet systems.  The Kerberized equivalents are allowed, and they
provide the same convenience without the security risks.}

There must be one master server and, optionally, one or more slave
servers in your realm.  The slave servers provide redundancy in case
of master server failure.

One of the basic assumptions in Kerberos is that the hosts on the
network are all time-synchronized to within a couple of minutes of
each other.  Kerberos will not work between hosts whose clocks are off
by more than a couple of minutes.\footnote{A recommended
time-synchronization service is provided by NTP (Network Time
Protocol).  You can \id{ninstall} the \qt{NTPtoronto} package from
\key{hpsdlz.sdd.hp.com}.}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Creating a Master Server}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Follow these instructions to set up a Kerberos master server.  These
instructions also configure the system as a Kerberized server and
client.  There must be one master server in every realm.  These
instructions assume that you are logged in with superuser capability
on the master server.

\begin{enumerate}
\item \lit{ninstall -haspen.iag.hp.com -v kerberos kerberos.bin.master}

This installs configuration files, documentation, and Kerberos master
server programs and scripts.  It creates the \lit{/kerberos} directory
and installs some scripts in it, and it adds entries to the
\lit{/etc/services} and \lit{/etc/inetd.conf} files.  It also installs
the Kerberized applications.

\item \lit{cp /etc/newconfig/krb.conf /usr/local/etc}

Edit \lit{/usr/local/etc/krb.conf} to reflect your local realm and the
Kerberos master server host.  The first line in the file is the realm
name.  As a rule, your realm name should be the same as your Internet
domain converted to upper-case.  The following lines list the master
and slave servers for the realm.  For example, for Internet domain
\key{iag.hp.com} the realm is \key{IAG.HP.COM} and the master server
is \key{aspen.iag.hp.com}.  Here is the \lit{krb.conf} file:
\begin{verbatim}
IAG.HP.COM
IAG.HP.COM aspen.iag.hp.com admin server
\end{verbatim}
A server entry which ends with \q{\key{admin server}} is a master
server; other server entries are slave servers.

\item If your realm name is {\em not} the same as your Internet
domain then you should copy the file \lit{/etc/newconfig/krb.realms}
to \lit{/usr/local/etc/krb.realms} and edit the file.  This file
contains entries which translate host names and domains to realm
names.  A host translation entry contains the host name and the realm
for the host.  A domain translation entry contains the Internet domain
(beginning with a dot) and the realm for the domain.  For example, the
Internet domain \key{sde.hp.com} is geographically split, and it is
more convenient to create a locally administered realm at each site.
So the two realms \key{SDE-FC.HP.COM} and \key{SDE-PA.HP.COM} were
created.  Assuming that you are in the \key{SDE-FC.HP.COM} realm your
\lit{krb.realms} file would contain at least one entry:
\begin{verbatim}
.sde.hp.com SDE-FC.HP.COM
\end{verbatim}
This is a domain translation entry, and it maps every host in the
\key{sde.hp.com} domain to be in the \key{SDE-FC.HP.COM} realm.

\item \lit{/usr/local/etc/kdb\_init}

This program prompts you for the local realm name and the Kerberos
master key.  It creates the \lit{/kerberos/principal.*} files which
contain the database.  The master key must be remembered as it is not
stored anywhere.

\item \lit{/usr/local/etc/kstash}

Stash the master key for use by various Kerberos programs.  Doing this
makes it a little more convenient when using those Kerberos programs
which prompt for the master key.  The encrypted key is stashed in the
\lit{/kerberos/.k} file.

\item \lit{/kerberos/kdb\_edit.sh}

This script invokes \lit{/usr/local/etc/kdb\_edit} which prompts you
for principals and passwords.  You should add the \key{rcmd} service
for the \master.  The instance should be \master.  Refer to the
section entitled \q{Adding Principals} for the type of input expected
of you.  At this time you can also add other principals (users and
service instances) or you can do that later.

\item \lit{/usr/local/etc/ext\_srvtab -n \master}

Extract the service entries for \master.  The \qt{-n} option tells
\id{ext\_srvtab} not to prompt for the master key.

\item If \master\ is a cluster node and \lit{/usr/local/etc/srvtab}
is not already a CDF then execute:

\lit{makecdf /usr/local/etc/srvtab}

to make it a CDF.  If you do not like CDFs there is an alternative
configuration for the \lit{srvtab} file.  Read the section entitled
\q{Alternate Cluster srvtab Configuration}.

\item \lit{cp \master-new-srvtab /usr/local/etc/srvtab \\
chmod 400 /usr/local/etc/srvtab \\
rm \master-new-srvtab}

Install the output file as the service file, and protect it from
ordinary users.

\item \lit{/kerberos/kerberos.sh}

Start the Kerberos master and administrative servers.  This script
should be invoked from \lit{/etc/netbsdsrc} or from some other boot
script.\footnote{At IAG we start all of our local network services
from \lit{/etc/netlocalrc} which is invoked from
\lit{/etc/netlinkrc}.}

\item \lit{inetd -c}

The \lit{/etc/inetd.conf} and \lit{/etc/services} files have already
been updated by the \id{ninstall} process.  So reconfigure \id{inetd}
to start accepting the Kerberized services.
\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Creating a Slave Server}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Follow these instructions to set up a slave server.  These
instructions also configure the system as a Kerberized server and
client.  Slave servers are optional, and you may set up as many of
them as you see fit.  These instructions assume that you are logged in
with superuser capability on the slave server.

\begin{enumerate}
\item \lit{ninstall -haspen.iag.hp.com -v kerberos kerberos.bin.slave}

This installs configuration files, documentation, and Kerberos slave
server programs and scripts.  It creates the \lit{/kerberos} directory
and installs some scripts in it, and it adds entries to the
\lit{/etc/services} and \lit{/etc/inetd.conf} files.  It also installs
the Kerberized applications.

\item On the \master, add the \slave\ as a slave entry to the
\lit{/usr/local/etc/krb.conf} file.  For example,
\begin{verbatim}
IAG.HP.COM
IAG.HP.COM aspen.iag.hp.com admin server
IAG.HP.COM kenzo.iag.hp.com
IAG.HP.COM telford.iag.hp.com
\end{verbatim}
where \key{kenzo.iag.hp.com} and \key{telford.iag.hp.com} are the
slave servers.

\item On the \master, execute:

\lit{/kerberos/kdb\_edit.sh}

to add new service instances for the \slave.  You must add the
\key{rcmd} service with instance \slave\ and any other Kerberized
service which the \slave\ will provide.  Refer to the section entitled
\q{Adding Principals} for more information on how to do this.

\item On the \master, execute:

\lit{/usr/local/etc/ext\_srvtab -n \slave}

to extract the service entries for \slave.  The \qt{-n} option tells
\id{ext\_srvtab} not to prompt for the master key.

\item If \slave\ is a cluster server and \lit{/usr/local/etc/srvtab}
is not already a CDF then execute:

\lit{makecdf /usr/local/etc/srvtab}

to make it a CDF.  If you do not like CDFs there is an alternative
configuration for the \lit{srvtab} file.  Read the section entitled
\q{Alternate Cluster srvtab Configuration}.

\item Copy the \lit{\slave-new-srvtab} file from the \master and install
it on \slave as \lit{/usr/local/etc/srvtab} with mode 400.

\item Copy the \lit{/usr/local/etc/krb.conf} and
\lit{/usr/local/etc/krb.realms} configuration files from the \master.

\item On the \master, add the \slave\ to the \lit{/kerberos/slaves}
file.  This file contains the host names of all the slave servers, one
per line.

\item \lit{/usr/local/etc/kdb\_init}

This program prompts you for the local realm name and the Kerberos
master key.  The realm name and master key should be the same as for
the \master.  It creates the \lit{/kerberos/principal.*} files which
contain the database.  This must be done to create an empty database
for the database propagation from the \master\ to work.

\item \lit{/usr/local/etc/kstash}

Stash the master key for use by various Kerberos programs.  Doing this
makes it a little more convenient when using those Kerberos programs
which prompt for the master key.  The encrypted key is stashed in the
\lit{/kerberos/.k} file.

\item \lit{/kerberos/kerberos\_slave.sh}

Start the Kerberos slave server and propagation server.  This script
should be invoked from \lit{/etc/netbsdsrc} or from some other boot
script.\footnote{At IAG we start all of our local network services
from \lit{/etc/netlocalrc} which is invoked from
\lit{/etc/netlinkrc}.}

\item On the \master, execute:

\lit{/kerberos/kprop.sh}

This script propagates the master database to the slave server.

\item \lit{inetd -c}

The \lit{/etc/inetd.conf} and \lit{/etc/services} files have already
been updated by the \id{ninstall} process.  So reconfigure \id{inetd}
to start accepting the Kerberized services.
\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Creating a Kerberized Service Client and Server}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Follow these instructions to set up a host which is both a client and
server of Kerberized services.  These instructions assume that you are
logged in with superuser capabilities on the host.

\begin{enumerate}
\item %
\begin{itemize}
\item If this host is a standalone system or if this is the first node
in a cluster to have Kerberos installed then do the following:
\begin{enumerate}
\item \lit{ninstall -haspen.iag.hp.com -v kerberos}

This installs configuration files, documentation, and the Kerberized
applications.  It also adds entries to the \lit{/etc/services} and
\lit{/etc/inetd.conf} files.

\item Copy the \lit{/usr/local/etc/krb.conf} and
\lit{/usr/local/etc/krb.realms} configuration files from the \master.
\end{enumerate}

\item If this host is a part a cluster which already has Kerberos
installed and the \\
\lit{/etc/inetd.conf} file is a CDF then do the following:
\begin{enumerate}
\item \lit{cat /etc/newconfig/Kerberos.inetd >> /etc/inetd.conf}

Add the \id{inetd} service entries for the Kerberized services.
\end{enumerate}
\end{itemize}

\item On the \master, execute:

\lit{/kerberos/kdb\_edit.sh}

to add new service instances for this host.  You must add the
\key{rcmd} service with instance \idea{host} and any other Kerberized
service which this host will provide.  Refer to the section entitled
\q{Adding Principals} for more information on how to do this.

\item On the \master\ (or a \slave), execute:

\lit{/usr/local/etc/ext\_srvtab -n \idea{host}}

to extract service entries for the instance \idea{host}.  Copy the
output file \lit{\idea{host}-new-srvtab} to \idea{host}.

\item If \idea{host} is a cluster node and \lit{/usr/local/etc/srvtab}
is not already a CDF then execute:

\lit{makecdf /usr/local/etc/srvtab}

to make it a CDF.  If you do not like CDFs there is an alternative
configuration for the \lit{srvtab} file.  Read the section entitled
\q{Alternate Cluster srvtab Configuration}.

\item \lit{cp \idea{host}-new-srvtab /usr/local/etc/srvtab \\
chmod 400 /usr/local/etc/srvtab \\
rm \idea{host}-new-srvtab}

Install the output file as the service file, and protect it from
ordinary users.

\item \lit{inetd -c}

The \lit{/etc/inetd.conf} and \lit{/etc/services} files have already
been updated by the \id{ninstall} process.  So reconfigure \id{inetd}
to start accepting the Kerberized services.
\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Caring and Feeding of Kerberos}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The master Kerberos database is located in the \lit{/kerberos}
directory on the master server (a host of your choice).  There is only
one master database for a given realm, and only the master database
can be updated.  There can be any number of slave databases which are
read-only.  Therefore, modifications should only be made to the master
Kerberos database.

Each host which provides Kerberized services must have the
\lit{/usr/local/etc/srvtab} configuration file.  This file has entries
for all the Kerberized services which this host provides.  The entries
for this file are extracted from the Kerberos database (master or
slave) with the program \id{ext\_srvtab}.  In a cluster the services
file is a CDF (but read the section entitled \q{Alternate Cluster
srvtab Configuration} if you would rather not use CDFs).

The following scenarios will be described: adding principals, deleting
principals, changing a password, and inter-realm authentication.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Configuration Files}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The file \lit{/usr/local/etc/krb.conf} (and
\lit{/usr/local/etc/krb.realms} if needed) must be maintained and
should be the same on every host in the realm.  The only time that the
\lit{krb.conf} file may need to be updated is when any of the servers
change or when inter-realm authentication is configured with a new
realm.  The only time that the \lit{krb.realms} file may need to be
updated is when inter-realm authentication is configured with a new
realm.

The first line in the \lit{krb.conf} file is the name of the local
realm.  Following lines map realm names to servers for those realms.
For example:
\begin{verbatim}
IAG.HP.COM
IAG.HP.COM aspen.iag.hp.com admin server
IAG.HP.COM kenzo.iag.hp.com
IAG.HP.COM telford.iag.hp.com
SDE-FC.HP.COM hpfclk.sde.hp.com admin server
\end{verbatim}
The local realm is \key{IAG.HP.COM} and there are three servers for
this realm, \key{aspen.iag.hp.com} is the master server because its
entry ends with \q{\key{admin server}}, and \key{kenzo.iag.hp.com} and
\key{telford.iag.hp.com} are slave servers.  The file is also
configured with a server for another realm (only needed for
inter-realm authentication).

The \lit{krb.realms} file just contains translation entries and is
only needed for inter-realm authentication.  Normally, a translation
entry is not necessary if the realm name matches the Internet domain.
But if a domain contains multiple realms then this file could map the
host names to the appropriate realms.  Both host names and domains can
be mapped to realms.  A domain translation entry begins with a dot, as
in,
\begin{verbatim}
.sde.hp.com SDE-FC.HP.COM
\end{verbatim}
and a host translation entry does not begin with a dot:
\begin{verbatim}
hp-ses.sde.hp.com SDE-PA.HP.COM
\end{verbatim}
The first match in the file determines the translation.  So you should
list host name translations for the exceptions before you list a
domain translation for the general case.  This is more fully described
in the section entitled \q{Inter-Realm Authentication}.

The other configuration file is the \lit{/usr/local/etc/srvtab}
services file which must be maintained on every host or cluster which
provides Kerberized services.  This file is maintained as part of the
service addition/deletion process.

Finally, there are the access control lists for use with the
\id{kadmin} command.  These configuration files are
\lit{/kerberos/admin\_acl.add}, \lit{/kerberos/admin\_acl.mod}, and
\lit{/kerberos/admin\_acl.get}, and they are maintained on the master
server.  Each file contains a list of principals which are allowed to
add and modify entries in, and get entries from the Kerberos database.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Adding Principals}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Remember that only the master database can be modified.  So to add a
user or service, you must run the \lit{/kerberos/kdb\_edit.sh} script
on the \master.  This script invokes the
\lit{/usr/local/etc/kdb\_edit} program which lets you edit the
database, and it also invokes the \lit{/usr/local/etc/kprop} program
to propagate the database to the slave servers.  You can look at the
script to see exactly what it does.  When editing the database, you
will be prompted for the principal and the instance names among other
things.  Here is the sequence of prompts that you will get:

\begin{enumerate}
\item \lit{Principal name: \idea{user}}

Enter the user's username as the principal name.  It is a very good
idea to keep the principal the same as the username.

\item \lit{Instance:}

Just press return.  All users have a principal identifier with a null
instance.  If a user also has superuser capability then the user will
also have a \key{root} instance.  In this case you should follow these
instructions again to add the same principal with the \key{root}
instance.

\item \lit{<Not found>, Create [y] ?}

Just press return to create the principal.

\item \lit{New Password: \idea{password}} \\
\lit{Verifying, please re-enter} \\
\lit{New Password: \idea{password}}

Enter the new password twice.  The password is not echoed.

\item \lit{Expiration date (enter yyyy-mm-dd) [ 1999-12-31 ] ?}

This is the date at which the principal expires.  Just use the default
unless there is a specific date at which the prinicipal is to expire.

\item \lit{Max ticket lifetime (*5 minutes) [ 255 ] ?}

This is the maximum ticket lifetime allowed.  The maximum of 255 is a
restriction of the current Kerberos protocol.  Just use the default
unless you want to limit the ticket lifetime.

\item \lit{Attributes [ 0 ] ?}

Just press return.  There are currently no attributes of interest.

\item \lit{Edit O.K.} \\
\lit{Principal name:}

Just press return to exit, or continue to add more principals (if you
are adding several service instances, for example).
\end{enumerate}

After you exit from the program, if slave servers are configured then
the script will prompt you if it is OK to propagate the database.
Type \qt{y} to propagate the database.  That is all you have to do for
a user.

Adding a new service instance (or instances) follows the same
procedure as adding a user, but there are some differences in the
input and there are some additional instructions.  Here are the
differences in input:

\begin{enumerate}
\item You must enter the instance name.  The instance name is the
host name for which the service entry is being created.

\item You should type \qt{RANDOM} as the password (type it twice)
and you must confirm at the next prompt to let Kerberos generate a
random password for the service.  The reason that the service should
have a random password is that the password is used only by the
service.
\end{enumerate}

Adding a new service for one or more instances is the same as adding
one or more services for a given instance.  Since the
\lit{/usr/local/etc/srvtab} file cannot be edited, and since you
cannot selectively extract service entries for each instance, you must
recreate the \lit{/usr/local/etc/srvtab} file.

\begin{enumerate}
\item \lit{/usr/local/etc/ext\_srvtab -n \idea{host}}

Extract the service entries for \idea{host} from the database.  You
can specify more than one host at a time.  The output file is
\lit{\idea{host}-new-srvtab} for each host.  Copy the file
\lit{\idea{host}-new-srvtab} to the target system, \idea{host}.

\item \lit{cp \idea{host}-new-srvtab /usr/local/etc/srvtab \\
rm \idea{host}-new-srvtab}

Install the services file on \idea{host} and then remove the
\lit{\idea{host}-new-srvtab} file.
\end{enumerate}

So whenever a new service instance is added to the database, the
\lit{/usr/local/etc/srvtab} file on the host which corresponds to the
new instance must be recreated.

Changing an existing entry's password, expiration date, or attributes
can be accomplished by following the same procedure for adding an
entry.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Deleting Principals}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Remember that only the master database can be modified.  So to delete
a principal you must run the \lit{/kerberos/kdb\_edit.sh} script on
the \master.  For deletion, this script invokes the
\lit{/usr/local/etc/kdb\_util} program which dumps the database into a
file which can be edited.  The script also invokes the
\lit{/usr/local/etc/kprop} program to propagate the database to the
slave servers.  You can look at the script to see exactly what it
does.

\begin{enumerate}
\item \lit{/kerberos/kdb\_edit.sh -d}

The \qt{-d} option must be specified to delete entries from the
database.  The script dumps the database into a file and invokes an
editor on the file.  The default editor is \id{vi} unless you have
defined the \key{EDITOR} environment variable to be your favorite
editor.

The first field in each line is the principal name and the second
field is the instance name.  Delete the entry (or entries) matching
the instance(s) for which you wish to delete.  Then save the file and
exit from the editor.

The script will prompt you if it is OK to load the database.  Type
\qt{y} to load the database.  If slave servers are configured then the
script will also prompt you if it is OK to propagate the database.
Type \qt{y} to propagate the database.
\end{enumerate}

That is all you do to delete a user principal.  If you are deleting
one or more service instances because you are removing one or more
standalone hosts or cluster nodes from Kerberized service then you
should just remove the \lit{/usr/local/etc/srvtab} file from each
host.

Changing an existing entry (ie. changing a principal name and/or
instance) is accomplished by following this same procedure.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Alternate Cluster srvtab Configuration}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Previously, the \lit{/usr/local/etc/srvtab} file in a cluster was
assumed to be a CDF.  This section describes how to configure it as a
single file shared by all cluster nodes---that is, the service tickets
for all the cluster nodes are stored in a single
\lit{/usr/local/etc/srvtab} file.

Here are the steps needed to implement this configuration:

\begin{enumerate}
\item On the \master\ (or a \slave), execute:

\lit{/usr/local/etc/ext\_srvtab -n \cluster}

to extract the service entries for every node in the cluster (where
\cluster is a space-separated list of all nodes in a cluster).
You may specify all the cluster node names on the command line.  The
\qt{-n} option tells \id{ext\_srvtab} not to prompt for the master
key.

\item \lit{cat *-new-srvtab > new-srvtab}

Combine all the output files into a single file and install the file
as \lit{/usr/local/etc/srvtab} in the cluster.  Remove all the
\lit{*new-srvtab} files.  Then login on the cluster and execute:

\lit{chmod 400 /usr/local/etc/srvtab}

to protect it from ordinary users.
\end{enumerate}

When you add, delete, or modify service entries in the Kerberos
database you must recreate the \lit{/usr/local/etc/srvtab} file by
following this same procedure.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Changing a Password}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

If a user forgets his or her password then you may be called upon to
change his or her password.  You can do this by following the
procedure given for adding a principal.  When the \id{kdb\_edit}
program sees that the principal already exists, you will be prompted
if you want to change the password.  You will also have the
opportunity to change the other information if you confirm the prompt
and change the password.

A simpler way to just change a password is to use the \id{kadmin}
command.  You must have an \key{admin} instance and your principal
must be listed in the \lit{/kerberos/admin\_acl.mod} file on the
master server.  You can run \id{kadmin} on any host.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Inter-realm Authentication}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The ticket-granting ticket is the basis for obtaining other service
tickets.  In the case of inter-realm service activity, both realms
must be able to authenticate with each other.  Since you are only
registered in one realm, to use a service in another realm means that
the server must be able to authenticate you in your own realm.  To
allow this to happen, the two realms must use a common key for this
particular instance of the ticket-granting ticket.\footnote{The
current version of the Kerberos protocol only allows for single-hop
inter-realm authentication.}

To illustrate with an example, let's say that the \key{IAG.HP.COM} and
\key{SDE-FC.HP.COM} realm administrators want to set up inter-realm
authentication.  The first step is for the two administrators to
decide on a password, let's say \qt{84kf84ng7023kdfh} (it should be
random since no one will ever use this password).  Then the
administrator of \key{IAG.HP.COM} runs \id{/kerberos/kdb\_edit.sh} on
his master server and adds the principal \key{krbtgt} with the
instance \key{SDE-FC.HP.COM} and the password.  The administrator of
\key{SDE-FC.HP.COM} runs \id{/kerberos/kdb\_edit.sh} on his master
server and adds the principal \key{krbtgt} with the instance
\key{IAG.HP.COM} and the password.

The \lit{/usr/local/etc/krb.conf} and \lit{/usr/local/etc/krb.realms}
files must also be configured to include the other realm's server(s)
and to map host names and domains to the other realm.  To continue
with our example, we should add the servers for the other realm in
\lit{krb.conf} and list the host and domain translation in
\lit{krb.realms}.

The \lit{krb.conf} file for \key{IAG.HP.COM} would look like this:
\begin{verbatim}
IAG.HP.COM
IAG.HP.COM aspen.iag.hp.com admin server
IAG.HP.COM kenzo.iag.hp.com
IAG.HP.COM telford.iag.hp.com
SDE-FC.HP.COM hpfclk.sde.hp.com admin server
\end{verbatim}
The additional entry lists the \key{SDE-FC.HP.COM} domain and its
master server.  The \lit{krb.realms} file would look like this:
\begin{verbatim}
.sde.hp.com SDE-FC.HP.COM
\end{verbatim}
This translates all hosts in the \key{sde.hp.com} domain to be in the
\key{SDE-FC.HP.COM} realm.  However, if there is another realm in
the same Internet domain (this would be the only reason for the realm
name to be different from the domain) then a domain translation entry
cannot be used since there is now a one (domain) to two (realm)
mapping.  In this case, you can decide to keep the domain translation
and add host name translations for hosts in the other realm.  For
example, if the other realm is \key{SDE-PA.HP.COM} then,
\begin{verbatim}
hp-sde.sde.hp.com SDE-PA.HP.COM
hp-ses.sde.hp.com SDE-PA.HP.COM
.sde.hp.com SDE-FC.HP.COM
\end{verbatim}
is a valid configuration.  The host entries are for all hosts in the
\key{SDE-PA.HP.COM} realm and the domain entry is for all hosts in the
\key{SDE-FC.HP.COM} realm.  The order of the entries is important as
the first match is used.  The choice of which realm is specified with
the domain translation entry is purely a matter of convenience.

If it is not possible to to list all translations in the
\lit{krb.realms} file then the user would have to specify the realm
of the target system.  For example, if the host
\key{hpsdel.sde.hp.com} is in the \key{SDE-PA.HP.COM} realm and it is
not listed in the \key{krb.realms} file then to use \id{krlogin} the
user must specify the \qt{-k} option and the realm name:
\begin{verbatim}
krlogin hpsdel.sde.hp.com -k SDE-PA.HP.COM
\end{verbatim}
So to make it easier for the users, all host and domain translations
should be listed in the \lit{krb.realms} file.

Now let's look at the configuration files from the \key{SDE-FC.HP.COM}
realm.  The \lit{krb.conf} file would look like this:
\begin{verbatim}
SDE-FC.HP.COM
SDE-FC.HP.COM hpfclk.sde.hp.com admin server
IAG.HP.COM aspen.iag.hp.com asmin server
IAG.HP.COM kenzo.iag.hp.com
IAG.HP.COM telford.iag.hp.com
\end{verbatim}
All the servers for \key{IAG.HP.COM} are listed here, but only one
(any one of them) is necessary.  The \lit{krb.realms} file would look
like this:
\begin{verbatim}
hp-sde.sde.hp.com SDE-PA.HP.COM
hp-ses.sde.hp.com SDE-PA.HP.COM
.sde.hp.com SDE-FC.HP.COM
\end{verbatim}
The local realm is listed as a domain translation entry after any host
name entries for the other realm.  In the \key{SDE-PA.HP.COM} realm,
there would be host entries for the \key{SDE-FC.HP.COM} realm and a
domain entry for \key{SDE-PA.HP.COM}.  Also note that the
\key{IAG.HP.COM} realm is not listed here.  This is because the realm
name is the same as the Internet domain.  However, it can be listed if
desired.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\input{references}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{thebibliography}{99}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\bibitem{tai:user} Tai Jin.  \q{Living with Your Three-Headed Dog}.  HP
Internal Document (April 1990).

\bibitem{tai:admin} Tai Jin.  \q{Caring and Feeding of Your
Three-Headed Dog}.  HP Internal Document (April 1990).

%\bibitem{tai:develop} Tai Jin.  \q{Teaching Your Three-Headed Dog New
%Tricks}.  HP Internal Document (to be written?).

\bibitem{techplan} S. P. Miller, B. C. Newman, J. I. Schiller, J. H.
Saltzer.  Section E.2.1: Kerberos Authentication and Authorization
System, MIT Project Athena Technical Plan (December 1987).

\bibitem{usenix} J. G. Steiner, B. C. Neuman, J. I. Schiller.
\q{Kerberos: An Authentication Service for Open Network Systems}.
Usenix Conference Proceedings (March 1988).

\bibitem{dialogue} B. Bryant.  \q{Designing an Authentication System: a
Dialogue in Four Scenes}.  MIT Project Athena (February 1988).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{thebibliography}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%\onecolumn					% two column
\appendix

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Installation Summary}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Here is a summary of the instructions:

\begin{itemize}
\item To install Kerberos on the \master:
\begin{enumerate}
\item \lit{ninstall -haspen.iag.hp.com -v kerberos kerberos.bin.master}
\item Edit the \lit{krb.conf} and \lit{krb.realms} configuration files.
\item Create the master database and add services for the \master\ 
instance.
\item Extract the service entries for the \master\ instance and
install them in the \lit{srvtab} file.
\item \lit{/kerberos/kerberos.sh}
\item \lit{inetd -c}
\end{enumerate}

\item To install Kerberos on a \slave:
\begin{enumerate}
\item \lit{ninstall -haspen.iag.hp.com -v kerberos kerberos.bin.slave}
\item On the \master, add the \slave\ to the \lit{krb.conf}
configuration file and also to the \lit{slaves} file.  Add services
for the \slave\ instance.
\item Install the master configuration files on the \slave.
\item Create the database.
\item \lit{/kerberos/kerberos\_slave.sh}
\item On the \master, execute \lit{/kerberos/kprop.sh}.
\item Extract the service entries for the \slave\ instance and install
them in the \lit{srvtab} file.
\item \lit{inetd -c}
\end{enumerate}

\item To install Kerberos on the rest of your systems:
\begin{enumerate}
\item \lit{ninstall -haspen.iag.hp.com -v kerberos}
\item On the \master, add services for the \idea{host} instance, and
extract and install the service entries for the \idea{host} and
install them in the \lit{srvtab} file on the
\idea{host}.
\item \lit{inetd -c}
\end{enumerate}
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Administration Summary}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

All editing of the database must be performed on the \master.  You
should also edit the configuration files on the \master\ and
distribute them to the rest of your systems.

\begin{itemize}
\item Maintaining configuration files

The \lit{krb.conf} and \lit{krb.realms} files should be identical on
every system.  These files must be updated when servers change or when
inter-realm authentication is configured.  The \lit{srvtab} file
should be updated on the affected systems as part of the service
addition and deletion process.

\item Updating slave servers

By using the \lit{/kerberos/kdb\_edit.sh} script to add/delete/modify
the Kerberos database the database can be automatically updated on the
slave servers.

\item Adding a new user

Run the \lit{/kerberos/kdb\_edit.sh} script and just enter the
principal, the instance (if any), and the password.  Everything else
should be defaulted.

\item Adding a new service instance

Run the \lit{/kerberos/kdb\_edit.sh} script and just enter the
principal, the instance, and \qt{RANDOM} for the password.  Everything
else should be defaulted.  Then extract the service entries for each
instance and recreate the \lit{srvtab} file on the affected hosts.

\item Deleting a user

Execute the command \qt{/kerberos/kdb\_edit.sh -d} to edit the
database.

\item Deleting a service instance

Execute the command \qt{/kerberos/kdb\_edit.sh -d} to edit the
database.  Then extract the service entries for each instance for
which a service was deleted and recreate the \lit{srvtab} file on the
affected hosts.

\item Changing a user's password

Run the \lit{/kerberos/kdb\_edit.sh} script and enter the user's
principal and instance, if any, and change the password.

\item Inter-realm authentication

You must cooperate with the other realm administrator with which you
wish to set up inter-realm authentication by sharing a common password
for the ticket-granting ticket.  Add the ticket-granting ticket as you
would a new user with the other realm name as the instance.  Then add
one or more server entries of the other realm to the \lit{krb.conf}
file.  The \lit{krb.realms} file should also be updated if the other
realm does not match the Internet domain for that realm.
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{File Descriptions}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Here are the descriptions of the programs and files that are relevant
to the administration of Kerberos.
\begin{list}{}{\itemindent 0in \labelsep 0.25in
\listparindent 0in \itemsep \medskipamount
\setlength{\labelwidth}{2in} \setlength{\leftmargin}{2.25in}
\setlength{\rightmargin}{0in}}
\item[/etc/newconfig/Kerberos.inetd\hfill]
File containing \lit{/etc/inetd.conf} entries for the Kerberized
versions of \id{rcp}, \id{remsh} and \id{rlogin}.  This file is
automatically appended to the \lit{/etc/inetd.conf} file (if
necessary) by the \id{ninstall} procedure.

\item[/etc/newconfig/Kerberos.services\hfill]
File containing Kerberos service entries.  This file is automatically
appended to the \lit{/etc/services} file (if necessary) by the
\id{ninstall} procedure.

\item[/usr/local/etc/krb.conf\hfill]
Kerberos configuration file listing realms and servers.  This file
must be edited before Kerberized services can be used.  This file is
installed as \lit{/etc/newconfig/krb.conf} by the \id{ninstall}
procedure.

\item[/usr/local/etc/krb.realms\hfill]
Sample realms translation file.  Translates host and domain names to
realms.  If necessary, this file should be edited.  This file is
installed as \lit{/etc/newconfig/krb.realms} by the \id{ninstall}
procedure.

\item[/kerberos\hfill]
The Kerberos database directory for master and slave servers.  This
directory is created by the \id{ninstall} procedure.

\item[/kerberos/kdb\_edit.sh\hfill]
This script is installed on the master server.  It is used to edit the
master database and propagate the database to the slave servers.  It
invokes the \lit{kdb\_edit} and \lit{kdb\_util} programs and the
\lit{kprop.sh} script.

\item[/kerberos/kprop.sh\hfill]
This script is installed on the master server.  It is used to
propagate the master database to the slave servers.

\item[/kerberos/kerberos.sh\hfill]
This script is installed on the master server.  It starts the
\lit{kerberos} and \lit{kadmind} daemons.  This script should be
invoked from a system boot script.

\item[/kerberos/kerberos\_slave.sh\hfill]
This script is installed on slave servers.  It starts the
\lit{kerberos} and \lit{kpropd} daemons.  This script should be
invoked from a system boot script.

\item[/kerberos/.k\hfill]
This file contains the cached master key and is read by various
programs which access the database.

\item[/.klogin\hfill]
This file is needed for \id{krcp}, \id{kremsh}, \id{krlogin} to work
with the \key{root} instance of a user.  This is essentially a
\home{.rhosts} file for \key{root} instance users.  You also
need this file if you use \id{ksu2} to become the \key{root} user.

\item[/usr/local/bin/ksrvutil\hfill]
Kerberos \lit{/usr/local/etc/srvtab} service file utility.

\item[/usr/local/bin/kadmin\hfill]
Kerberos administrative utility.  This program allows selected
principals to add new principals, change passwords, and get
information.

\item[/usr/local/etc/kadmind\hfill]
The Kerberos database administrative server.  This program allows
selected principals to add new principals, change passwords, and get
information.  Your principal must have an \key{admin} instance to
perform these tasks, and the principals allowed to add new principals
must be listed in the \lit{/kerberos/admin\_acl.add} file, principals
allowed to change passwords must be listed in the
\lit{/kerberos/admin\_acl.mod} file, and principals allowed to get
information must be listed in the \lit{/kerberos/admin\_acl.get} file.
The server obeys \lit{/usr/adm/inetd.sec} security for the service
name \key{kerberos\_master}.

\item[/usr/local/etc/kdb\_destroy\hfill]
Destroy the Kerberos database.

\item[/usr/local/etc/kdb\_edit\hfill]
Edit the Kerberos database; this program allows you to add entries and
change passwords and attributes.

\item[/usr/local/etc/kdb\_init\hfill]
Initialize the Kerberos database.

\item[/usr/local/etc/kdb\_util\hfill]
Kerberos database utility used to dump and load the database.

\item[/usr/local/etc/kerberos\hfill]
The Kerberos master and slave server.

\item[/usr/local/etc/kprop\hfill]
Propagates the Kerberos database from the master server to the slave
servers.

\item[/usr/local/etc/kpropd\hfill]
Kerberos slave propagation server.  The server obeys
\lit{/usr/adm/inetd.sec} security for the service name \key{krb\_prop}.

\item[/usr/local/etc/kstash\hfill]
Stash the encrypted Kerberos master key.  This allows \id{kerberos}
and \id{kadmind} to start without having to prompt for the master key.
The key is stored in the \lit{/kerberos/.k} file.

\item[/usr/local/etc/ext\_srvtab\hfill]
Extract service entries for a particular instance or instances from
the Kerberos database.  This command must be run on a Kerberos server
host.  The output file should be installed as the
\lit{/usr/local/etc/srvtab} file on the instance (host) providing
the service(s).

\item[/usr/local/etc/srvtab\hfill]
This file contains the service keys for a particular host.  It is
important to protect this file with UNIX mode 400 to prevent security
breaches.
\end{list}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Administration Examples}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The following session illustrates the addition of a new user with null
and \key{root} instances, changing a user's password, and adding a new
service instance.  First I run \id{ksu2} to become the superuser and
then I run the \id{/kerberos/kdb\_edit.sh} script.  A \qt{<cr>}
indicates that only a carriage return was entered in response to the
prompt.  A \qt{<password>} indicates that a password was entered in
response to the prompt.

\begin{verbatim}
aspen% ksu2
Password for principal tai.root: <password>     (does not echo)
Ticket expires in 2.0 hours
aspen-root# /kerberos/kdb_edit.sh
Opening database...
Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.

Principal name: kincl
Instance: <cr>

<Not found>, Create [y] ? <cr>

Principal: kincl, Instance: , kdc_key_ver: 1
New Password: <password>                (does not echo)
Verifying, please re-enter 
New Password: <password>                (does not echo)

Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 1999-12-31 ] ? <cr>
Max ticket lifetime (*5 minutes) [ 255 ] ? <cr>
Attributes [ 0 ] ? <cr>
Edit O.K.
\end{verbatim}

I have entered the principal name and password and used the defaults
for all other prompts.  Now I continue to add the \key{root} instance:

\begin{verbatim}
Principal name: kincl
Instance: root

<Not found>, Create [y] ? <cr>

Principal: kincl, Instance: root, kdc_key_ver: 1
New Password: <password>                (does not echo)
Verifying, please re-enter 
New Password: <password>                (does not echo)

Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 1999-12-31 ] ? <cr>
Max ticket lifetime (*5 minutes) [ 255 ] ? <cr>
Attributes [ 0 ] ? <cr>
Edit O.K.
\end{verbatim}

The only additional information that I have entered is the instance.

\begin{verbatim}
Principal name: tai
Instance: <cr>

Principal: tai, Instance: , kdc_key_ver: 1
Change password [n] ? y

New Password: <password>                (does not echo)
Verifying, please re-enter 
New Password: <password>                (does not echo)

Principal's new key version = 2
Expiration date (enter yyyy-mm-dd) [ 1999-12-31 ] ? <cr>
Max ticket lifetime (*5 minutes) [ 255 ] ? <cr>
Attributes [ 0 ] ? <cr>
Edit O.K.
\end{verbatim}

The principal \key{tai} already existed in the database.  So I was
prompted to change the password.  I confirmed and changed changed the
password.  I also had the opportunity to change the expiration date,
ticket lifetime and attributes.

Now I continue to add a new service:

\begin{verbatim}
Principal name: rcmd
Instance: vertigo.iag.hp.com

<Not found>, Create [y] ? <cr>

Principal: rcmd, Instance: vertigo.iag.hp.com, kdc_key_ver: 1
New Password: RANDOM                 (does not echo)
Verifying, please re-enter
New Password: RANDOM                 (does not echo)

Random password [y] ? <cr>

Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 1999-12-31 ] ? <cr>
Max ticket lifetime (*5 minutes) [ 255 ] ? <cr>
Attributes [ 0 ] ? <cr>
Edit O.K.
Principal name: <cr>
\end{verbatim}

I typed \qt{RANDOM} in uppercase to both password prompts.  Then I
confirmed the next prompt to assign a randomly-generated password to
this service instance.

\begin{verbatim}
OK to update slave servers [y or n]? y
Updating slave servers...

Start slave propagation: Sat Jan 27 18:20:32 1990
kenzo.IAG.HP.COM: success.
telford.IAG.HP.COM: success.


kenzo.IAG.HP.COM:		Succeeded
telford.IAG.HP.COM:		Succeeded
propagation finished, 0:00:03 elapsed
\end{verbatim}

After exiting from the \lit{kdb\_edit} program, the script prompts me
to update the slave servers.  I type \qt{y} to confirm and the
database is propagated to the slave servers.

Now I have to extract the service entries for \key{vertigo.iag.hp.com}
and install them in the file \lit{/usr/local/etc/srvtab} on that host.

\begin{verbatim}
aspen-root# ext_srvtab -n vertigo.iag.hp.com
Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Generating 'vertigo.iag.hp.com-new-srvtab'....
aspen-root# rcp vertigo.iag.hp.com-new-srvtab vertigo:/usr/local/etc/srvtab
aspen-root# krlogin vertigo
\end{verbatim}

While logged in on the master server \key{aspen}, I extracted the
service entries for \key{vertigo.iag.hp.com} and installed it on the
host.  Assuming that the \lit{inetd.conf} file on \key{kenzo} had
already been set up and \id{inetd} reconfigured, I can \id{krlogin} to
\key{vertigo.iag.hp.com}.

\begin{verbatim}
vertigo-root# ksrvutil list
Version    Principal
   1     rcmd.vertigo.iag.hp.com@IAG.HP.COM
\end{verbatim}

Using the \id{ksrvutil} program, I can see what service entries are in
the \lit{srvtab} file.

The \id{kdb\_util} program can show you the Kerberos database.  Here
is a partial listing of the output file generated by the command,
\begin{center}
\lit{kdb\_util dump output\_file}
\end{center}

\begin{verbatim}
rcmd kenzo.iag.hp.com 255 1 1 0 197f7c5c a5f8c35a 200001010459 198911140009 * *
krbtgt SDE-FC.HP.COM 255 1 1 0 a05f5155 d62c0883 200001010459 198912062205 * *
taisu * 255 1 2 0 d557eb2 63d97cd 200001010459 198909272015 * *
zephyr zephyr 255 1 1 0 197f7c5c a5f8c35a 200001010459 198911292134 * *
tai root 255 1 2 0 d557eb2 63d97cd 200001010459 198910041609 * *
kincl * 255 1 4 0 69a6b154 133b3235 200001010459 199001130148 kincl *
changepw aspen.iag.hp.com 255 1 1 0 197f7c5c a5f8c35a 200001010459 198909162157 db_creation *
default * 255 1 1 0 0 0 200001010459 198909162157 db_creation *
rcmd aspen.iag.hp.com 255 1 1 0 e02a4f83 f603fe87 200001010459 198909162159 * *
K M 255 1 1 0 22dcc9e3 2f328881 200001010459 198909162157 db_creation *
rcmd vertigo.iag.hp.com 255 1 1 0 197f7c5c a5f8c35a 200001010459 198911230341 * *
kincl root 255 1 4 0 542a46c6 74c53822 200001010459 199001130149 kincl root
rcmd telford.iag.hp.com 255 1 1 0 e02a4f83 f603fe87 200001010459 198909162158 * *
krbtgt IAG.HP.COM 255 1 1 0 197f7c5c a5f8c35a 200001010459 198909162157 db_creation *
tai * 255 1 9 0 d557eb2 63d97cd 200001010459 198911090150 tai *
\end{verbatim}

This file can be edited in as much as you can delete and modify
entries.  The first and second fields are the principal name and
instance.  A \qt{*} in the instance field indicates a null instance.
The third field is the maximum ticket lifetime in five minute units.
The last two fields are the principal and instance of the person who
last modified the entry with the \id{kadmin} program.  The other
fields should not be modified.  The primary use in editing this file
is to delete entries and modify instances.

The edited file can be loaded as the new Kerberos database using the
command,
\begin{center}
\lit{kdb\_util load output\_file}
\end{center}
You should use the \lit{/kerberos/ked\_edit.sh} script to delete
entries since it does all this and takes care of propagating the
database to the slave servers.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
