This is /usr/src/kerberosIV/doc/obj/kth-krb.info, produced by makeinfo
version 4.0 from /usr/src/kerberosIV/doc/../src/doc/kth-krb.texi.

INFO-DIR-SECTION Kerberos
START-INFO-DIR-ENTRY
* Kth-krb: (kth-krb).           The Kerberos IV distribution from KTH
END-INFO-DIR-ENTRY


File: kth-krb.info,  Node: Top,  Next: Introduction,  Prev: (dir),  Up: (dir)

KTH-krb
*******

* Menu:

* Introduction::
* What is Kerberos?::
* Installing programs::
* How to set up a realm::
* Resolving frequent problems::
* Acknowledgments::
* Index::

 --- The Detailed Node Listing ---

Installing programs

* Installing from source::
* Installing a binary distribution::
* Finishing the installation::

How to set up a realm

* How to set up the kerberos server::
* Install the client programs::
* Install the kerberised services::
* Install a slave kerberos server::
* Cross-realm functionality ::

How to set up the kerberos server

* Choose a realm name::
* Choose a kerberos server::
* Install the configuration files::
* Install the /etc/services::
* Install the kerberos server::
* Set up the server::
* Add a few important principals::
* Start the server::
* Try to get tickets::
* Create initial ACL for the admin server::
* Start the admin server::
* Add users to the database::
* Automate the startup of the servers::

Resolving frequent problems

* Problems with firewalls::
* Common error messages::
* Is Kerberos year 2000 safe?::


File: kth-krb.info,  Node: Introduction,  Next: What is Kerberos?,  Prev: Top,  Up: Top

Introduction
************

This is an attempt at documenting the Kerberos 4 distribution from
Kungliga Tekniska Högskolan (the Royal Institute of Technology in
Stockholm, Sweden). This distribution is based on eBones, but has been
improved in many ways. It is more portable, and several new features
have been added. It should run on any reasonably modern unix-like
system.

In addition, some part compile and work on:

   * OS/2 with EMX

   * Windows 95/NT with gnu-win32 (with the proper amount of magic the
     libraries should compile with Microsoft C as well)

It should work on anything that is almost POSIX, has an ANSI C
compiler, a dbm library (for the server side), and BSD Sockets.

A web-page is available at <http://www.pdc.kth.se/kth-krb/>.

Bug reports
===========

If you find bugs in the version shipped with OpenBSD, please submit a
bug report using the `sendbug' utility.

If you cannot build the programs or they do not behave as you think they
should, please send us a bug report.  The bug report should be sent to
`<kth-krb-bugs@pdc.kth.se>'.  Please include information on what
machine and operating system (including version) you are running, what
you are trying to do, what happens, what you think should have happened,
an example for us to repeat, the output you get when trying the example,
and a patch for the problem if you have one.  Please make any patches
with `diff -u' or `diff -c'.  The more detailed the bug report is, the
easier it will be for us to reproduce, understand, and fix it.

Suggestions, comments and other non bug reports are welcome.  Send them
to `<kth-krb@pdc.kth.se>'.


File: kth-krb.info,  Node: What is Kerberos?,  Next: Installing programs,  Prev: Introduction,  Up: Top

What is Kerberos?
*****************

     Now this Cerberus had three heads of dogs,
             the tail of a dragon, and on his back the
             heads of all sorts of snakes.
             -- Pseudo-Apollodorus Library 2.5.12

Kerberos is a system for authenticating users and services on a network.
It is built upon the assumption that the network is "unsafe".  For
example, data sent over the network can be eavesdropped and altered, and
addresses can also be faked.  Therefore they cannot be used for
authentication purposes.

Kerberos is a trusted third-party service.  That means that there is a
third party (the kerberos server) that is trusted by all the entities on
the network (users and services, usually called "principals").  All
principals share a secret password (or key) with the kerberos server and
this enables principals to verify that the messages from the kerberos
server are authentic.  Thus trusting the kerberos server, users and
services can authenticate each other.

Basic mechanism
===============

In Kerberos, principals use "tickets" to prove that they are who they
claim to be. In the following example, A is the initiator of the
authentication exchange, usually a user, and B is the service that A
wishes to use.

To obtain a ticket for a specific service, A sends a ticket request to
the kerberos server. The request basically contains A's and B's names.
The kerberos server checks that both A and B are valid principals.

Having verified the validity of the principals, it creates a packet
containing A's and B's names, A's network address (A<ADDR>), the
current time (T<ISSUE>), the lifetime of the ticket (LIFE), and a
secret "session key" (K<AB>). This packet is encrypted with B's secret
key (K<B>).  The actual ticket (T<AB>) looks like this: ({A, B,
A<ADDR>, T<ISSUE>, LIFE, K<AB>}K<B>).

The reply to A consists of the ticket (T<AB>), B's name, the current
time, the lifetime of the ticket, and the session key, all encrypted in
A's secret key ({B, T<ISSUE>, LIFE, K<AB>, T<AB>}K<A>). A decrypts the
reply and retains it for later use.


Before sending a message to B, A creates an authenticator consisting of
A's name, A's address, the current time, and a "checksum" chosen by A,
all encrypted with the secret session key ({A, A<ADDR>, T<CURRENT>,
CHECKSUM}K<AB>). This is sent together with the ticket received from
the kerberos server to B.  Upon reception, B decrypts the ticket using
B's secret key.  Since the ticket contains the session key that the
authenticator was encrypted with, B can now also decrypt the
authenticator. To verify that A really is A, B now has to compare the
contents of the ticket with that of the authenticator. If everything
matches, B now considers A as properly authenticated.

Different attacks
=================

Impersonating A
---------------

An impostor, C could steal the authenticator and the ticket as it is
transmitted across the network, and use them to impersonate A. The
address in the ticket and the authenticator was added to make it more
difficult to perform this attack.  To succeed C will have to either use
the same machine as A or fake the source addresses of the packets. By
including the time stamp in the authenticator, C does not have much
time in which to mount the attack.

Impersonating B
---------------

C can masquerade B's network address, and when A sends her credentials,
C just pretend to verify them. C can't be sure that she is talking to A.

Defense strategies
==================

It would be possible to add a "replay cache" to the server side.  The
idea is to save the authenticators sent during the last few minutes, so
that B can detect when someone is trying to retransmit an already used
message. This is somewhat impractical (mostly regarding efficiency),
and is not part of Kerberos 4; MIT Kerberos 5 contains it.

To authenticate B, A might request that B sends something back that
proves that B has access to the session key. An example of this is the
checksum that A sent as part of the authenticator. One typical
procedure is to add one to the checksum, encrypt it with the session
key and send it back to A.  This is called "mutual authentication".

The session key can also be used to add cryptographic checksums to the
messages sent between A and B (known as "message integrity").
Encryption can also be added ("message confidentiality"). This is
probably the best approach in all cases.

Further reading
===============

The original paper on Kerberos from 1988 is `Kerberos: An
Authentication Service for Open Network Systems', by Jennifer Steiner,
Clifford Neuman and Jeffrey I. Schiller.

