How to configure Slave KDC (Backup KDC)

At this point, you will want to setup a backup or “slave” KDC.

Host Principal

First, add a host principal for each slave KDC. If you followed the instructions above for the primary KDC, then you will already have a host principal for the primary.
 [root@coma ~]# kadmin
 Authenticating as principal root/admin@ EXAMPLE.COM with password.
 Password for root/admin@ EXAMPLE.COM:
 kadmin:  addprinc -randkey host/second.example.com
 NOTICE: no policy specified for host/second.example.com@ EXAMPLE.COM; assigning "default"
 Principal "host/second.example.com@ EXAMPLE.COM " created.

Copy Configuration Files

Copy the following files from the primary KDC to each of the slave KDCs.

• /etc/krb5.conf
• /var/kerberos/krb5kdc/kdc.conf
• /var/kerberos/krb5kdc/kadm5.acl
• /etc/gssapi_mech.conf

Create kpropd.acl

Create an ACL file with all of the KDCs listed (both primary and backups). This file is /var/kerberos/krb5kdc/kpropd.acl and should look something like this.
host/coma.example.com@ EXAMPLE.COM

host/ second.example.com@ EXAMPLE.COM
Don’t put this file on the primary KDC or kadmin will not start.

Add Host Principal to Slave Key Table

On each slave KDC, add the host principal to the local key table.
 [root@second ~]# kadmin
 Authenticating as principal root/admin@ EXAMPLE.COM with password.
 Password for root/admin@ EXAMPLE.COM:
 kadmin:  ktadd host/ second.example.com

Start the Kerberos Propagation Daemon

On RHEL4 it is not necessary to create the database on the slave prior to starting the daemon. It was reported (thanks Louis) that on Fedora and perhaps Centos it is required. If the kprop daemon doesn’t start, you may need to create the database with the “kdb5_util create -s” command before starting it.
On each slave KDC, use the following command to enable the receipt of the kerberos database.
[root@second ~]# chkconfig kprop on
[root@second ~]# service kprop start
Starting Kerberos 5 Propagation Server:                    [  OK  ]

Propagate the Database

The next step is to propagate the database (manually) to each slave KDC. This is a two step process. First, dump the database to a file. Next, propogate the dumped file to each slave KDC.
 

[root@coma ~]# kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans
 [root@coma ~]# kprop -f /var/kerberos/krb5kdc/slave_datatrans second.physik.unizh.ch
 Database propagation to second.physik.unizh.ch: SUCCEEDED

Create a Stash File

On each KDC you need to create a stash file. You will need the (really long and random) master key that you entered when you initially created the kerberos database.
 [root@second ~]# kdb5_util stash
 kdb5_util: Cannot find/read stored master key while reading master key
 kdb5_util: Warning: proceeding without master key
 Enter KDC database master key:

Start the Kerberos 5 KDC on each Slave

Now that the database is there, and you have created the stash file, you are ready to start the KDC Daemon.
 [root@second ~]# chkconfig krb5kdc on
 [root@second ~]# service krb5kdc start
 Starting Kerberos 5 KDC:                                   [  OK  ]
Do not start the Administration Daemon (kadmin) on the slaves. The Administration Daemon is used to add/remove/modify principals and to change passwords. When the database is replicated to the slaves, any changes that were made on the slaves would be lost. This also means that if the primary KDC goes down, it is not possible to make changes, or for users to modify their password.
If the primary KDC will be down for an extended period, you can make any slave the primary, but you will have to replicate the database back to the old primary when it becomes available. This requires manual intervention.

[ Read More ]

How to Create the Kerberos database

Create the database with the following command.

 [root@coma ~] kdb5_util create -s

This will prompt you for a password. You will only have to enter this password when you initially configure a slave KDC, so choose something large and random and store it in a secure place. Really, you may only have to enter this once more, so make it secure.

Add the first Administrative User

I do administration as root, so the first user I add is root/admin. The default realm is appended automatically, so the command to use is as follows.
 [root@coma ~] kadmin.local -q "addprinc root/admin"
Enter a password when prompted. You will need this password every time you administer the database.

Starting the Services

At this point it is necessary to enable and start the kerberos services.

 [root@coma ~] chkconfig kadmin on
 [root@coma ~] service kadmin start
 [root@coma ~] chkconfig krb5kdc on
 [root@coma ~] service krb5kdc start

To test if everything is working, run kadmin. By default, the current user appended with ‘/admin’ is used as the principle.
 [root@coma ~] kadmin
 Authenticating as principal root/admin@PHYSIK.UNIZH.CH with password.
 Password for root/admin@PHYSIK.UNIZH.CH:
 kadmin:  listprincs
 K/M@PHYSIK.UNIZH.CH
 kadmin/admin@PHYSIK.UNIZH.CH
 kadmin/changepw@PHYSIK.UNIZH.CH
 kadmin/history@PHYSIK.UNIZH.CH
 krbtgt/PHYSIK.UNIZH.CH@PHYSIK.UNIZH.CH
 root/admin@PHYSIK.UNIZH.CH
The additional principles have been created by the tool. They are required so leave them be.

Create a Host Principal for the KDC

