1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
Backups of secure hosts
=======================
When you back up a secure host, you should exclude the host's keytab
file from the backup. If someone obtained a copy of the keytab from a
backup, that person could make any host masquerade as the host whose
keytab was compromised. In many configurations, knowledge of the
host's keytab also allows root access to the host. This could be
particularly dangerous if the compromised keytab was from one of your
KDCs. If the machine has a disk crash and the keytab file is lost, it
is easy to generate another keytab file. (See :ref:`add_princ_kt`.)
If you are unable to exclude particular files from backups, you should
ensure that the backups are kept as secure as the host's root
password.
Backing up the Kerberos database
--------------------------------
As with any file, it is possible that your Kerberos database could
become corrupted. If this happens on one of the slave KDCs, you might
never notice, since the next automatic propagation of the database
would install a fresh copy. However, if it happens to the master KDC,
the corrupted database would be propagated to all of the slaves during
the next propagation. For this reason, MIT recommends that you back
up your Kerberos database regularly. Because the master KDC is
continuously dumping the database to a file in order to propagate it
to the slave KDCs, it is a simple matter to have a cron job
periodically copy the dump file to a secure machine elsewhere on your
network. (Of course, it is important to make the host where these
backups are stored as secure as your KDCs, and to encrypt its
transmission across your network.) Then if your database becomes
corrupted, you can load the most recent dump onto the master KDC.
(See :ref:`restore_from_dump`.)
|