A less technical description can be found in `Designing an
Authentication System: a Dialogue in Four Scenes' by Bill Bryant, also
from 1988.

These and several other documents can be found on the KTH-KRB web-page.


File: kth-krb.info,  Node: Installing programs,  Next: How to set up a realm,  Prev: What is Kerberos?,  Up: Top

Installing programs
*******************

* Menu:

* Installing from source::
* Installing a binary distribution::
* Finishing the installation::
* .klogin::


File: kth-krb.info,  Node: Installing from source,  Next: Installing a binary distribution,  Prev: Installing programs,  Up: Installing programs

Installing from source
======================

KerberosIV is by default built by the standard `make build' procedure,
so normally you don't need to do anything special.  But if you're
upgrading from OpenBSD 2.6 or earlier, the following steps may be
necessary:

Obtain and build the latest usr.bin/compile_et.
          # cd /usr/src/usr.bin/compile_et
          # make clean && make depend && make && make install

Obtain and build the latest lib/libcom_err.
          # cd /usr/src/lib/libcom_err
          # make clean && make depend && make && make install

If you are not doing a complete make build, regenerate the Kerberos header files, and then rebuild Kerberos:
          # rm -r /usr/include/kerberosIV/*
          # cd /usr/src
          # make includes
          # cd /usr/src/kerberosIV
          # make cleandir && make depend && make && make install

Otherwise, simply restart your make build.

File: kth-krb.info,  Node: Installing a binary distribution,  Next: Finishing the installation,  Prev: Installing from source,  Up: Installing programs

Installing a binary distribution
================================

OpenBSD is shipped with KerberosIV builtin, so no installation is
necessary.


File: kth-krb.info,  Node: Finishing the installation,  Next: .klogin,  Prev: Installing a binary distribution,  Up: Installing programs

Finishing the installation
==========================

The only program that needs to be installed setuid to root is `su'.

If `rlogin' and `rsh' are setuid to root they will fall back to
non-kerberised protocols if the kerberised ones fail for some reason.
The old protocols use reserved ports as security, and therefore the
programs have to be setuid to root. If you don't need this
functionality consider turning off the setuid bit.


File: kth-krb.info,  Node: .klogin,  Prev: Finishing the installation,  Up: Installing programs

Each user can have an authorization file `~USER/.klogin' that
determines what principals can login as that user.  It is similar to the
`~user/.rhosts' except that it does not use IP and privileged-port
based authentication.  If this file does not exist, the user herself
`user@LOCALREALM' will be allowed to login.  Supplementary local realms
(*note Install the configuration files::) also apply here.  If the file
exists, it should contain the additional principals that are to be
allowed to login as the local user USER.

This file is consulted by most of the daemons (`rlogind', `rshd',
`ftpd', `telnetd', `popper', `kauthd', and `kxd') to determine if the
principal requesting a service is allowed to receive it.  It is also
used by `su', which is a good way of keeping an access control list
(ACL) on who is allowed to become root.  Assuming that `~root/.klogin'
contains:

     nisse.root@FOO.SE
     lisa.root@FOO.SE

both nisse and lisa will be able to su to root by entering the password
of their root instance.  If that fails or if the user is not listed in
`~root/.klogin', `su' falls back to the normal policy of who is
permitted to su.  Also note that that nisse and lisa can login with
e.g. `telnet' as root provided that they have tickets for their root
instance.


File: kth-krb.info,  Node: How to set up a realm,  Next: Resolving frequent problems,  Prev: Installing programs,  Up: Top

How to set up a realm
*********************

     	Who willed you? or whose will stands but mine?
     	There's none protector of the realm but I.
     	Break up the gates, I'll be your warrantize.
     	Shall I be flouted thus by dunghill grooms?
             -- King Henry VI, 6.1

* Menu:

* How to set up the kerberos server::
* Install the client programs::
* Install the kerberised services::
* Install a slave kerberos server::
* Cross-realm functionality ::


File: kth-krb.info,  Node: How to set up the kerberos server,  Next: Install the client programs,  Prev: How to set up a realm,  Up: How to set up a realm

How to set up the kerberos server
=================================

* Menu:

* Choose a realm name::
* Choose a kerberos server::
* Install the configuration files::
* Install the /etc/services::
* Install the kerberos server::
* Set up the server::
* Add a few important principals::
* Start the server::
* Try to get tickets::
* Create initial ACL for the admin server::
* Start the admin server::
* Add users to the database::
* Automate the startup of the servers::


File: kth-krb.info,  Node: Choose a realm name,  Next: Choose a kerberos server,  Prev: How to set up the kerberos server,  Up: How to set up the kerberos server

Choose a realm name
-------------------

A realm is an administrative domain.  Kerberos realms are usually
written in uppercase and consist of a Internet domain name(1).  Call
your realm the same as your Internet domain name if you do not have
strong reasons for not doing so.  It will make life easier for you and
everyone else.

---------- Footnotes ----------

(1) Using lowercase characters in the realm name might break in
mysterious ways. This really should have been fixed, but has not.


File: kth-krb.info,  Node: Choose a kerberos server,  Next: Install the configuration files,  Prev: Choose a realm name,  Up: How to set up the kerberos server

Choose a kerberos server
------------------------

You need to choose a machine to run the kerberos server program.  If
the kerberos database residing on this host is compromised, your entire
realm will be compromised.  Therefore, this machine must be as secure
as possible.  Preferably it should not run any services other than
Kerberos.  The secure-minded administrator might only allow logins on
the console.

This machine has also to be reliable.  If it is down, you will not be
able to use any kerberised services unless you have also configured a
slave server (*note Install a slave kerberos server::).

Running the kerberos server requires very little CPU power and a small
amount of disk. An old PC with some hundreds of megabytes of free disk
space should do fine. Most of the disk space will be used for various
logs.


File: kth-krb.info,  Node: Install the configuration files,  Next: Install the /etc/services,  Prev: Choose a kerberos server,  Up: How to set up the kerberos server

Install the configuration files
-------------------------------

There are two important configuration files: `/etc/kerberosIV/krb.conf'
and `/etc/kerberosIV/krb.realms'.

The `krb.conf' file determines which machines are servers for different
realms.  The format of this file is:

     THIS.REALM
     SUPP.LOCAL.REALM
     THIS.REALM              kerberos.this.realm admin server
     THIS.REALM              kerberos-1.this.realm
     SUPP.LOCAL.REALM        kerberos.supp.local.realm admin server
     ANOTHER.REALM           kerberos.another.realm

