Administration de la base de données Kerberos

La base de données Kerberos est au coeur du système Kerberos, et doit donc être correctement mise à jour. La présente section décrit certaines procédures d'administration de la base de données Kerberos, dont la sauvegarde et la restauration de la base de données, la configuration de la propagation en parallèle, et l'administration du fichier de réserve. Les étapes de configuration initiale de la base de données sont présentées à la section "Comment configurer un KDC maître".

Sauvegarde et propagation de la base de données Kerberos

La propagation de la base de données Kerberos du KDC maître vers les KDC esclaves est l'une des tâches de configuration les plus importantes. Si la propagation n'est pas assez fréquente, le KDC maître et les KDC esclaves se désynchroniseraient, et si le KDC maître tombait en panne, les KDC esclaves ne posséderaient pas les informations de base de données les plus récentes. En outre, si un KDC esclave a été configuré en tant que maître à des fins d'équilibrage de charge, les clients utilisant cet esclave comme KDC maître n'auront pas les informations les plus récentes. Il est donc important de s'assurer que la propagation est effectuée à une fréquence suffisante, en fonction de la fréquence à laquelle vous modifiez la base de données Kerberos.

Lorsque vous configurez le KDC maître, vous définissez le script kprop_script dans une tâche cron de manière à sauvegarder automatiquement la base de données Kerberos dans le fichier de vidage /var/krb5/slave_datatrans et de la propager vers les KDC esclaves. Cependant, comme tout autre fichier, la base de données Kerberos peut s'endommager. Si cela se produit sur un des KDC esclaves, vous pourriez ne pas le remarquer, étant donné que la propagation automatique suivante de la base de données installe une nouvelle copie. Mais si cela se produit sur le KDC maître, la base de données erronée est propagée vers tous les esclaves lors de la propagation suivante, et le fichier de sauvegarde erroné remplace le fichier de sauvegarde non erroné antérieur sur le KDC maître.

Comme il n'y a pas de copie de sauvegarde "sécuritaire" dans ce scénario, vous devriez également configurer une tâche cron afin de copier périodiquement le fichier de vidage slave_datatrans dans un autre emplacement, ou afin de créer une autre copie de sauvegarde distincte au moyen de la commande dump de kdb5_util. Ensuite, si votre base de données est altérée, vous pourrez restaurer la sauvegarde la plus récente sur le KDC maître au moyen de la commande load de kdb5_util.

