Kerberos est un protocole complexe, qui fait intervenir pas mal de concepts et plutôt que de s'intéresser d'abord à la théorie, peut-être vaut-il mieux adopter pour sa compréhension une démarche plus pragmatique, en voyant d'abord comment la plateforme de tests a été construite.

Nous disposons d'un réseau IP 192.168.0.0/24, dans lequel un domaine DNS « en bois » a été créé : maison.mrs. Un serveur DNS est donc en mesure d'effectuer toutes les recherches directes dans ce domaine ainsi que les recherches inverses associées. Tous les hôtes qui entreront en jeu fonctionneront sous Debian Lenny (serveurs) ou Ubuntu Karmic (clients).

L'exactitude est la politesse des rois, aussi ne faut-il pas s'étonner que l'exactitude temporelle revête au royaume de kerberos une importance particulière. Plus de 300 secondes (5 minutes) de divergence avec le serveur et c'est le bannissement définitif. Il est donc primordial de disposer, au sein du royaume, d'une horloge de référence, et tous les membres du royaumes doivent être synchronisés avec. Nous en comprendrons mieux l'utilité plus tard.

Dans notre réseau IP 192.168.0.0/24, nous disposons d'un serveur de temps (NTP) qui fera une horloge de référence tout à fait acceptable.

Dans ce réseau, un hôte kerberos.maison.mrs va héberger le « serveur » kerberos. Installation du paquet krb5-admin-server :

kerberos:~# aptitude install krb5-admin-server
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Lecture de l'information d'état étendu      
Initialisation de l'état des paquets... Fait
Lecture des descriptions de tâches... Fait  
Les NOUVEAUX paquets suivants vont être installés : 
  bind9-host{a} geoip-database{a} krb5-admin-server krb5-config{a}
  krb5-kdc{a} krb5-user{a} libbind9-50{a} libcap2{a} 
  libdns53{a} libgeoip1{a} libgssrpc4{a} libisc50{a}
  libisccc50{a} libisccfg50{a} libkadm5clnt-mit7{a} 
  libkadm5srv-mit7{a} libkdb5-4{a} liblwres50{a} 
0 paquets mis à jour, 18 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 2 491ko d'archives. Après dépaquetage, 6 451ko seront utilisés.
Voulez-vous continuer ? [Y/n/?] 

L'installation va poser quelques questions d'apparence anodine, mais lourdes de conséquences cependant. Comme nous allons revenir sur les fichiers de configuration, nous verrons cela plus tard.

Pour l'instant, les dépendances du paquet krb5-admin-server offrent un intérêt plus immédiat :

• krb5-config est un paquet que nous retrouverons sur tous les protagonistes de la plateforme, il va déterminer principalement la topologie du royaume kerberos ;
• krb5-user contient des outils d'utilisation de kerberos. Apriori à mettre entre les mains de tous les clients qui ont besoin de l'authentification kerberos ;
• krb5-kdc contient la partie dite kdc (Key Distribution Center), l'une des trois têtes du Cerbère. Ce paquet devra être installé sur d'éventuels « serveurs » kerberos esclaves, très utiles en production, mais inutiles ici, pour nos tests.

Les autres dépendances sont des bibliothèques associées où des outils associés à DNS.

En réalité, la paquet le plus important est ici krb5-kdc. krb5-admin-server n'apporte, comme son nom semble l'indiquer, que des outils d'administration de l'usine kerberos.

N'oublions pas de nous assurer, par un moyen quelconque, que l'horloge de cet hôte reste raisonnablement synchronisée avec notre référence de temps.

Ici, juste une station de travail sur laquelle nous installons krb5-user. Par dépendance, krb5-config viendra avec.

krb5-user fournira les outils qui permettront :

• aux administrateurs du royaume de faire leur travail d'administration ;
• aux utilisateurs d'obtenir auprès du KDC les accréditations qui leurs seront nécessaires.

Dans ce scénario, l'hôte client s'appèlera pchris.maison.mrs et fonctionnera sous Ubuntu Karmic Koala.

Ce serveur est destiné à fournir des services dont l'accès sera autorisé ou non, en fonction des accréditations que ses clients pourront obtenir du KDC. Dans cet exemple, nous installerons un serveur http (apache) dont l'accès sera soumis à authentification via kerberos.

Le paquet krb5-user sera installé dessus également.

