aboutsummaryrefslogtreecommitdiff
path: root/crypto/krb5/doc/admin/backup_host.rst
diff options
context:
space:
mode:
Diffstat (limited to 'crypto/krb5/doc/admin/backup_host.rst')
-rw-r--r--crypto/krb5/doc/admin/backup_host.rst34
1 files changed, 0 insertions, 34 deletions
diff --git a/crypto/krb5/doc/admin/backup_host.rst b/crypto/krb5/doc/admin/backup_host.rst
deleted file mode 100644
index 8914551c92d2..000000000000
--- a/crypto/krb5/doc/admin/backup_host.rst
+++ /dev/null
@@ -1,34 +0,0 @@
-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 replica KDCs, you
-might never notice, since the next automatic propagation of the
-database would install a fresh copy. However, if it happens to the
-primary KDC, the corrupted database would be propagated to all of the
-replicas during the next propagation. For this reason, MIT recommends
-that you back up your Kerberos database regularly. Because the primary
-KDC is continuously dumping the database to a file in order to
-propagate it to the replica 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 primary KDC.
-(See :ref:`restore_from_dump`.)