Il est également important de noter que, comme le fichier de vidage de la base de données contient des clés de principal, vous devez protéger le fichier contre les utilisateurs non autorisés (par défaut, le fichier de vidage de la base de données n'a des permissions en lecture/écriture que pour root). Cela inclut l'utilisation exclusive de la commande kprop pour propager le fichier de vidage de la base de données, qui chiffre les données transférées. En outre, kprop propage les données uniquement aux KDC esclaves, ce qui minimise la possibilité d'un envoi accidentel du vidage de la base de données à des hôtes non autorisés.

Si la base de données Kerberos est actualisée après avoir été propagée et qu'elle est ultérieurement endommagée avant la propagation suivante, les esclaves ne contiendront pas les mises à jour : celles-ci seront perdues. En raison de ce scénario, si vous apportez des modifications considérables à la base de données avant une propagation périodique, vous devriez propager manuellement la base de données afin d'éviter les pertes de données.

Le fichier kpropd.acl

Le fichier kpropd.acl d'un centre de distribution de clés (KDC) contient une liste de noms de principal d'hôte, un par ligne, spécifiant les systèmes desquels le KDC peut recevoir une base de données actualisée au moyen du mécanisme de propagation. Si le KDC maître est employé pour propager tous les KDC esclaves, le fichier kpropd.acl de chaque esclave ne doit contenir que le nom de principal de l'hôte du maître.

Cependant, les étapes d'installation et de configuration subséquentes de ce guide vous indiquent d'ajouter le même fichier kpropd.acl aux KDC maître et esclaves. Le fichier contient tous les noms de principal d'hôte KDC. Cette configuration vous permet d'effectuer la propagation depuis tout KDC, au cas où les KDC de propagation deviennent temporairement indisponibles. En outre, la conservation d'une copie identique sur tous les KDC en facilite la mise à jour.

La commande kprop_script

La commande kprop_script fait appel à la commande kprop pour propager la base de données Kerberos à d'autres KDC. (Si le script kprop_script est exécuté sur un KDC esclave, il propage la copie de l'esclave de la base de données Kerberos vers d'autres KDC.) Le script kprop_script accepte une liste de noms d'hôte comme arguments, séparés par des espaces, qui spécifient les KDC à propager.

Lorsque le script kprop_script est exécuté, il crée une copie de sauvegarde de la base de données Kerberos dans le fichier /var/krb5/slave_datatrans, et copie le fichier dans les KDC spécifiés. La base de données Kerberos est verrouillée jusqu'à la fin de la propagation.

Comment sauvegarder la base de données Kerberos

1. Adoptez l'identité de superutilisateur sur le KDC maître.

2. Sauvegardez la base de données Kerberos en utilisant la commande dump de kdb5_util.

   # /usr/krb5/sbin/kdb5_util dump [-verbeux] [-d nom_de_la_bd] [nom_du_fichier [principaux...]]

   -verbeux	Imprime le nom de chaque principal et de chaque politique en cours de sauvegarde.
   nom_de_la_bd	Nom de la base de données à sauvegarder. Le suffixe «.db» est ajouté au nom de base de données spécifié, et le chemin d'accès absolu du fichier peut être précisé. Si l'option -d n'est pas spécifiée, le nom de la base de données par défaut est /var/krb5/principal, lequel devient /var/krb5/principal.db.
   nom_du_fichier	Fichier de sauvegarde de la base de données. Vous pouvez préciser le chemin d'accès absolu de ce fichier. Si vous ne spécifiez pas de fichier, la base de données est vidée dans la sortie standard.
   principal	Liste comportant un ou plusieurs principaux (séparés par des espaces) devant être sauvegardés. Vous devez spécifier des noms de principal entièrement qualifiés. Si vous n'indiquez aucun principal, la base de données entière est sauvegardée.

Exemple--Sauvegarde de la base de données Kerberos

L'exemple suivant sauvegarde la base de données Kerberos dans un fichier appelé fichier_de_vidage. Étant donné que l'option -verbeux est spécifiée, chaque principal est imprimé à mesure qu'il est sauvegardé.

# kbd5_util dump -verbose fichier_de_vidage 
kadmin/kdc1.eng.acme.com@ENG.ACME.COM 
krbtgt/eng.acme.com@ENG.ACME.COM 
kadmin/history@ENG.ACME.COM 
pak/admin@ENG.ACME.COM 
pak@ENG.ACME.COM
changepw/kdc1.eng.acme.com@ENG.ACME.COM
#

L'exemple suivant sauvegarde les principaux pak et pak/admin de la base de données Kerberos.

# kdb5_util dump -verbose fichier_de_vidage pak/admin@ENG.ACME.COM pak@ENG.ACME.COM
pak/admin@ENG.ACME.COM
pak@ENG.ACME.COM
#

Comment restaurer la base de données Kerberos

1. Adoptez l'identité de superutilisateur sur le KDC maître.

2. Restaurez la base de données Kerberos au moyen de la commande load de kdb_util.

   # /usr/krb5/sbin/kdb5_util load [-verbeux] [-d nom_de_la_bd] [-update] [nom_du_fichier]

   -verbeux	Imprime le nom de chaque principal et de chaque politique en cours de restauration.
   nom_de_la_bd	Nom de la base de données à restaurer. Le suffixe «.db» est ajouté au nom de base de données spécifié, et le chemin d'accès absolu du fichier peut être précisé. Si l'option -d n'est pas spécifiée, le nom de la base de données par défaut est /var/krb5/principal, lequel devient /var/krb5/principal.db.
   -update	Met à jour la base de données existante ; autrement, une nouvelle base de données est créée ou la base de données existante est remplacée.
   nom_du_fichier	Fichier à partir duquel restaurer la base de données. Vous pouvez préciser le chemin d'accès absolu de ce fichier.

Exemple--Restauration de la base de données Kerberos

L'exemple suivant restaure la base de données appelée base1.db dans le répertoire courant à partir du fichier fichier_de_vidage. Étant donné que l'option -update n'est pas spécifiée, une nouvelle base de données est créée lors de la restauration.

# kdb5_util load -d base1 fichier_de_vidage

Comment propager manuellement la base de données Kerberos vers les KDC esclaves

Cette procédure explique comment propager la base de données Kerberos au moyen de la commande kprop. Vous pouvez l'utiliser pour synchroniser un KDC esclave avec le KDC maître en dehors de la tâche cron périodique. Contrairement au script kprop_script, vous pouvez utiliser la commande kprop pour propager uniquement la sauvegarde de la base de données courante sans effectuer préalablement une nouvelle sauvegarde de la base de données.

1. Adoptez l'identité de superutilisateur sur le KDC maître.

2. (facultatif) Sauvegardez la base de données au moyen de la commande kdb5_util.

   # /usr/krb5/sbin/kdb5_util dump /var/krb5/slave_datatrans

3. Propagez la base de données vers un KDC esclave au moyen de la commande kprop .

   # /usr/krb5/lib/kprop -f /var/krb5/slave_datatrans KDC_esclave

Si vous désirez sauvegarder la base de données et la propager vers un KDC esclave en dehors de la tâche cron périodique, vous pouvez aussi utiliser la commande kprop_script comme ceci :

# /usr/krb5/lib/kprop_script KDC_esclave

Configuration de la propagation en parallèle

Dans la plupart des cas, le KDC maître est utilisé exclusivement pour la propagation de sa base de données aux KDC esclaves. Cependant, si votre site comporte de nombreux KDC esclaves, vous pourriez répartir la charge du processus de propagation, ce qui est appelé la propagation en parallèle.

La propagation en parallèle permet à des KDC esclaves particuliers de partager les tâches de propagation avec le KDC maître. Cela permet d'accélérer la propagation et d'alléger la charge de travail du KDC maître.

Par exemple, supposons que votre site comporte un maître et six esclaves (comme l'illustre la Figure 3-2), et que esclave-1 à esclave-3 constitue un premier groupe logique, et esclave-4 à esclave-6 constitue le deuxième. Pour configurer la propagation en parallèle, le KDC maître pourrait propager la base de données vers esclave-1 et esclave-4, et ces esclaves pourraient à leur tour propager la base de données vers les esclaves dans leur groupe.

Figure 3-2 Exemple de configuration de propagation en parallèle

Comment configurer la propagation en parallèle

Ceci ne constitue pas une procédure détaillée, mais une liste globale des étapes de configuration permettant d'activer la propagation en parallèle.

1. Sur le KDC maître, modifiez l'entrée kprop_script dans sa tâche cron de manière à inclure seulement les arguments relatifs aux esclaves qui effectueront la propagation subséquente (esclaves de propagation).

2. Sur chaque esclave de propagation, ajoutez une entrée kprop_script à sa tâche cron, laquelle doit inclure les arguments à propager par les esclaves. Pour que la propagation en parallèle réussisse, il faut configurer l'exécution de la tâche cron après la propagation de l'esclave de propagation dans la nouvelle base de données.

   ---

   Remarque :

   La durée de propagation d'un esclave de propagation dépend de certains facteurs tels que la largeur de bande du réseau et la taille de la base de données.

   ---

3. Sur chaque KDC esclave, configurez les permissions appropriées devant être propagées. Pour ce faire, ajoutez le nom du principal de l'hôte de son KDC de propagation dans son fichier kpropd.acl.

Exemple -- Configuration de la propagation en parallèle

Dans l'exemple de la Figure 3-2, l'entrée kprop_script du KDC maître pourrait ressembler à ceci :

10 3 * * * /usr/krb5/lib/kprop_script esclave-1.acme.com esclave-4.acme.com

L'entrée kprop_script de l'esclave-1 aurait l'apparence suivante (il faut noter que la propagation sur l'esclave débute une heure après la propagation par le maître) :

10 4 * * * /usr/krb5/lib/kprop_script esclave-2.acme.com esclave-3.acme.com

Le fichier kpropd.acl des esclaves de propagation devrait comporter l'entrée suivante :

host/master.acme.com@ACME.COM

Le fichier kpropd.acl des esclaves propagés par esclave-1 devrait comporter l'entrée suivante :

host/esclave-1.acme.com@ACME.COM

Administration du fichier de réserve

Le fichier de réserve contient la clé maîtresse de la base de données Kerberos, qui est créée automatiquement lorsque vous créez une base de données Kerberos. Si le fichier de réserve est endommagé, vous pouvez employer la commande stash de kdb5_util(1M) afin de remplacer le fichier endommagé. Normalement, vous ne devriez supprimer un fichier de réserve qu'après avoir supprimé la base de données Kerberos au moyen de la commande destroy de kdb5_util. Comme le fichier de réserve n'est pas supprimé automatiquement avec la base de données, vous devez le supprimer afin de terminer le nettoyage.

Comment supprimer un fichier de réserve

1. Adoptez l'identité de superutilisateur sur le KDC contenant le fichier de réserve.

2. Supprimez le fichier de réserve.

   # rm fichier_de_réserve

   fichier_de_réserve

   Chemin du fichier de réserve. Par défaut, le fichier de réserve se situe dans /var/krb5/.k5.secteur.

Si vous devez recréer le fichier de réserve, vous pouvez employer l'option -f de la commande kdb5_util.