Now you will want to create a host principal for the KDC. This is required for replication (see below). You also need to add this principal to the local key table.
 [root@coma ~]# kadmin
 Authenticating as principal root/admin@EXAMPLE.COM with password.
 Password for root/admin@EXAMPLE.COM:
 kadmin: addprinc -randkey host/coma.EXAMPLE.COM
 NOTICE: no policy specified for host/coma.example.com@EXAMPLE.COM; assigning "default"
 Principal "host/coma.example.com@EXAMPLE.COM" created.
 kadmin: ktadd host/coma.example.com

Setup the default Policy

You will want to create the default password policy at this point. All new accounts will have this policy enforced.
 [root@coma ~] kadmin
 Authenticating as principal root/admin@ EXAMPLE.COM with password.
 Password for root/admin@ EXAMPLE.COM:
 kadmin: add_policy -maxlife 180days -minlife 2days -minlength 8 -minclasses 3 -history 10 default
You can also add other policies and apply different policies to different principles. The different flags and their meaning are as follows.

Flag	Description
-maxlife	The is the maximum period before the password must be changed.
-minlife	This is the minimum time after a password change before it can be changed again. Without a minimum time, users can change their password multiple times and overflow the history (see below) and end up back with the same password.
-minclasses	This is the number of distinct character classes that must appear in the password. Character classes are uppercase letters, lowercase letters, number and symbols. Setting this to 2 for example would mean a password with at least one lowercase letter and a number would be valid.
-history	This is the number of previous passwords to keep. A password may not duplicate a prior password.

Changing the Maximum Renewal Time

Each principal has its own maximum renewal life. On RHEL4, new principals are created with a maximum renewal time of zero. This means you can get a renewable ticket, but they can never be renewed. Each principal must be manually changed to the desired maximum renewal time. In addition, the special principal krbtgt/REALM@REALM must be changed to reflect the maximum renewal time that any principal will have.
 [root@coma ~]# kadmin
 Authenticating as principal root/admin@ EXAMPLE.COM with password.
 Password for root/admin@ EXAMPLE.COM:
 kadmin:  modprinc -maxrenewlife 2weeks krbtgt/ EXAMPLE.COM @ EXAMPLE.COM
 Principal "krbtgt/ EXAMPLE.COM @ EXAMPLE.COM " modified.

Adding Principals

 [root@coma ~] kadmin
 uthenticating as principal root/admin@ EXAMPLE.COM with password.
 Password for root/admin@ EXAMPLE.COM:
 kadmin: addprinc -maxrenewlife 7days doug
The various options allow you to tune your password policy. 

[ Read More ]

Edit /var/kerberos/krb5kdc/kadm5.acl & /etc/gssapi_mech.conf

This file determines who can modify the kerberos database. You need to change the realm. 

*/admin@EXAMPLE.COM *
A brief note on kerberos users (called principles) is in order at this point. All standard users will be of the form username@REALM. When one tries to run the administration tool, it takes the current username, appends ‘/admin’ and uses that as the principle. If there is no username/admin@REALM principle, then that user cannot modify the database.

Change /etc/gssapi_mech.conf

There is a problem with this file on 64-bit architectures. It specifies the “lib” library path instead of the “lib64” path. You can just remove the path altogether and it will work on either. This is more important on a kerberos client, but a server can be a client as well, so you may as well change it on all machines.
# library                               initialization function
# ================================      ==========================
# The MIT K5 gssapi library, use special function for initialization.
libgssapi_krb5.so                       mechglue_internal_krb5_init

[ Read More ]

Edit /var/kerberos/krb5kdc/kdc.conf

In this file, only the realms section needs to be modified. it is important to change the key types as well. I can confirm that the setting below work perfectly in our environment. You may want to decide on appropriate values for the maximum life of each ticket, and for how long each ticket can be renewed. Reasonable values are 1 day and 1 week but your needs will vary. The values here are the absolute maximum that the KDC will issue. Each principal has its own maximum as well. 

[realms]
EXAMPLE.COM = {
 master_key_type = des3-hmac-sha1
 supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal
 max_life = 25h
 max_renewable_life = 4w
}

[ Read More ]

Edit file /etc/krb5.com

There are a number of files that have to be manually edited on the server.

Edit /etc/krb5.conf

The stock version of this file will have EXAMPLE.COM or example.com everwhere you want to put your own realm or domain name. The two sections in question are libdefaults and domain_realm. The other sections do not need to be changed. In libdefaults, enter your own kerberos realm name. You may want to set the clock skew to a lower value (provided you are synchronizing time with ntp).
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
clockskew = 120
The realms section contains the settings for each realm. We have only one realm so it would look like the following. Note that you enter a kdc line for each Kerberos Domain Controller. You should have at least two.
[realms]
EXAMPLE.COM = {
 kdc = coma.example.com:88
 kdc = second.example.com:88
 admin_server = coma.example.com:749
 default_domain = example.com
}
In domain_realm, enter the mapping between DNS domains and your kerberos realm. If you are serving multiple DNS domains, you need to put them all here.
[domain_realm]
.zbox.example.com = EXAMPLE.COM
zbox.EXAMPLE.COM = EXAMPLE.COM
.example.com = EXAMPLE.COM
example.com = example.com
Finally, you may want to tweak the application defaults, for example to change the renew lifetime.
[appdefaults]
pam = {
  debug = false
  ticket_lifetime = 36000
  renew_lifetime = 36000
  forwardable = true
  krb4_convert = false
}
kinit = {
  ticket_lifetime = 36000
  renew_lifetime = 36000
  forwardable = true
}

[ Read More ]