Dans ce scénario, le serveur s'appèlera apache-krb.maison.mrs, il fonctionnera sous Debian Squeeze.

L'installation du paquet krb5-config a créé un fichier /etc/krb5.conf qu'il a adapté en fonction de quelques questions posées par le script d'installation. Le contenu de ce fichier ne satisfait pas nos petits besoins. En voici une première version propre à nous satisfaire :

[libdefaults]
        default_realm = MAISON.MRS
        dns_lookup_realm = false
        dns_lookup_kdc = false

[realms]
MAISON.MRS = {
         kdc = 192.168.0.133
        admin_server = 192.168.0.133
        default_domain = MAISON.MRS
}

[domain_realm]
        .maison.mrs = MAISON.MRS
        maison.mrs = MAISON.MRS

[logging]
        default = FILE:/var/log/krb5.log
        kdc = FILE:/var/log/krb5kdc.log
        admin-server = FILE:/var/log/krb5adm.log

L'analogie entre les noms du domaine DNS et du royaume kerberos n'est pas un hasard. Lorsque l'on construit un royaume kerberos, c'est généralement au sein d'un domaine DNS, autant leur donner le même nom. Simplement, un nom de royaume s'écrit toujours en lettres capitales.

Si vous voulez en savoir plus sur les divers paramètres de ce fichier de configuration, installez le paquet krb5-doc qui contient entre autres le manuel de krb5.conf.

L'installation de krb5-kdc a créé un répertoire /etc/krb5kdc qui contient actuellement un unique fichier kdc.conf :

[kdcdefaults]
    kdc_ports = 750,88

[realms]
    MAISON.MRS = {
        database_name = /var/lib/krb5kdc/principal
        admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
        acl_file = /etc/krb5kdc/kadm5.acl
        key_stash_file = /etc/krb5kdc/stash
        kdc_ports = 750,88
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
        default_principal_flags = +preauth
    }

Il n'y a rien à redire à cette configuration, mais il y a à remarquer qu'il est fait référence à trois fichiers qui n'existent pas encore : /var/lib/krb5kdc/principal, /etc/krb5kdc/kadm5.keytab et /etc/krb5kdc/kadm5.acl. Autant dire que l'usine ne va pas démarrer toute seule, il y a encore du travail à faire.

Il faut commencer par créer la base de données pour notre royaume MAISON.MRS. Le moyen le plus standard de le faire est d'employer la commande kdb5_util :

kerberos:~# kdb5_util -r MAISON.MRS create -s
Loading random data
... (un (long) moment plus tard)...
Initializing database '/var/lib/krb5kdc/principal' for realm 'MAISON.MRS',
master key name 'K/M@MAISON.MRS'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: 
Re-enter KDC database master key to verify: 

Le mot depasse demandé ici a toutes les chances de ne jamais servir, sauf en cas de maintenance forcée de la base. En cas d'oubli, point de salut…

En attendant, /var/lib/krb5kdc/ a été peuplé :

kerberos:/var/lib/krb5kdc# ls -l
total 16
-rw------- 1 root root 8192 févr. 13 15:57 principal
-rw------- 1 root root 8192 févr. 13 15:57 principal.kadm5
-rw------- 1 root root    0 févr. 13 15:57 principal.kadm5.lock
-rw------- 1 root root    0 févr. 13 15:57 principal.ok

Pour démarrer l'usine, il nous faut encore un fichier /etc/krb5kdc/kadm5.acl, même vide pour l'instant :

kerberos:/etc/krb5kdc# touch /etc/krb5kdc/kadm5.acl

Normalement, nous pouvons maintenant faire démarrer l'usine :

kerberos:/etc/krb5kdc# /etc/init.d/krb5-kdc start
kerberos:/etc/krb5kdc# /etc/init.d/krb5-admin-server start
kerberos:/etc/krb5kdc# ps aux | grep krb
root      2363  0.0  0.1   3468   556 ?        Ss   16:06   0:00 /usr/sbin/krb5kdc
kerberos:/etc/krb5kdc# ps aux | grep kadmin
root      2367  0.0  0.1   3424   736 ?        Ss   16:07   0:00 /usr/sbin/kadmind

Nous allons maintenant créer un « principal » pour un administrateur de ce royaume. A ce stade, nous ne pouvons le faire que localement, car il faut disposer d'un principal d'administrateur du royaume pour pouvoir le faire à distance. C'est le coup de l'œuf et de la poule…

