[5217] in Kerberos
How to build a kerberos 5 slave in 3 easy pages
daemon@ATHENA.MIT.EDU ('(AUS) Steve Kenton')
Mon May 22 17:16:17 1995
To: kerberos@MIT.EDU
Date: 22 May 1995 20:56:43 GMT
From: skenton@remus.ucs.uoknor.edu ('(AUS) Steve Kenton')
Building a Kerberos 5 slave
The B4-3 stuff has been test on SUN 4.1.3_U1 and Slackware Linux 2.2
with 1.2.6 kernel. The BETA5 stuff has been tested on Slackware
Linux 2.2 with 1.2.8 kernel. It works here, your mileage may vary.
First you need a working master.
Obtain the source for some distribution of Kerberos 5 and configure it.
cd src
./configure
For the B4-3 distribution, you must change one line of code on the
master (where kprop will be run) before building the executables.
edit lib/krb5/keytab/file/ktf_get_en.c and add a break; after line 67.
There is a bug in the IGNORE_VNO logic that trips up the kprop program.
This change should not be needed on later releases.
For the BETA5 (950505) distribution you must make some other changes.
A couple of things got left out. This should be fixed in later releases.
Edit slave/kprop.c and add following section after line 374.
It should be immediately before the krb5_sendauth call.
if (retval = krb5_auth_con_setaddrs(contect, *auth_contect, &sender_addr,
&receiver_addr)) {
com_err(progname, retval, "in krb5_auth_con_setaddrs");
exit(1);
}
edit lib/krb5/krb/rd_safe.c and insert the following after line 269.
It should be between two sets of closing "}" lines.
auth_context->remote_seq_number++;
For more recent distributions, none of the above changes are needed.
Now build the executables and install them in the standard places
make
make install
Set up the config files for your REALM and servers. For the B4-3
distibution they are /krb5/krb.conf and /krbc/krb.realms but for the
BETA5 distibution they were merged, and renamed to /etc/krb5.conf as
well as being reformatted. Follow the installation instructions for
the particular release you have. Remember to create the database and
start the kdc process on the master.
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.ucs.uoknor.edu and slave.ucs.uoknor.edu
references below.
Copy the config files from the master to the slave. Presumably they
are already correct and they should not require changes.
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.ucs.uoknor.edu@UOKNOR.EDU
The service names, protocols etc. for various kerberos 5 services are
distributed in config-files/services.append. As the name implies
this file need to be appended to the end of the /etc/services file on
both the master and the slave. Check for, and if necessary, change
the entry krb_prop to krb5_prop so that master to slave propogation
can find the required service name. This was wrong in the B4-3
distribution. It is correct in the BETA5 distribution.
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 vary 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 /krb5/sbin/kpropd kpropd -p
/krb5/admin/kdb5_edit
Initialize an empty data base on the slave as follows:
cd /krb5/admin
Run kdb5_create and supply the realm password (from the master) twice
Run 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 & slave instances like:
ark host/master.ucs.uoknor.edu
ark host/slave.ucs.uoknor.edu
xst master.ucs.uoknor.edu host
xst slave.ucs.uoknor.edu host
While you are at it, create an instance for yourself and dump the db like:
ank skenton
supply the password twice
ddb /krb5/slave_datatrans
quit
Now move/ftp/sneakernet the keytab files
master.ucs.uoknor.edu-new-srvtab and slave.ucs.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.ucs.uoknor.edu-new-srvtab /etc/v5srvtab
Either reboot or restart inetd so that kpropd will be in effect without rebooting.
ps -ax | grep -i inet
kill -HUP <pid of inetd>
Try to manually propagate to yourself like:
/krb5/sbin/kprop slave.ucs.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 lldb. 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:
/krb5/admin/kdb5_edit -R "ddb /krb5/slave_datatrans"
/krb5/sbin/kprop slave.ucs.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:
cd /krb5/admin
kdb5_edit
show skenton
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:
/krb5/sbin/krb5kdc
You can start the key distribution center from /etc/rc.local as follows:
# Put any local setup commands in here
if [ -f /krb5/sbin/krb5kdc ]; then
/krb5/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
/krb5/bin/kinit skenton
supply the password
