Ubuntu Server Guide Changes, errors and bugs

Secondary KDC
Once you have one Key Distribution Center (KDC) on your network, it is good practice to have a Secondary
KDC in case the primary becomes unavailable. Also, if you have Kerberos clients that are in different
networks (possibly separated by routers using NAT), it is wise to place a secondary KDC in each of those
networks.
Note
The native replication mechanism explained here relies on a cronjob, and essentially dumps the
DB on the primary and loads it back up on the secondary. You may want to take a look at using
the kldap backend which can use the OpenLDAP replication mechanism. It is explained further
below.
First, install the packages, and when asked for the Kerberos and Admin server names enter the name of the
Primary KDC:
sudo apt i n s t a l l krb5−kdc krb5−admin−s e r v e r
Once you have the packages installed, create the host principals for both KDCs. From a terminal prompt,
enter:
kadmin −q ” a d d p r i n c −randkey h o s t / kdc01 . example . com”
kadmin −q ” a d d p r i n c −randkey h o s t / kdc02 . example . com”
176

---

Note
The kadmin command defaults to using a principal like username/[e-mail],
where username is your current shell user. If you need to override that, use −p 
−want>
Make sure the principal you are using has the extra extract−keys privilege in kdc01’s /etc/krb5kdc/kadm5.
acl file. Something like this:
ubuntu /admin@EXAMPLE .COM * e
Where “*” means all privileges (except extract−keys), and e means exactly extract−keys.
Extract the keytab file:
kadmin −q ” ktadd −norandkey −k keytab . kdc02 h o s t / kdc02 . example . com”
There should now be a keytab.kdc02 in the current directory, move the file to /etc/krb5.keytab:
sudo mv keytab . kdc02 / e t c / krb5 . keytab
sudo chown r o o t : r o o t / e t c / krb5 . keytab
Note
If the path to the keytab.kdc02 file is different adjust accordingly.
Also, you can list the principals in a Keytab file, which can be useful when troubleshooting, using the klist
utility:
sudo k l i s t −k / e t c / krb5 . keytab
The -k option indicates the file is a keytab file.
Next, there needs to be a kpropd.acl file on each KDC that lists all KDCs for the Realm. For example, on
both primary and secondary KDC, create /etc/krb5kdc/kpropd.acl:
h o s t / kdc01 . example [e-mail]
h o s t / kdc02 . example [e-mail]
Create an empty database on the Secondary KDC:
sudo k d b 5 _ u t i l −s c r e a t e
Now install kpropd daemon, which listens for connections from the kprop utility from the primary kdc:
sudo apt i n s t a l l krb5−kpropd
The service will be running right after installation.
From a terminal on the Primary KDC, create a dump file of the principal database:
sudo k d b 5 _ u t i l dump / var / l i b / krb5kdc /dump
Still on the Primary KDC, extract its keytab file and copy it to /etc/krb5.keytab:
kadmin −q ” ktadd −k keytab . kdc01 h o s t / kdc01 . example . com”
sudo mv keytab . kdc01 / e t c / krb5 . keytab
sudo chown r o o t : r o o t / e t c / krb5 . keytab
Note
You can now remove the extract−keys privilege from this principal in kdc01’s /etc/krb5kdc/
kadm5.acl file
177

---

On the Primary KDC, run the kprop utility to push the database dump made before to the Secondary KDC:
$ sudo kprop −r EXAMPLE.COM −f / var / l i b / krb5kdc /dump kdc02 . example . com
Database p r o p a g a t i o n t o kdc02 . example . com : SUCCEEDED
Note the SUCCEEDED message, which signals that the propagation worked. If there is an error message
check /var/log/syslog on the secondary KDC for more information.
You may also want to create a cron job to periodically update the database on the Secondary KDC. For
example, the following will push the database every hour:
# m h
dom mon dow
command
0 * * * * r o o t / u s r / s b i n / k d b 5 _ u t i l dump / var / l i b / krb5kdc /dump && / u s r / s b i n /
kprop −r EXAMPLE.COM −f / var / l i b / krb5kdc /dump kdc02 . example . com
Back on the Secondary KDC, create a stash file to hold the Kerberos master key:
sudo k d b 5 _ u ti l s t a s h
Finally, start the krb5−kdc daemon on the Secondary KDC:
sudo s y s t e m c t l s t a r t krb5−kdc . s e r v i c e
Note
The Secondary KDC does not run an admin server, since it’s a read-only copy
From now on, you can specify both KDC servers in /etc/krb5.conf for the EXAMPLE.COM realm, in any
host participating in this realm (including kdc01 and kdc02), but remember that there can only be one
admin server and that’s the one running on kdc01:
[ r e a l m s ]
EXAMPLE.COM = {
kdc = kdc01 . example . com
kdc = kdc02 . example . com
admin_server = kdc01 . example . com
}
The Secondary KDC should now be able to issue tickets for the Realm. You can test this by stopping the
krb5−kdc daemon on the Primary KDC, then by using kinit to request a ticket. If all goes well you should
receive a ticket from the Secondary KDC. Otherwise, check /var/log/syslog and /var/log/auth.log in the
Secondary KDC.