"Fossies" - the Fresh Open Source Software Archive

Member "krb5-1.18/doc/admin/backup_host.rst" (12 Feb 2020, 1790 Bytes) of package /linux/misc/krb5-1.18.tar.gz:

As a special service "Fossies" has tried to format the requested source page into HTML format (assuming markdown format). Alternatively you can here view or download the uninterpreted source code file. A member file download can also be achieved by clicking within a package contents listing on the according byte size field. See also the last Fossies "Diffs" side-by-side code changes report for "backup_host.rst": 1.16.3_vs_1.17.

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 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 master 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 master 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 master KDC. (See restore_from_dump.)