Dépannage de Kerberos

Cette section fournit des informations de dépannage pour le logiciel Kerberos.

Identification des problèmes liés aux numéros de version de clé

Parfois, le numéro de version de clé (KVNO) utilisé par le KDC et les clés du principal de service stockées dans le fichier /etc/krb5/krb5.keytab pour les services hébergés sur le système ne correspondent pas. Le KVNO peut être désynchronisé lors de la création d'un nouvel ensemble de clés sur le KDC sans mettre à jour le fichier de table de clés avec les nouvelles clés. Ce problème peut être diagnostiqué à l'aide de la procédure suivante.

1. Répertoriez les entrées keytab.

   Notez que le KVNO pour chaque principal est inclus dans la liste.

   # klist -k 
   Keytab name: FILE:/etc/krb5/krb5.keytab
   KVNO Principal
   ---- --------------------------------------------------------------------------
      2 host/denver.example.com@EXAMPLE.COM
      2 host/denver.example.com@EXAMPLE.COM
      2 host/denver.example.com@EXAMPLE.COM
      2 nfs/denver.example.com@EXAMPLE.COM
      2 nfs/denver.example.com@EXAMPLE.COM
      2 nfs/denver.example.com@EXAMPLE.COM
      2 nfs/denver.example.com@EXAMPLE.COM

2. Faites l'acquisition d'autorisations initiales à l'aide de la clé host.

   # kinit -k

3. Déterminez le KVNO utilisé par le KDC.

   # kvno nfs/denver.example.com
   nfs/denver.example.com@EXAMPLE.COM: kvno = 3

   Notez que le KVNO répertorié ici est 3 au lieu de 2.

Problèmes avec le format du fichier krb5.conf

Si le fichier krb5.conf n'est pas formaté correctement, le message d'erreur suivant peut s'afficher dans une fenêtre de terminal ou être enregistrée dans le fichier journal :

Improper format of Kerberos configuration file while initializing krb5 library

S'il y a un problème avec le format du fichier krb5.conf, les services associés sont vulnérables aux attaques. Vous devez résoudre le problème avant d'autoriser l'utilisation des fonctions de Kerberos.

Problèmes de propagation de la base de données Kerberos

Si la propagation de base de données Kerberos échoue, essayez /usr/bin/rlogin -x entre le KDC esclave et le KDC maître, et depuis le KDC maître vers le serveur KDC esclave.

Si les KDC ont été configurés de façon à restreindre l'accès, rlogin est désactivé et ne peut pas être utilisé pour résoudre ce problème. Pour activer rlogin sur un KDC, vous devez activer le service eklogin.

# svcadm enable svc:/network/login:eklogin

Une fois que vous avez résolu le problème, vous devez désactiver le service eklogin.

Si rlogin ne fonctionne pas, les problèmes proviennent probablement des fichiers keytab des KDC. Si rlogin ne fonctionne pas, le problème ne provient pas du fichier keytab ou du service de noms, car rlogin et le logiciel de propagation utilisent le même principal host/host-name. Dans ce cas, assurez-vous que le fichier kpropd.acl est correct.

Problèmes de montage d'un système de fichiers NFS utilisant Kerberos

• Si un montage de système de fichiers NFS utilisant Kerberos échoue, assurez-vous que le fichier /var/rcache/root existe sur le serveur NFS. Si le système de fichiers n'est pas détenu par root, supprimez-le et essayez de le monter une nouvelle fois.

• Si vous avez un problème d'accès à un système de fichiers NFS utilisant Kerberos, assurez-vous que le service gssd est activé sur votre système et le serveur NFS.

• Si vous voyez le message d'erreur invalid argument ou bad directory lorsque vous tentez d'accéder à un système de fichiers NFS utilisant Kerberos, le problème est peut-être que vous n'utilisez pas un nom DNS complet lorsque vous essayez de monter le système de fichiers NFS. L'hôte qui est en cours de montage n'est pas le même que le composant du nom de l'hôte du principal de service dans le fichier keytab du serveur.

  Ce problème peut également se produire si votre serveur dispose de plusieurs interfaces Ethernet, et que vous avez configuré DNS pour qu'il utilise un plan de type "nom par interface" au lieu de "plusieurs enregistrements d'adresses par hôte". Pour le service Kerberos, vous devez configurer plusieurs enregistrements d'adresses par hôte comme suitKen Hornstein, "FAQ Kerberos," [http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#kerbdns], consulté le 10 mars 2010.:

  my.host.name.   A       1.2.3.4
                  A       1.2.4.4
                  A       1.2.5.4
  
  my-en0.host.name.       A       1.2.3.4
  my-en1.host.name.       A       1.2.4.4
  my-en2.host.name.       A       1.2.5.4
  
  4.3.2.1         PTR     my.host.name.
  4.4.2.1         PTR     my.host.name.
  4.5.2.1         PTR     my.host.name.

Dans cet exemple, la configuration autorise une référence pour les différentes interfaces et un seul principal de service au lieu de trois principaux de service dans le fichier keytab du serveur.

Problèmes liés à l'authentification en tant qu'utilisateur root

En cas d'échec de l'authentification lorsque vous essayez de vous connecter en tant que superutilisateur sur votre système et que vous avez déjà ajouté le principal root au fichier keytab de votre hôte, il y a deux problèmes potentiels à vérifier. Tout d'abord, assurez-vous que le principal root dans le fichier keytab a un nom d'hôte complet comme instance. Si c'est le cas, vérifiez le fichier /etc/resolv.conf pour vous assurer que le système est correctement configuré en tant que client DNS.

Observation du mappage d'informations d'identification GSS sur des informations d'identification UNIX

Pour être en mesure de contrôler les correspondances d'informations d'identification, commencez par décommenter cette ligne du fichier /etc/gss/gsscred.conf.

SYSLOG_UID_MAPPING=yes

Ensuite demandez au service gssd d'obtenir des informations depuis le fichier /etc/gss/gsscred.conf.

# pkill -HUP gssd

Maintenant, vous devez être en mesure de contrôler les mappages d'informations d'identification quand gssd les demande. Les mappages sont enregistrés par syslogd, si le fichier syslog.conf est configuré pour l'utilitaire système auth avec le niveau de gravité debug.