[2115] in Kerberos-V5-bugs
my crib sheet on getting a slave server up and running with beta-6
daemon@ATHENA.MIT.EDU (Stephen M. Kenton)
Thu Jul 25 17:15:15 1996
From: "Stephen M. Kenton" <skenton@ou.edu>
To: <krb5-bugs@MIT.EDU>
Date: Thu, 25 Jul 1996 16:13:51 -0500
Here is a copy of my crib sheet for kerberos slave servers. I just
updated
it for beta-6. They inter-operated with the beta-5 and earlier versions.
I
figured that other people would probably appreciate it, rough though it
may be.
Building a Kerberos 5 beta-6 slave
The BETA6 stuff has been tested on Solaris 2.5 It works here, your
mileage may vary. Installing current (~4.9.3) versions of bind/named
can modify some of the include files and shared libraries. The
installs described below were done before upgrading to the new bind.
If you have already upgraded bind you will have a bit more lint
picking to do in the compile stage. You are on your own there. KRB5-6
Builds out of the box.
First you need a working master. Untar the source for Kerberos 5 and
configure it with:
cd src
./configure
or if you use gcc
./configure --with-cc=gcc --with-ccopts=-i
Now build the executables and install them in the standard places.
Fix any minor lint type problems (probably bind induced) until it
completes without errors. One caveat, ar and strip need to be in the
search path of the person building and installing it. The build can
be done anywhere by a non priv user, but the make install requres an
su root since it creates and fills the /usr/local/lib/krb5kdc
directory and requires files be added to /etc.
make
make check
make install
Set up the config files for your REALM and servers /etc/krb5.conf
Remember to create the database and start the kdc process on the
master (as described below).
Once you have kerberos 5 running as a master, build and install it
again on a second machine that is going to be the slave. There are
only a few differences between a master and a slave configuration.
You can actually run the master and slave on the same machine, which
is silly, but makes for easy testing. Just use the name of your
machine in place of both the master.backbone.uoknor.edu and
slave.backbone.uoknor.edu references below and skip the step to create
an empty database on the slave.
Slave propogation requires that the "formal" host name on the slave
be fully qualified and match the slave /etc/v5srvtab host entry and
the name supplied to the kprop command on the master either
explicitly by the user or via dns/resolver expansion of a shorter
nickname. This *CAN* be done with the hostname command, but pre
Solaris 2.5 systems prefer a short input/output to the hostname
command and stash it elsewhere. It is probably best to put the fully
qualified hostname *FIRST* in /etc/hosts on the slave like:
129.15.1.10 slave.backbone.uoknor.edu slave
Copy the config files from the master to the slave. Presumably they
are already correct and they should not require changes except for
the KDC. Create the file /krb5/kpropd.acl on the slave and add the
master entry. This is how the slave knows who it is supposed to
allow to update it.
host/master.backbone.uoknor.edu@OU.EDU
The service names, protocols etc. for various kerberos 5 services are
distributed in config-files/services.append. As the name implies
this file needs to be appended to the end of the /etc/services file
on both the master and the slave. The unofficial port 750 used by
kerberos 4 is still supported by kerberos 5 in addition to the
official port 88. They are currently interchangable at your option.
***If you are running NIS you must make and push the /etc/services map.***
The man page kpropd.8 incorrectly says that the service should be
called kprop. In fact is should be krb5_prop as mentioned above.
Edit /etc/inetd.conf on the slave and add the following entry for
krb5_prop which will cause kdb5_edit to be run when a database update
has been received. Your syntax may differ slighly depending on the
variant of the operating system. In this example the line is wrapped
to fit on the page. Enter it as a single line on your system.
krb5_prop stream tcp nowait root /usr/local/sbin/kpropd kpropd -p
/usr/local/sbin/kdb5_edit
Either reboot or restart inetd so that kpropd will be in effect without
rebooting.
ps -e | grep -i inet
kill -HUP <pid of inetd>
Upon receipt of a database transfer inetd will generate and execute the
command:
/usr/local/sbin/kdb5_edit -R "lddb /usr/local/lib/krb5kdc/from_master
/usr/local/lib/krb5kdc/principal"
Initialize an empty data base on the slave as follows:
Run /usr/local/sbin/kdb5_create and supply the realm password (from the
master) twice
Run /usr/local/sbin/kdb5_stash and supply the same password once more
The slave just needs an empty data base, the master requires
additional stuff. The kprop and kpropd programs use the generic host
access instance. Run kdb5_edit and create and export the host/master
host/slave instances like:
ark host/master.backbone.uoknor.edu
ark host/slave.backbone.uoknor.edu
xst master.backbone.uoknor.edu host
xst slave.backbone.uoknor.edu host
While you are at it, create an instance for yourself and dump the db like:
ank somename
supply the password twice
ddb /usr/local/lib/krb5kdc/slave_datatrans
quit
Now move/ftp/sneakernet the keytab files
master.backbone.uoknor.edu-new-srvtab and
slave.backbone.uoknor.edu-new-srvtab
to /etc/v5srvtab on the appropriate machines. This is how the master
and slave authenticate each other without using the about to be
updated kdc database. Be warned that using ftp is probably a bad
idea since it gives snoopers a chance grab the keytab data off the
wire. This would be equivalent to them getting certain passwords.
mv master.backbone.uoknor.edu-new-srvtab /etc/v5srvtab
chmod 600 /etc/v5srvtab
From the master try to manually propagate to the slave like:
/usr/local/sbin/kprop slave.backbone.uoknor.edu
If all goes according to plan you get a SUCCEEDED message and
kpropd will have run kdb5_edit (via the -p option in inetd.conf)
and automagically loaded the new database with lddb. If you get
the SUCCEEDED message with the master and slave on the same machine
it is time to try separate machines for the master and slave.
*THE CLOCK ON THE MASTER AND SLAVE MUST BE SYNCRONIZED WITHIN A FEW
MINUTES*
You can propogate automagically via cron using a script with these
commands:
#!/bin/sh
/usr/local/sbin/kdb5_edit -R "ddb /usr/local/lib/krb5kdc/slave_datatrans"
/usr/local/sbin/kprop slave.backbone.uoknor.edu
Once the propogation completes the slave will whirl and click for a while
as it updates the database. When all is quiet, you can check to see if it
worked by looking for your instance that was created on the master
earlier:
/usr/local/sbin/kdb5_edit
show somename
quit
Propogation of the database from master to slave does not require the
key distribution center to be running on the slave, but just about
everything else using kerberos does. Start the key distribution
center manually on the slave:
/usr/local/sbin/krb5kdc
You can start the key distribution center from /etc/rc.local as follows:
# Put any local setup commands in here
if [ -f /usr/local/sbin/krb5kdc ]; then
/usr/local/sbin/krb5kdc
echo -n ' kerberos5'
fi
In addition you will need to validate your instance to kerberos. On
the slave, try using the name and password you created for yourself
on the master
/usr/local/bin/kinit somename
supply the password
Trouble shooting:
If there are no errors but your principal did not propogate from the
master to the slave check to see if the file
/usr/local/lib/krb5kdc/slave_datatrans exists on the master and the
file /usr/local/lib/krb5kdc/from_master exists on the slave with the
correct time stamps. If not, you probably forgot to dump the
database and run kprop on the master or have a problem with either
the entry for the master in /usr/local/lib/krb5kdc/kpropd.acl on the
slave or the kpropd entry in /etc/inetd.conf on the slave. Otherwise
the transfer worked and the problem is with the automatic reload of
the database via krb5_edit from the kpropd entry in /etc/inetd.conf
on the slave. This may be related to typos or paths and permissions
on executables. Try manually executing the kdb5_edit -R "lddb etc."
command described for the inetd above. If it fails you may have used
different realm passwords for the master and slave. Remove the empty
database on the slave using:
rm /usr/local/lib/krb5kdc/principal*
Rerun the database creation and and rerun the password stash commands
on the slave, as described earlier, giving the correct realm password
from the master. You can verify the realm password on the master by
running /usr/local/sbin/kdb5_edit and using the emk (enter master key)
command to check it.
A message about "broken pipe" during kprop almost certainly
indicates problems with the kpropd.acl file. If you get an error
about privilege when running kpropd make sure you are su root. If you
get an error about the format of the config files check to see that
they are in fact correct. Also check that they are world readable.
If get an error about "Permission denied during attempt to fetch
initial ticket" you probably forgot to su before running kprop. If
you get an error about "No principal found in data base during
attempt to fetch initial ticket" you have a mismatch between the host
name in /etc/hosts and the host/what_ever principle created in the
master data base and exported to /etc/v5srvtab on the master or slave.
Make sure the first name following the address for the local host in
/etc/hosts on the slave is fully qualified. This is also the case if
you get an error during kprop on the master about "Wrong principal in
request" or "Software caused connection abort".
