Voyons tout d'abord comment ça se présente du côté de l'utilisateur à peine averti, sur une plateforme de tests très rudimentaire.

Grâce aux avantages de KVM nous pouvons disposer d'autant de machines que nous le souhaitons, profitons-en.

• un serveur kerberos.maison.mrs se charge de faire fonctionner l'usine à gaz ;
• un serveur apache-krb.maison.mrs est un serveur http tout bête, sauf qu'il n'autorise l'accès qu'aux personnes duement authentifiées par kerberos ;
• un client qui voudrait bien accéder au contenu de apache-krb.maison.mrs depuis un poste de travail qui dispose des outils nécessaires pour dialoguer avec kerberos.maison.mrs.

Première prise, l'utilisateur, qui s'appèle chris, n'a pas fait risette à kerberos, et essaye d'accéder à http://apache-kerb.maison.mrs :

Il se fait jeter…

Chris lit alors la notice où on lui explique qu'il doit d'abord s'authentifier auprès du cerbère en utilisant la commande kinit :

~$ kinit chris
Password for chris@MAISON.MRS: 

Confiant, il re essaye :

Et là, chris peut fermer son navigateur puis le ré-ouvrir, retourner sur la même page et ça marchera encore.

Si tout ceci fonctionne, c'est parce que :

• kerberos.maison.mrs gère un « royaume » kerberos nommé MAISON.MRS. Dans ce royaume, il y a :
  • des utilisateurs enregistrés (chris entre autres) ;
  • des services sur des hôtes (HTTP/apache-krb.maison.mrs) y sont aussi enregistrés ;
• apache-krb.maison.mrs dispose d'un apache2 configuré pour authentifier les utilisateurs avec kerberos :
  • un module spécial, auth_kerb est chargé et utilisé dans la configuration de l'indien ;
  • un « tableau de clés » (keytab) a été placé sur ce serveur, de manière à ce qu'il sache à qui s'adresser pour que l'usine à gaz (kerberos) fonctionne sans fumées ni explosions.
• le poste client quant-à-lui utilise les outils nécessaires à l'utilisateur et aussi ceux de l'administrateur du royaume, mais nous verrons ça plus loin). De plus, le navigateur, ici « Firefox » a été instruit de la procédure à suivre en cas de demande d'authentification kerberos. Ceci est réalisé diversement suivant les distributions. Voici la ligne concernée lorsque l'on utilise l'URI about:config :
  network.negotiate-auth.trusted-uris;https://,http://
  Ici, la négociation est demandée pour tout URI correspondant aux protocoles http et https.

Pour les trois protagonistes, il y a un fichier de configuration (le même sur les trois), qui définit la configuration du royaume kerberos qui, vous l'avez deviné, s'appelle ici MAISON.MRS. Même nom que le domaine dns, mais en majuscules.

C'est le fichier de configuration du royaume, commun ici à tous les protagonistes :

[realms]
MAISON.MRS = {
      kdc = 192.168.0.133          # kerberos.maison.mrs
      admin_server = 192.168.0.133 # kerberos.maison.mrs
      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

[appdefaults]
        pam = {
                debug = true
                forwardable = true
                krb4_convert = false
        }

Pour l'instant, la partie [appdefaults] n'a pas d'utilité, mais si l'on y parle de pam c'est qu'il y a sans doute moyen d'utiliser kerberos pour les ouvertures de session…

Le peu qu'il y a ici n'est pas très difficile à interpréter, nous passerons rapidement. La chose remarquable est que dans le royaume MAISON.MRS, il y a un kdc et un admin_server. Ils sont confondus ici sur la même machine (je n'ai que 4 Go de RAM), mais il est possible de placer ces deux fonctions sur des hôtes différents. Elles correspondent d'ailleurs à deux paquets différents :

• krb5-kdc
• krb5-admin-server

Les noms sont assez explicites.

L'autre chose remarquable est que le nom dns du domaine est le même que celui du royaume kerberos. Ce n'est pas indispensable, mais souhaitable, d'autant que c'est ainsi dans Active Directory.

En réalité, la définition des royaumes peut être plus complexe, un hôte peut appartenir à plusieurs royaumes et un utilisateur peut s'authentifier dans plusieurs royaumes, si nécessaire, mais ne compliquons pas inutilement les choses.

Sur apache, nous avons un tableau de clés que l'on peut consulter avec la commande klist :

apache-krb:~# klist -k /etc/apache2/krb5.keytab 
Keytab name: FILE:/etc/apache2/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   3 host/apache-krb.maison.mrs@MAISON.MRS
   3 host/apache-krb.maison.mrs@MAISON.MRS
   3 host/apache-krb.maison.mrs@MAISON.MRS
   3 host/apache-krb.maison.mrs@MAISON.MRS
   3 HTTP/apache-krb.maison.mrs@MAISON.MRS
   3 HTTP/apache-krb.maison.mrs@MAISON.MRS
   3 HTTP/apache-krb.maison.mrs@MAISON.MRS
   3 HTTP/apache-krb.maison.mrs@MAISON.MRS

Prenons-le comme tel pour le moment, nous comprendrons mieux plus tard.

Il s'agit de la configuration par défaut du serveur par défaut à laquelle il a été ajouté les paramètres relatifs à l'authentification kerberos :

	<Directory /var/www/>
	        AuthName "Secure Access"
        	AuthType Kerberos
	        Krb5Keytab /etc/apache2/krb5.keytab
        	KrbMethodK5Passwd off
	        KrbSaveCredentials on
        	require valid-user

		Options Indexes FollowSymLinks MultiViews
		AllowOverride None
		Order allow,deny
		allow from all
	</Directory>

Nous avons pu observer suffisamment de choses pour mieux comprendre le principe de kerberos et accessoirement pourquoi ce protocole a-t-il été appelé ainsi.

• l'utilisateur doit disposer d'un principal dont il fait la demande à une entité nommée AS, au moyen de la commande kinit. Nous verrons plus loin que cette demande peut être automatisée lors de l'ouverture de la session par l'utilisateur. Cette procédure aboutit au fait que l'utilisateur en question a été authentifié par « l'AS » qui lui a transmis une « chose » (le principal) dont la validité est limitée dans le temps ;
• lorsque l'utilisateur souhaite utiliser un service soumis à une authentification par kerberos, sous réserve que l'application cliente qui doit communiquer avec ce service sache le faire, le client obtient silencieusement un « ticket spécial » en faisant une requête non moins silencieuse au service TGS de kerberos, et que ce ticket spécial lui ouvre les portes du service convoité.

Nous avons donc pu constater de façon subtile l'effet « SSO » de kerberos. Cet effet serait bien sûr beaucoup plus visible si en plus d'un service http, nous avions mis en place d'autres services, comme un système de fichier en réseau (NFS v4 par exemple), ssh, ftp voire aussi un proxy http comme squid.

Reste à démonter le mécanisme et à voir de plus près l'aspect sécuritaire de ce protocole.