The first line defines the name of the local realm. The next few lines
optionally defines supplementary local realms.

If the first character on the first line of `krb.conf' is `#', the
KerberosIV subsystem is disabled. (This is an OpenBSD specific addition)

The rest of the file defines the names of the kerberos servers and the
database administration servers for all known realms. You can define
any number of kerberos slave servers similar to the one defined on line
four. Clients will try to contact servers in listed order.

The `admin server' clause at the first entry states that this is the
master server (the one to contact when modifying the database, such as
changing passwords). There should be only one such entry for each realm.

In the original MIT Kerberos 4 (as in most others), the server
specification could only take the form of a host-name. To facilitate
having kerberos servers in odd places (such as behind a firewall),
support has been added for ports other than the default (750), and
protocols other than UDP.

The formal syntax for an entry is now `[PROTO/]HOST[:PORT]'. PROTO is
either `UDP', `TCP', or `HTTP', and PORT is the port to talk to.
Default value for PROTO is `UDP' and for PORT whatever `kerberos-iv' is
defined to be in `/etc/services' or 750 if undefined. If PROTO is
`HTTP', the default port is 80. An `http' entry may also be specified
in URL format.

If the information about a realm is missing from the `krb.conf' file,
or if the information is wrong, the following methods will be tried in
order.

  1. If you have an SRV-record (`RFC 2052') for your realm it will be
     used. This record should be of the form
     `kerberos-iv.PROTOCOL.REALM', where PROTO is either `UDP', `TCP',
     or `HTTP'. (Note: the current implementation does not look at
     priority or weight when deciding which server to talk to.)

  2. If there isn't any SRV-record, it tries to find a TXT-record for
     the same domain. The contents of the record should have the same
     format as the host specification in `krb.conf'. (Note: this is a
     temporary solution if your name server doesn't support SRV
     records. The clients should work fine with SRV records, so if your
     name server supports them, they are very much preferred.)

  3. If no valid kerberos server is found, it will try to talk UDP to
     the service `kerberos-iv' with fall-back to port 750 with
     `kerberos.REALM' (which is also assumed to be the master server),
     and then `kerberos-1.REALM', `kerberos-2.REALM', and so on.

SRV records have been supported in BIND since 4.9.5T2A.  An example
would look like the following in the zone file:

     kerberos-iv.udp.foo.se.  1M IN SRV  1 0 750 kerberos-1.foo.se.
     kerberos-iv.udp.foo.se.  1M IN SRV  0 0 750 kerberos.foo.se.

We strongly recommend that you add a CNAME `kerberos.REALM' pointing to
your kerberos master server.

The `krb.realms' file is used to find out what realm a particular host
belongs to.  An example of this file could look like:

     this.realm            THIS.REALM
     .this.realm           THIS.REALM
     foo.com               SOME.OTHER.REALM
     www.foo.com           A.STRANGE.REALM
     .foo.com              FOO.REALM

Entries starting with a dot are taken as the name of a domain. Entries
not starting with a dot are taken as a host-name. The first entry
matched is used. The entry for `this.realm' is only necessary if there
is a host named `this.realm'.

If no matching realm is found in `krb.realms', DNS is searched for the
correct realm. For example, if we are looking for host `a.b.c',
`krb4-realm.a.b.c' is first tried and then `krb4-realm.b.c' and so on.
The entry should be a TXT record containing the name of the realm, such
as:

     krb4-realm.pdc.kth.se.  7200    TXT     "NADA.KTH.SE"

If this didn't help the domain name sans the first part in uppercase is
tried.

The plain vanilla version of Kerberos doesn't have any fancy methods of
getting realms and servers so it is generally a good idea to keep
`krb.conf' and `krb.realms' up to date.