Utilisons pour ceci la commande interactive kadmin.local :

kerberos:/etc/krb5kdc# kadmin.local 
Authenticating as principal root/admin@MAISON.MRS with password.

kadmin.local:  add_principal -clearpolicy chris/admin

Enter password for principal "chris/admin@MAISON.MRS": 
Re-enter password for principal "chris/admin@MAISON.MRS": 
Principal "chris/admin@MAISON.MRS" created.
kadmin.local:  quit

Ici, quelques explications ne sont sans doute pas superflues.

• le principal root/admin@MAISON.MRS est fictif, du moins pour l'instant, et n'est utilisable que par la commande kadmin.local. C'est l'œuf originel (ou la poule), en quelque sorte ;
• une fois l'outil d'administration interactif local démarré, nous créons un « vrai » principal avec la commande:
  add_principal -clearpolicy chris/admin
  cette commande va créer le principal chris/admin avec un mot de passe associé. Nous ne nous préoccupons pas pour l'instant des « policy » ;
• ce principal est ici constitué de deux parties :
  • la partie à gauche du /, obligatoire, et qui devrait correspondre à un utilisateur UNIX, ici chris ;
  • la partie à droite du /, optionnelle, qui sert à distinguer les différents rôles que peut jouer un même utilisateur, ici admin. Nous n'allons pas tarder à en comprendre le sens.

Nous allons maintenant justement définir les privilèges qu'accordent le rôle admin pour la gestion du royaume :

kerberos:~# echo '*/admin *' >> /etc/krb5kdc/kadm5.acl

Nous ajoutons dans « l' Access Control List » une ligne qui veut dire en français : tous les principaux affublés du rôle « admin » (*/admin) auront tous les droits d'administration ( *).

Nous avons désormais un œuf (ou une pondeuse) et nous pouvons tester si la reproduction va pouvoir se faire dans de bonnes conditions. Mais avant, il faut redémarrer le service d'administration de l'usine (à cause de la modification de l'ACL):

kerberos:/etc/krb5kdc# /etc/init.d/krb5-admin-server restart

Voyons d'abord s'il est possible de s'authentifier avec ce principal :

kerberos:/etc/krb5kdc# kinit -V chris/admin
Password for chris/admin@MAISON.MRS: 
Authenticated to Kerberos v5

Ça marche. Utilisons maintenand la commande kadmin assez proche de kadmin.local à part qu'elle est utilisable depuis tout hôte correctement configuré (krb5.conf) où elle est installée et qui nécessite absolument de s'identifier comme /admin :

kerberos:/etc/krb5kdc# kadmin -p chris/admin
Authenticating as principal chris/admin with password.
Password for chris/admin@MAISON.MRS: 
kadmin:  add_principal -clearpolicy chris
Enter password for principal "chris@MAISON.MRS": 
Re-enter password for principal "chris@MAISON.MRS": 
Principal "chris@MAISON.MRS" created.

Nous avons créé un principal pour chris, mais cette fois-ci sans aucun rôle particulier. Le mot de passe devrait être différent de celui du principal chris/admin, pour des raisons de sécurité bien entendu.

profitons pour lire la liste des principaux existants :

kadmin:  list_principals
K/M@MAISON.MRS
chris/admin@MAISON.MRS
chris@MAISON.MRS
kadmin/admin@MAISON.MRS
kadmin/changepw@MAISON.MRS
kadmin/history@MAISON.MRS
kadmin/kerberos.maison.mrs@MAISON.MRS
krbtgt/MAISON.MRS@MAISON.MRS

Nous retrouvons bien les deux principaux que nous avons créés, avec en plus quelques autres, créés avec la base de données du royaume.

Si vous avez bien suivi, vous devez pouvoir répondre à la question suivante : Est-ce que la commande kadmin -p chris va permettre de créer de nouveaux principaux ?

Bon. Le royaume existe, dispose d'un administrateur (chris/admin) et d'un sujet (chris). Pour l'instant, c'est une petite usine. Nous allons maintenant ajouter dans le royaume une simple station de travail, avec les outils nécessaires pour obtenir une authentification kerberos depuis notre « KDC » (Key Distribution Center, il est peut-être temps de le dire).