Running a Debian Kerberos Realm

You will want to install the krb5-kdc and krb5-admin-server on your master
KDC and at least krb5-kdc on any slave KDCs you have.  You may wish to
install krb5-admin-server on slaves in case you need them to become the
master KDC in a hurry, but in this case you may want to configure
krb5-admin-server to not start unless started manually.  Otherwise,
clients may change their password on a slave server, a change that will
then be overwritten silently later and may cause user confusion.  (This
can only happen if the client is misconfigured to use a slave server as
the admin server, but sometimes this happens.)

If you want to use the LDAP backend, also install the krb5-kdc-ldap
package, which contains the kldap plugin.

krb5-kdc adds a commented-out line for kpropd to /etc/inetd.conf.  You
will want to uncomment this on slave KDCs so that they can receive updates
from the master, but leave it commented out on the master.

You should look at the KDC configuration file (/etc/krb5kdc/kdc.conf) and
adjust the parameters appropriately.  If you expect to be using a lot of
Kerberos4 services, you should either remove +preauth from the default
principal flags or select full krb4 support when prompted by debconf.
(You can run dpkg-reconfigure on krb5-kdc to see this prompt again.)  If
you remove +preauth from the flags, principals will by default not require
preauthentication.  This is less secure since it opens you to offline
dictionary attacks, but this level of security is what people have been
suffering with throughout the lifetime of Kerberos4.  You can turn on
requires_preauth for specific high-security principals in kadmin.  If you
simply select full krb4 support, then Kerberos5 clients will require
preauthentication, but all principals will be accepted for Kerberos4.
This has a similar vulnerability to dictionary attacks and cannot be
overridden by setting requires_preauth selectively.

By default principals are created with most supported keys, including AES
and 3DES keys.  This means that if you ever decide at some point in the
future that you no longer have any services using older weaker enctypes,
you can get the full security benefits of stronger encryption types by
dropping the weaker ones from supported_enctypes in /etc/krb5kdc/kdc.conf.
Note however, that for some services, like AFS, you may need to only create
single DES keys.  You might do this by for example:

    kadmin.local -e des-cbc-crc:normal -q "ktadd afs/ATHENA.MIT.EDU"

Similarly, for old Java applications, you may need to create keys without
AES enctypes, particularly if Java is using a ticket cache created by a
different program.

You will probably want to create /etc/krb5kdc/kadm5.acl to include a list
of users who are authorized to run kadmin in your realm.  The kadmind
documentation provides examples.