Bases du client Kerberos sous Linux : krb5.conf, kinit/klist/kdestroy et keytabs

Objectif

Obtenir, inspecter et supprimer un ticket d'octroi de ticket (TGT, ticket-granting ticket) Kerberos sur un client Linux avec MIT Kerberos (krb5), et utiliser un keytab pour un processus qui doit s'authentifier sans mot de passe saisi de manière interactive.

Prérequis

Le paquet krb5-user/krb5-workstation est installé. Le fichier /etc/krb5.conf est configuré avec au minimum un default_realm dans [libdefaults], ainsi que, sauf si des enregistrements DNS SRV fournissent cette information, une section [realms] associant le realm à son KDC, et généralement une section [domain_realm] associant les domaines DNS au realm. Le KDC doit être joignable par le réseau (en général TCP/UDP 88).

Étapes

1. Vérifier la configuration : default_realm dans /etc/krb5.conf doit correspondre exactement au nom du realm, casse comprise. Par convention, les noms de realm Kerberos sont en majuscules et sont traités comme des chaînes sensibles à la casse : pour la bibliothèque, EXAMPLE.COM et example.com sont donc deux realms distincts, même si le DNS ne tient pas compte de la casse.
2. Obtenir un ticket de manière interactive : kinit user@EXAMPLE.COM. La commande demande le mot de passe et, en cas de succès, enregistre un TGT dans le cache d'identifiants par défaut. La documentation de kinit décrit les options -k -t <keytab> pour s'authentifier à partir d'un keytab plutôt qu'avec un mot de passe, ce qui est la forme requise pour un usage non interactif, par exemple kinit -k -t /etc/svc.keytab svc@EXAMPLE.COM (sans principal, la commande utilise par défaut le principal local host/).
3. Inspecter le cache : klist affiche le principal, les indicateurs (flags) des tickets ainsi que leurs dates d'émission et d'expiration, sans nécessiter d'authentification supplémentaire.
4. Lister le contenu d'un keytab (pour un principal de service ou d'automatisation) sans en extraire les secrets : klist -k -t -e /etc/krb5.keytab. La commande affiche les principaux, les horodatages des clés et (avec -e) les types de chiffrement présents dans le keytab ; le keytab système n'est lisible que par root.
5. Supprimer les tickets en cache une fois le travail terminé ou avant de changer d'identité : kdestroy.

Résultat attendu

Après un kinit réussi, klist affiche un TGT valide dont la date d'expiration se situe dans le futur ; un appel ultérieur à un service Kerberisé (SSH avec GSSAPI, liaison LDAP SASL/GSSAPI) aboutit sans demande de mot de passe. Après kdestroy, klist indique qu'aucun identifiant n'est en cache.

Limites et base de vérification

Les défaillances les plus fréquentes côté client sont le décalage d'horloge et les différences de casse dans le nom du realm entre krb5.conf et ce qu'attend le KDC. Kerberos rejette les tickets lorsque les horloges du client et du KDC diffèrent de plus que la tolérance configurée (clockskew dans [libdefaults], 300 secondes par défaut) ; l'erreur signalée est « clock skew too great ». Aucun de ces deux cas ne relève d'un problème de réseau ou de mot de passe : il est donc plus efficace de vérifier d'abord chronyc tracking/timedatectl et la chaîne exacte du realm. Un fichier keytab permet à quiconque peut le lire d'obtenir des tickets pour son principal ; ses permissions (lecture réservée au propriétaire) sont donc aussi importantes que son emplacement.