In addition to these commonly used files, `/etc/kerberosIV/krb.extra'
holds some things that are not normally used. It consists of a number of
`VARIABLE = VALUE' pairs, blank lines and lines beginning with a hash
(#) are ignored.

The currently defined variables are:

`kdc_timeout'
     The time in seconds to wait for an answer from the KDC (the
     default is 4 seconds).

`kdc_timesync'
     This flag enables storing of the time differential to the KDC when
     getting an initial ticket. This differential is used later on to
     compute the correct time. This can help if your machine doesn't
     have a working clock.

`firewall_address'
     The IP address that hosts outside the firewall see when connecting
     from within the firewall. If this is specified, the code will try
     to compute the value for `reverse_lsb_test'.

`krb4_proxy'
     When getting tickets via HTTP, this specifies the proxy to use. The
     default is to speak directly to the KDC.

`krb_default_tkt_root'
     The default prefix for ticket files.  The default is `/tmp/tkt'.
     Normally the uid or tty is appended to this prefix.

`krb_default_keyfile'
     The file where the server keys are stored, the default is
     `/etc/kerberosIV/srvtab'.

`nat_in_use'
     If the client is behind a Network Address Translator (NAT).

`reverse_lsb_test'
     Reverses the test used by `krb_mk_safe', `krb_rd_safe',
     `krb_mk_priv', and `krb_rd_priv' to compute the ordering of the
     communicating hosts. This test can cause truble when using
     firewalls.


File: kth-krb.info,  Node: Install the /etc/services,  Next: Install the kerberos server,  Prev: Install the configuration files,  Up: How to set up the kerberos server

Updating /etc/services
----------------------

The `/etc/services' in OpenBSD has the standard services defined, so
if, for some reason, you would need to change it you can do that here.


File: kth-krb.info,  Node: Install the kerberos server,  Next: Set up the server,  Prev: Install the /etc/services,  Up: How to set up the kerberos server

Install the kerberos server
---------------------------

You should have already chosen the machine where you want to run the
kerberos server and the realm name.  The machine should also be as
secure as possible (*note Choose a kerberos server::) before installing
the kerberos server.  In this example, we will install a kerberos server
for the realm `FOO.SE' on a machine called `hemlig.foo.se'.


File: kth-krb.info,  Node: Set up the server,  Next: Add a few important principals,  Prev: Install the kerberos server,  Up: How to set up the kerberos server

Setup the server
----------------

Login as root on the console of the kerberos server. Then, to create the
database, run `kdb_init':

     hemlig# kdb_init
     Realm name [default  FOO.SE ]:
     You will be prompted for the database Master Password.
     It is important that you NOT FORGET this password.
     
     Enter Kerberos master password:
     Verifying password
     Enter Kerberos master password:

If you have set up the configuration files correctly, `kdb_init' should
choose the correct realm as the default, otherwise a (good) guess is
made.  Enter the master password.

This password will only be used for encrypting the kerberos database on
disk and for generating new random keys.  You will not have to remember
it, only to type it again when you run `kstash'.  Choose something long
and random.  Now run `kstash' using the same password:

     hemlig# kstash
     
     Enter Kerberos master password:
     
     Current Kerberos master key version is 1.
     
     Master key entered.  BEWARE!
     Wrote master key to /etc/kerberosIV/master_key

After entering the same master password it will be saved in the file
`/etc/kerberosIV/master_key' and the kerberos server will read it when
needed. Write down the master password and put it in a sealed envelope
in a safe, you might need it if your disk crashes or should you want to
set up a slave server.

`kdb_init' initializes the database with a few entries:

`krbtgt.REALM'
     The key used for authenticating to the kerberos server.

`changepw.kerberos'
     The key used for authenticating to the administrative server, i.e.
     when adding users, changing passwords, and so on.

`default'
     This entry is copied to new items when these are added.  Enter
     here the values you want new entries to have, particularly the
     expiry date.

`K.M'
     This is the master key and it is only used to verify that the
     master key that is saved un-encrypted in
     `/etc/kerberosIV/master_key' is correct and corresponds to this
     database.

`kstash' only reads the master password and writes it to
`/etc/kerberosIV/master_key'.  This enables the kerberos server to
start without you having to enter the master password.  This file
(`/etc/kerberosIV/master_key') is only readable by root and resides on
a "secure" machine.


File: kth-krb.info,  Node: Add a few important principals,  Next: Start the server,  Prev: Set up the server,  Up: How to set up the kerberos server

Add a few important principals
------------------------------

Now the kerberos database has been created, containing only a few
principals.  The next step is to add a few more so that you can test
that it works properly and so that you can administer your realm without
having to use the console on the kerberos server.  Use `kdb_edit' to
edit the kerberos database directly on the server.

`kdb_edit' is intended as a bootstrapping and fall-back mechanism for
editing the database.  For normal purposes, use the `kadmin' program
(*note Add users to the database::).

The following example shows the adding of the principal `nisse.admin'
into the kerberos database.  This principal is used by `nisse' when
administrating the kerberos database.  Later on the normal principal
for `nisse' will be created.  Replace `nisse' and `password' with your
own username and password.

     hemlig# kdb_edit -n
     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: <nisse>
     Instance: <admin>
     
     <Not found>, Create [y] ? <>
     
     Principal: nisse, Instance: admin, kdc_key_ver: 1
     New Password: <password>
     Verifying password
     New Password: <password>
     
     Principal's new key version = 1
     Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? <>
     Max ticket lifetime (*5 minutes) [ 255 ] ? <>
     Attributes [ 0 ] ? <>
     Edit O.K.
     Principal name: <>

`kdb_edit' will loop until you hit the `return' key at the "Principal
name" prompt. Now you have added nisse as an administrator.


File: kth-krb.info,  Node: Start the server,  Next: Try to get tickets,  Prev: Add a few important principals,  Up: How to set up the kerberos server

Start the server
----------------

     hemlig# /usr/libexec/kerberos &
     Kerberos server starting
     Sleep forever on error
     Log file is /var/log/kerberos.log
     Current Kerberos master key version is 1.
     
     Master key entered.  BEWARE!
     
     Current Kerberos master key version is 1
     Local realm: FOO.SE


File: kth-krb.info,  Node: Try to get tickets,  Next: Create initial ACL for the admin server,  Prev: Start the server,  Up: How to set up the kerberos server

Try to get tickets
------------------

You can now verify that these principals have been added and that the
server is working correctly.

     hemlig# kinit
     eBones International (hemlig.foo.se)
     Kerberos Initialization
     Kerberos name: <nisse.admin>
     Password: <password>

If you do not get any error message from `kinit', then everything is
working (otherwise, see *Note Common error messages::).  Use `klist' to
verify the tickets you acquired with `kinit':

     hemlig# klist
     Ticket file:    /tmp/tkt0
     Principal:      nisse.admin@FOO.SE
     
     Issued           Expires          Principal
     May 24 21:06:03  May 25 07:06:03  krbtgt.FOO.SE@FOO.SE


File: kth-krb.info,  Node: Create initial ACL for the admin server,  Next: Start the admin server,  Prev: Try to get tickets,  Up: How to set up the kerberos server

Create initial ACL for the admin server
---------------------------------------

The admin server, `kadmind', uses a series of files to determine who has
the right to perform certain operations.  The files are:
`admin_acl.add', `admin_acl.get', `admin_acl.del', and `admin_acl.mod'.
Create these with `nisse.admin@FOO.SE' as the contents.

     hemlig# echo "nisse.admin@FOO.SE" >> /etc/kerberosIV/admin_acl.add
     hemlig# echo "nisse.admin@FOO.SE" >> /etc/kerberosIV/admin_acl.get
     hemlig# echo "nisse.admin@FOO.SE" >> /etc/kerberosIV/admin_acl.mod
     hemlig# echo "nisse.admin@FOO.SE" >> /etc/kerberosIV/admin_acl.del

Later on you may wish to add more users with administration privileges.
Make sure that you create both the administration principals and add
them to the admin server ACL.


File: kth-krb.info,  Node: Start the admin server,  Next: Add users to the database,  Prev: Create initial ACL for the admin server,  Up: How to set up the kerberos server

Start the admin server
----------------------

     hemlig# /usr/libexec/kadmind &
     KADM Server KADM0.0A initializing
     Please do not use 'kill -9' to kill this job, use a
     regular kill instead
     
     Current Kerberos master key version is 1.
     
     Master key entered.  BEWARE!


File: kth-krb.info,  Node: Add users to the database,  Next: Automate the startup of the servers,  Prev: Start the admin server,  Up: How to set up the kerberos server

Add users to the database
-------------------------

Use the `kadmin' client to add users to the database:

     hemlig# kadmin -p nisse.admin -m
     Welcome to the Kerberos Administration Program, version 2
     Type "help" if you need it.
     admin:  <add nisse>
     Admin password: <nisse.admin's password>
     Maximum ticket lifetime?  (255)  [Forever]
     Attributes?  [0x00]
     Expiration date (enter yyyy-mm-dd) ?  [Sat Jan  1 05:59:00 2000]
     Password for nisse:
     Verifying password Password for nisse:
     nisse added to database.

Add whatever other users you want to have in the same way.  Verify that
a user is in the database and check the database entry for that user:

     admin:  <get nisse>
     Info in Database for nisse.:
     Max Life: 255 (Forever)   Exp Date: Sat Jan  1 05:59:59 2000
     
     Attribs: 00  key: 0 0
     admin:  <^D>
     Cleaning up and exiting.


File: kth-krb.info,  Node: Automate the startup of the servers,  Prev: Add users to the database,  Up: How to set up the kerberos server

Automate the startup of the servers
-----------------------------------

To automatically startup the servers on system boot, change the line
`kerberos_server=NO' to `kerberos_server=YES' in the file `/etc/rc.conf'


File: kth-krb.info,  Node: Install the client programs,  Next: Install the kerberised services,  Prev: How to set up the kerberos server,  Up: How to set up a realm

Install the client programs
===========================

Making a machine a kerberos client only requires a few steps.  First you
might need to change the configuration files as with the kerberos
server.  (*note Install the configuration files::

You should also verify that the local time on the client is synchronised
with the time on the kerberos server by some means. The maximum allowed
time difference between the participating servers and a client is 5
minutes.  One good way to synchronize the time is NTP (Network Time
Protocol), see /usr/ports/sysutils/xntpd.

If you need to run the client programs on a machine where you do not
have root-access, you can hopefully just use the binaries and no
configuration will be needed.  The heuristics used are mentioned above
(see *Note Install the configuration files::).  If this is not the case
and you need to have `krb.conf' and/or `krb.realms', you can copy them
into a directory of your choice and set the environment variable
KRBCONFDIR to point at this directory.

To test the client functionality, run the `kinit' program:

     foo$ kinit
     eBones International (foo.foo.se)
     Kerberos Initialization
     Kerberos name: <nisse>
     Password: <password>
     
     foo$ klist
     Ticket file:    /tmp/tkt4711
     Principal:      nisse@FOO.SE
     
     Issued           Expires          Principal
     May 24 21:06:03  May 25 07:06:03  krbtgt.FOO.SE@FOO.SE


File: kth-krb.info,  Node: Install the kerberised services,  Next: Install a slave kerberos server,  Prev: Install the client programs,  Up: How to set up a realm

Install the kerberised services
===============================

These includes `rsh', `rlogin', `telnet', `ftp', `rxtelnet', and so on.

First follow the steps mentioned in the prior section to make it a
client and verify its operation.  Change `inetd.conf' next to use the
new daemons.

You should at this point decide what services you want to run on each
machine.

rsh, rlogin, and rcp
--------------------

These exist in kerberised versions and "old-style" versions.  The
different versions use different port numbers, so you can choose none,
one, or both.  If you do not want to use "old-style" r* services, you
can let the programs output the text "Remote host requires Kerberos
authentication" instead of just refusing connections to that port.
This is enabled with the `-v' option.  The kerberised services exist in
encrypted and non-encrypted versions.  The encrypted services have an
"e" prepended to the name and the programs take `-x' as an option
indicating encryption.

Our recommendation is to only use the kerberised services and give
explanation messages for the old ports.

telnet
------

The telnet service always uses the same port and negotiates as to which
authentication method should be used.  The `telnetd' program has an
option "-a user" that only allows kerberised and authenticated
connections.  If this is not included, it falls back to using clear text
passwords.  For obvious reasons, we recommend that you enable this
option.

ftp
---

The ftp service works as telnet does, with just one port being used.  By
default only kerberos authenticated connections are allowed.  You can
specify additional levels that are thus allowed with these options:

`-a ftp'
     Allow anonymous login (as user "ftp" or "anonymous").

`-a safe'
     The same as `-a ftp', for backwards compatibility.

`-a plain'
     Allow clear-text passwords.

`-a none'
     The same as `-a ftp -a plain'.

`-a user'
     A no-op, also there for backwards compatibility reasons.

When running anonymous ftp you should read the man page on `ftpd' which
explains how to set it up.

pop
---

The Post Office Protocol (POP) is used to retrieve mail from the mail
hub.  The `popper' program implements the standard POP3 protocol and
the kerberised KPOP.  Use the `-k' option to run the kerberos version
of the protocol. This service should only be run on your mail hub.

kx
--

`kx' allows you to run X over a kerberos-authenticated and encrypted
connection.  This program is used by `rxtelnet', `tenletxr', and
`rxterm'.

kauth
-----

This service allows you to create tickets on a remote host.  To enable
it just insert the corresponding line in `inetd.conf'.

srvtabs
=======

In the same way every user needs to have a password registered with the
kerberos server, every service needs to have a shared key with the
kerberos server.  The service keys are stored in a file, usually called
`/etc/kerberosIV/srvtab'.  This file should not be readable to anyone
but root, in order to keep the key from being divulged.  The name of
this principal in the kerberos database is usually the service name and
the hostname.  Examples of such principals are `pop.HOSTNAME' and
`rcmd.HOSTNAME'.  (rcmd comes from "remote command".)  Here is a list
of the most commonly used srvtab types and what programs use them.

rcmd.HOSTNAME
     rsh, rcp, rlogin, telnet, kauth, su, kx

rcmd.kerberos
     kprop

pop.HOSTNAME
     popper, movemail, push

sample.HOSTNAME
     sample_server, simple_server

changepw.kerberos
     kadmin, kpasswd

krbtgt.REALM
     kerberos (not stored in any srvtab)

ftp.HOSTNAME
     ftp (also tries with rcmd.HOSTNAME)

zephyr.zephyr
     Zephyr

afs or afs.CELLNAME
     Andrew File System

To create these keys you will use the the `ksrvutil' program.  Perform
the following:

     bar# ksrvutil -p nisse.admin get
     Name [rcmd]: <>
     Instance [bar]: <>
     Realm [FOO.SE]: <>
     Is this correct? (y,n) [y] <>
     Add more keys? (y,n) [n] <>
     Password for nisse.admin@FOO.SE: <nisse.admin's password>
     Written rcmd.bar
     rcmd.bar@FOO.SE
     Old keyfile in /etc/kerberosIV/srvtab.old.

Complete test of the kerberised services
----------------------------------------

Obtain a ticket on one machine (`foo') and use it to login with a
kerberised service to a second machine (`bar').  The test should look
like this if successful:

     foo$ kinit nisse
     eBones International (foo.foo.se)
     Kerberos Initialization for "nisse"
     Password: <nisse's password>
     foo$ klist
     Ticket file:    /tmp/tkt4711
     Principal:      nisse@FOO.SE
     
     Issued           Expires          Principal
     May 30 13:48:03  May 30 23:48:03  krbtgt.FOO.SE@FOO.SE
     foo$ telnet bar
     Trying 17.17.17.17...
     Connected to bar.foo.se
     Escape character is '^]'.
     [ Trying mutual KERBEROS4 ... ]
     [ Kerberos V4 accepts you ]
     [ Kerberos V4 challenge successful ]
     bar$

You can also try with `rsh', `rcp', `rlogin', `rlogin -x', and some
other commands to see that everything is working all right.


File: kth-krb.info,  Node: Install a slave kerberos server,  Next: Cross-realm functionality,  Prev: Install the kerberised services,  Up: How to set up a realm

Install a slave kerberos server
===============================

It is desirable to have at least one backup (slave) server in case the
master server fails. It is possible to have any number of such slave
servers but more than three usually doesn't buy much more redundancy.

First select a good server machine.  (*note Choose a kerberos server::).

On the master, add a `rcmd.kerberos' (note, it should be literally
"kerberos") principal (using `ksrvutil get'). The `kprop' program,
running on the master, will use this when authenticating to the
`kpropd' daemons running on the slave servers.  The `kpropd' on the
slave will use its `rcmd.hostname' key for authenticating the
connection from the master.  Therefore, the slave needs to have this
key in its srvtab, and it of course also needs to have enough of the
configuration files to act as a server.  See *Note Install the
kerberised services:: for information on how to do this.

To summarize, the master should have a key for `rcmd.kerberos' and the
slave one for `rcmd.hostname'.

The slave will need the same master key as you used at the master.

On your master server, create a file, e.g. `/etc/kerberosIV/slaves',
that contains the hostnames of your kerberos slave servers.

Start `kpropd' with `kpropd -i' on your slave servers.

On your master server, create a dump of the database and then propagate
it.

     foo# kdb_util slave_dump /etc/kerberosIV/slave_dump
     foo# kprop

You should now have copies of the database on your slave servers. You
can verify this by issuing `kdb_util dump FILE' on your slave servers,
and comparing with the original file on the master server. Note that
the entries will not be in the same order.

This procedure should be automated with a script run regularly by cron,
for instance once an hour.

Since the master and slave servers will use copies of the same
database, they need to use the same master key.  Add the master key on
the slave with `kstash'. (*note Set up the server::)

To start the kerberos server on slaves, you first have to copy the
master key from the master server. You can do this either by remembering
the master password and issuing `kstash', or you can just copy the
keyfile. Remember that if you copy the file, do so on a safe media, not
over the network. Good means include floppy or paper. Paper is better,
since it is easier to swallow afterwards.

The kerberos server should be started with `-s' on the slave servers.
This enables sanity checks, for example checking the time since the
last update from the master.

All changes to the database are made by `kadmind' at the master, and
then propagated to the slaves, so you should *not* run `kadmind' on the
slaves.

Finally add the slave servers to `/etc/kerberosIV/krb.conf'. The
clients will ask the servers in the order specified by that file.

Consider adding CNAMEs to your slave servers, see *Note Install the
configuration files::.


File: kth-krb.info,  Node: Cross-realm functionality,  Prev: Install a slave kerberos server,  Up: How to set up a realm

Cross-realm functionality
=========================

Suppose you are residing in the realm `MY.REALM', how do you
authenticate to a server in `OTHER.REALM'? Having valid tickets in
`MY.REALM' allows you to communicate with kerberised services in that
realm. However, the computer in the other realm does not have a secret
key shared with the kerberos server in your realm.

It is possible to add a shared key between two realms that trust each
other. When a client program, such as `telnet', finds that the other
computer is in a different realm, it will try to get a ticket granting
ticket for that other realm, but from the local kerberos server. With
that ticket granting ticket, it will then obtain service tickets from
the kerberos server in the other realm.

To add this functionality you have to add a principal to each realm. The
principals should be `krbtgt.OTHER.REALM' in `MY.REALM', and
`krbtgt.MY.REALM' in `OTHER.REALM'. The two different principals should
have the same key (and key version number).  Remember to transfer this
key in a safe manner. This is all that is required.

     blubb$ klist
     Ticket file:    /tmp/tkt3008
     Principal:      joda@NADA.KTH.SE
     
       Issued           Expires          Principal
     Jun  7 02:26:23  Jun  7 12:26:23  krbtgt.NADA.KTH.SE@NADA.KTH.SE
     blubb$ telnet agat.e.kth.se
     Trying 130.237.48.12...
     Connected to agat.e.kth.se.
     Escape character is '^]'.
     [ Trying mutual KERBEROS4 ... ]
     [ Kerberos V4 accepts you ]
     [ Kerberos V4 challenge successful ]
     Last login: Sun Jun  2 20:51:50 from emma.pdc.kth.se
     
     agat$ exit
     Connection closed by foreign host.
     blubb$ klist
     Ticket file:    /tmp/tkt3008
     Principal:      joda@NADA.KTH.SE
     
       Issued           Expires          Principal
     Jun  7 02:26:23  Jun  7 12:26:23  krbtgt.NADA.KTH.SE@NADA.KTH.SE
     Jun  7 02:26:50  Jun  7 12:26:50  krbtgt.E.KTH.SE@NADA.KTH.SE
     Jun  7 02:26:51  Jun  7 12:26:51  rcmd.agat@E.KTH.SE


File: kth-krb.info,  Node: Resolving frequent problems,  Next: Acknowledgments,  Prev: How to set up a realm,  Up: Top

Resolving frequent problems
***************************

* Menu:

* Problems with firewalls::
* Common error messages::
* Is Kerberos year 2000 safe?::


File: kth-krb.info,  Node: Problems with firewalls,  Next: Common error messages,  Prev: Resolving frequent problems,  Up: Resolving frequent problems

Problems with firewalls
=======================

A firewall is a network device that filters out certain types of packets
going from one side of the firewall to the other. A firewall is supposed
to solve the same kinds of problems as Kerberos (basically hindering
unauthorised network use). The difference is that Kerberos tries to
authenticate users, while firewall splits the network in a `secure'
inside, and an `insecure' outside.

Firewall people usually think that UDP is insecure, partly because many
`insecure' protocols use UDP. Since Kerberos by default uses UDP to send
and recieve packets, Kerberos and firewalls doesn't work very well
together.

The symptoms of trying to use Kerberos behind a firewall is that you
can't get any tickets (`kinit' exits with the infamous `Can't send
request' error message).

There are a few ways to solve these problems:

   * Convince your firewall administrator to open UDP port 750 or 88 for
     incoming packets. This usually turns out to be difficult.

   * Convince your firewall administrator to open TCP port 750 or 88 for
     outgoing connections. This can be a lot easier, and might already
     be enabled.

   * Use TCP connections over some non-standard port. This requires
     that you have to convince the administrator of the kerberos server
     to allow connections on this port.

   * Use HTTP to get tickets. Since web-stuff has become almost
     infinitely popular, many firewalls either has the HTTP port open,
     or has a HTTP proxy.

The last two methods might be considered to be offensive (since you are
not sending the `right' type of data in each port). You probably do best
in discussuing this with firewall administrator.

For information on how to use other protocols when communication with
KDC, see *Note Install the configuration files::.

It is often the case that the firewall hides addresses on the `inside',
so it looks like all packets are coming from the firewall. Since address
of the client host is encoded in the ticket, this can cause trouble. If
you get errors like `Incorrect network address', when trying to use the
ticket, the problem is usually becuase the server you are trying to
talk to sees a different address than the KDC did. If you experience
this kind of trouble, the easiest way to solve them is probably to try
some other mechanism to fetch tickets. You might also be able to
convince the administrator of the server that the two different
addresses should be added to the `/etc/kerberosIV/krb.equiv' file.


File: kth-krb.info,  Node: Common error messages,  Next: Is Kerberos year 2000 safe?,  Prev: Problems with firewalls,  Up: Resolving frequent problems

Common error messages
=====================

These are some of the more obscure error messages you might encounter:

`Time is out of bounds'
     The time on your machine differs from the time on either the
     kerberos server or the machine you are trying to login to. If it
     isn't obvious that this is the case, remember that all times are
     compared in UTC.

     On unix systems you usually can find out what the local time is by
     doing `telnet machine daytime'. This time (again, usually is the
     keyword) is with correction for time-zone and daylight savings.

     If you have problem keeping your clocks synchronized, consider
     using a time keeping system such as NTP (see also the discussion in
     *Note Install the client programs::).

`Ticket issue date too far in the future'
     The time on the kerberos server is more than five minutes ahead of
     the time on the server.

`Can't decode authenticator'
     This means that there is a mismatch between the service key in the
     kerberos server and the service key file on the specific machine.
     Either:
        * the server couldn't find a service key matching the request

        * the service key (or version number) does not match the key
          the packet was encrypted with

`Incorrect network address'
     The address in the ticket does not match the address you sent the
     request from. This happens on systems with more than one network
     address, either physically or logically. You can list addresses
     which should be considered equal in `/etc/kerberosIV/krb.equiv' on
     your servers.

     A note to programmers: a server should not pass `*' as the instance
     to `krb_rd_req'. It should try to figure out on which interface the
     request was received, for instance by using `k_getsockinst'.

     If you change addresses on your computer you invalidate any
     tickets you might have. The easiest way to fix this is to get new
     tickets with the new address.

`Message integrity error'
     The packet is broken in some way:
        * the lengths does not match the size of the packet, or

        * the checksum does not match the contents of the packet

`Can't send request'
     There is some problem contacting the kerberos server. Either the
     server is down, or it is using the wrong port (compare the entries
     for `kerberos-iv' in `/etc/services'). The client might also have
     failed to guess what kerberos server to talk to (check
     `/etc/kerberosIV/krb.conf' and `/etc/kerberosIV/krb.realms').

     One reason you can't contact the kerberos server might be because
     you're behind a firewall that doesn't allow kerberos packets to
     pass. For possible solutions to this see the firewall section
     above.

`kerberos: socket: Unable to open socket...'
     The kerberos server has to open four sockets for each interface.
     If you have a machine with lots of virtual interfaces, you run the
     risk of running out of file descriptors.  If that happens you will
     get this error message.

`ftp: User foo access denied'
     This usually happens because the user's shell is not listed in
     `/etc/shells'.

`Generic kerberos error'
     This is a generic catch-all error message.


File: kth-krb.info,  Node: Is Kerberos year 2000 safe?,  Prev: Common error messages,  Up: Resolving frequent problems

Is Kerberos year 2000 safe?
===========================

Yes.

A somewhat longer answer is that we can't think of anything that can
break. The protocol itself doesn't use time stamps in textual form, the
two-digit year problems in the original MIT code has been fixed (this
was a problem mostly with log files). The FTP client had a bug in the
command `newer' (which fetches a file if it's newer than what you
already got).

Another thing to look out for, but that isn't a Y2K problem per se, is
the expiration date of old principals. The MIT code set the default
expiration date for some new principals to 1999-12-31, so you might want
to check your database for things like this.

Now, the Y2038 problem is something completely different (but the
authors should have retired by then, presumably growing rowanberrys in
some nice and warm place).


File: kth-krb.info,  Node: Acknowledgments,  Next: Index,  Prev: Resolving frequent problems,  Up: Top

Acknowledgments
***************

People from the MIT Athena project wrote the original code that this is
based on. Kerberos 4 patch-level 9 was stripped of both the encryption
functions and the calls to them. This was exported from the US as the
"Bones" release.  Eric Young put back the calls and hooked in his
libdes, thereby creating the "eBones" release.

The "rcmd" programs where initially developed at the University of
California at Berkeley and then hacked on by the FreeBSD and NetBSD
projects.

Berkeley also wrote `ftp', `ftpd', `telnet', and `telnetd'.  The
authentication and encryption code of `telnet' and `telnetd' was added
by David Borman (then of Cray Research, Inc).  The encryption code was
removed when this was exported and then added back by Juha Eskelinen,
`<esc@magic.fi>'.

The `popper' was also a Berkeley program initially.

The `login' has the same origins but has received code written by
Wietse Venema at Eindhoven University of Technology, The Netherlands.

`movemail' was (at least partially) written by Jonathan Kamens,
`<jik@security.ov.com>', and is Copyright (C) 1986, 1991, 1992, 1993,
1994 Free Software Foundation, Inc.

`xnlock' was originally written by Dan Heller in 1985 for sunview.  The
X version was written by him in 1990.

Some of the functions in `libroken' also come from Berkeley by the way
of NetBSD/FreeBSD.

The code to handle the dynamic loading of the AFS module for AIX is
copyright (C) 1992 HELIOS Software GmbH 30159 Hannover, Germany.

`editline' was written by Simmule Turner and Rich Salz.

Bugfixes and code has been contributed by:
Derrick J Brashear
     `<shadow@dementia.org>'

Anders Gertz
     `<gertz@lysator.liu.se>'

Dejan Ilic
     `<svedja@lysator.liu.se>'

Kent Engström
     `<kent@lysator.liu.se>'

Simon Josefsson
     `<jas@pdc.kth.se>'

Robert Malmgren
     `<rom@incolumitas.se>'

Fredrik Ljungberg
     `<flag@astrogator.se>'

Joakim Fallsjö
     `jfa@pobox.se'

Lars Malinowsky
     `<lama@pdc.kth.se>'

Fabien Coelho
     `<coelho@cri.ensmp.fr>'

Chris Chiappa
     `<griffon+@cmu.edu>'

Gregory S. Stark
     `<gsstark@mit.edu>'

Love Hörnquist-Åstrand
     `<lha@stacken.kth.se>'

Daniel Staaf
     `<d96-dst@nada.kth.se>'

Magnus Ahltorp
     `<map@stacken.kth.se>'

Robert Burgess
     `<rb@stacken.kth.se>'

Lars Arvestad
     `<arve@nada.kth.se>'

Jörgen Wahlsten
     `<wahlsten@pathfinder.com>'

Daniel Staaf
     `<d96-dst@nada.kth.se>'

R Lindsay Todd
     `<toddr@rpi.edu>'

Åke Sandgren
     `<ake@cs.umu.se>'

Thomas Nyström
     `<thn@stacken.kth.se>'

and we hope that those not mentioned here will forgive us.
Ian Marsh `<ianm@sics.se>' removed the worst abuses of the English
language from this text.

Ilja Hallberg `<iha@incolumitas.se>' is still promising to help us
finish the documentation.

This work was supported in part by SUNET and the Centre for Parallel
Computers at KTH.

The port to Windows 95/NT was supported by the Computer Council at KTH
and done by Jörgen Karlsson `<d93-jka@nada.kth.se>'.

All the bugs were introduced by ourselves.


File: kth-krb.info,  Node: Index,  Prev: Acknowledgments,  Up: Top

Index
*****

* Menu:

* .klogin:                               .klogin.
* admin_acl.add:                         Create initial ACL for the admin server.
* admin_acl.del:                         Create initial ACL for the admin server.
* admin_acl.get:                         Create initial ACL for the admin server.
* admin_acl.mod:                         Create initial ACL for the admin server.
* authentication:                        What is Kerberos?.
* Bones:                                 Acknowledgments.
* confidentiality:                       What is Kerberos?.
* eBones:                                Acknowledgments.
* firewall:                              Problems with firewalls.
* firewall_address:                      Install the configuration files.
* ftp:                                   Install the kerberised services.
* ftpd:                                  .klogin.
* HTTP:                                  Problems with firewalls.
* integrity:                             What is Kerberos?.
* kadmin:                                Add users to the database.
* kadmind <1>:                           Create initial ACL for the admin server.
* kadmind:                               Start the admin server.
* kauth:                                 Install the kerberised services.
* kauthd:                                .klogin.
* kdb_edit:                              Add a few important principals.
* kdb_init:                              Set up the server.
* kdc_timeout:                           Install the configuration files.
* kdc_timesync:                          Install the configuration files.
* kerberos <1>:                          Choose a kerberos server.
* kerberos:                              Start the server.
* kinit:                                 Try to get tickets.
* klist:                                 Try to get tickets.
* kprop:                                 Install a slave kerberos server.
* kpropd:                                Install a slave kerberos server.
* krb.conf <1>:                          Install the configuration files.
* krb.conf:                              Install the client programs.
* krb.extra:                             Install the configuration files.
* krb.realms <1>:                        Install the configuration files.
* krb.realms:                            Install the client programs.
* krb4_proxy:                            Install the configuration files.
* krb_default_keyfile:                   Install the configuration files.
* krb_default_tkt_root:                  Install the configuration files.
* KRBCONFDIR:                            Install the client programs.
* ksrvutil:                              Install the kerberised services.
* kstash:                                Set up the server.
* kx:                                    Install the kerberised services.
* kxd:                                   .klogin.
* master server:                         Install the configuration files.
* NAT:                                   Install the configuration files.
* nat_in_use:                            Install the configuration files.
* Network Address Translator:            Install the configuration files.
* NTP.:                                  Install the client programs.
* popper <1>:                            Install the kerberised services.
* popper:                                .klogin.
* rc:                                    Automate the startup of the servers.
* rcp:                                   Install the kerberised services.
* realm:                                 Choose a realm name.
* replay cache:                          What is Kerberos?.
* reverse_lsb_test:                      Install the configuration files.
* rlogin <1>:                            Finishing the installation.
* rlogin:                                Install the kerberised services.
* rlogind:                               .klogin.
* rsh <1>:                               Install the kerberised services.
* rsh:                                   Finishing the installation.
* rshd:                                  .klogin.
* rxtelnet:                              Install the kerberised services.
* session key:                           What is Kerberos?.
* srvtab:                                Install the kerberised services.
* su <1>:                                .klogin.
* su:                                    Finishing the installation.
* supplementary local realms:            Install the configuration files.
* telnet:                                Install the kerberised services.
* telnetd <1>:                           Install the kerberised services.
* telnetd:                               .klogin.
* Year 2000:                             Is Kerberos year 2000 safe?.



Tag Table:
Node: Top275
Node: Introduction1429
Node: What is Kerberos?3145
Node: Installing programs8093
Node: Installing from source8367
Node: Installing a binary distribution9424
Node: Finishing the installation9724
Node: .klogin10301
Node: How to set up a realm11680
Node: How to set up the kerberos server12273
Node: Choose a realm name12903
Ref: Choose a realm name-Footnote-113432
Node: Choose a kerberos server13563
Node: Install the configuration files14555
Node: Install the /etc/services20899
Node: Install the kerberos server21259
Node: Set up the server21816
Node: Add a few important principals24290
Node: Start the server26152
Node: Try to get tickets26639
Node: Create initial ACL for the admin server27485
Node: Start the admin server28454
Node: Add users to the database28928
Node: Automate the startup of the servers30005
Node: Install the client programs30361
Node: Install the kerberised services31957
Node: Install a slave kerberos server37185
Node: Cross-realm functionality40271
Node: Resolving frequent problems42408
Node: Problems with firewalls42683
Node: Common error messages45357
Node: Is Kerberos year 2000 safe?48763
Node: Acknowledgments49733
Node: Index52896

End Tag Table
