14.6. Kerberos

14.6.1. Installation de Kerberos

Kerberos est un composant optionnel de FreeBSD. La manière la plus simple d'installer ce logiciel est de sélectionner la distribution krb4 ou krb5 dans sysinstall lors de l'installation de FreeBSD. Cela installera les implémentations ``eBones'' (KerberosIV) ou ``Heimdal'' (Kerberos5) de Kerberos. Ces implémentations sont distribuées car elles sont développées en dehors des USA ou du Canada et étaient par conséquent disponibles aux utilisateurs hors de ces pays durant l'ère restrictive du contrôle des exportations de code de chiffrement à partir des USA.

Alternativement, l'implémentation du MIT de Kerberos est disponible dans le catalogue des logiciels portés sous security/krb5.

14.6.2. Créer la base de données initiale

Cela se fait uniquement sur le serveur Kerberos. Vérifiez tout d'abord qu'il ne traîne pas d'anciennes bases Kerberos. Allez dans le répertoire /etc/kerberosIV et assurez-vous qu'il ne contient que les fichiers suivants:

# cd /etc/kerberosIV
# ls
README      krb.conf        krb.realms

S'il y a d'autres fichiers (comme principal.* ou master_key), utilisez alors la commande kdb_destroy pour supprimer l'ancienne base de données Kerberos, ou si Kerberos ne tourne pas, effacez simplement les fichiers supplémentaires.

Vous devez maintenant éditer les fichiers krb.conf et krb.realms pour définir votre domaine Kerberos. Dans notre cas, le domaine sera EXAMPLE.COM et le serveur grunt.example.com. Nous éditons ou créons le fichier krb.conf:

# cat krb.conf
EXAMPLE.COM
EXAMPLE.COM grunt.example.com admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.gov

Dans notre cas les autres domaines n'ont pas besoin d'être mentionnés. Ils ne sont là que pour montrer comment une machine peut avoir connaissance de plusieurs domaines. Pour plus de simplicité, vous pouvez ne pas les inclure.

La première ligne indique pour quel domaine cette machine agit. Les autre lignes définissent les autres domaines/machines. Le premier élément sur une ligne est le domaine, le second le nom de la machine qui est le ``centre de distribution de clés'' de ce domaine. Les mots admin server qui suivent un nom de machine signifient que la machine est aussi serveur d'administration de la base de données. Pour plus d'explication sur cette terminologie, consultez les pages de manuel de Kerberos.

Nous devons maintenant ajouter grunt.example.com au domaine EXAMPLE.COM et ajouter une entrée pour mettre toutes les machines du domaine DNS .example.com dans le domaine Kerberos EXAMPLE.COM. Le fichier krb.realms aura alors l'allure suivante:

# cat krb.realms
grunt.example.com EXAMPLE.COM
.example.com EXAMPLE.COM
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDU

Encore une fois, les autres domaines n'ont pas besoin d'être mentionnés. Ils ne sont là que pour montrer comment une machine peut avoir connaissance de plusieurs domaines. Pour plus de simplicité, vous pouvez ne pas les inclure.

La première ligne assigne un système particulier au domaine désigné. Les lignes restantes montrent comment affecter par défaut les systèmes d'un sous-domaine DNS particulier à un domaine Kerberos donné.

Nous sommes maintenant prêt pour la création de la base de données. Il n'y a à le faire que sur le serveur Kerberos (ou Centre de Distribution de Clés). Cela se fait avec la commande kdb_init:

# kdb_init
Realm name [default  ATHENA.MIT.EDU ]: EXAMPLE.COM
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.

Enter Kerberos master key:

Nous devons maintenant sauvegarder la clé pour que les serveurs sur la machine locale puissent la lire. Utilisons la commande kstash pour faire cela:

# kstash

Enter Kerberos master key:

Current Kerberos master key version is 1.

Master key entered. BEWARE!

Le mot de passe maître chiffré est sauvegardé dans /etc/kerberosIV/master_key.

14.6.3. Installer les services

Il faut ajouter deux entrées (``principals'') à la base de données pour chaque système qui sera sécurisé par Kerberos. Ce sont kpasswd et rcmd. Ces deux entrées sont définies pour chaque système, chacune de leurs instances se voyant attribuer le nom du système.

Ces ``daemons'', kpasswd et rcmd permettent aux autres systèmes de changer les mots de passe Kerberos et d'exécuter des commandes comme rcp(1), rlogin(1), et rsh(1).

Ajoutons donc maintenant ces entrées:

# kdb_edit
Opening database...

Enter Kerberos master key:

Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.

Principal name: passwd
Instance: grunt

<Not found>, Create [y] ? y

Principal: passwd, Instance: grunt, kdc_key_ver: 1
New Password:                    <---- entrez RANDOM ici
Verifying password

New Password: <---- enter RANDOM here

Random password [y] ? y

Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: rcmd
Instance: grunt

<Not found>, Create [y] ?

Principal: rcmd, Instance: grunt, kdc_key_ver: 1
New Password:       <---- entrez RANDOM ici
Verifying password

New Password:           <---- entrez RANDOM ici

Random password [y] ?

Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name:         <---- ne rien entrer ici permet de quitter le programme

14.6.4. Créer le fichier des services

Il faut maintenant extraire les instances qui définissent les services sur chaque machine. Pour cela on utilise la commande ext_srvtab. Cela créera un fichier qui doit être copié ou déplacé par un moyen sûr dans le répertoire /etc/kerberosIV de chaque client Kerberos. Ce fichier doit être présent sur chaque serveur et client, et est crucial au bon fonctionnement de Kerberos.

# ext_srvtab grunt
Enter Kerberos master key:

Current Kerberos master key version is 1.

Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....

Cette commande ne génère qu'un fichier temporaire qui doit être renommé en srvtab pour que tous les serveurs puissent y accéder. Utilisez la commande mv(1) pour l'installer sur le système d'origine:

# mv grunt-new-srvtab srvtab

Si le fichier est destiné à un client, et que le réseau n'est pas considéré comme sûr, alors copiez le fichier client-new-srvtab sur un support amovible et transportez-le par un moyen physiquement sûr. Assurez-vous de le renommer en srvtab dans le répertoire /etc/kerberosIV du client, et mettez-le bien en mode 600:

# mv grumble-new-srvtab srvtab
# chmod 600 srvtab

14.6.5. Renseigner la base de données

Nous devons maintenant créer des entrées utilisateurs dans la base de données. Tout d'abord créons une entrée pour l'utilisateur jane. Utilisez la commande kdb_edit pour cela:

# kdb_edit
Opening database...

Enter Kerberos master key:

Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.

Principal name: jane
Instance:

<Not found>, Create [y] ? y

Principal: jane, Instance: , kdc_key_ver: 1
New Password:                <---- entrez un mot de passe sûr ici
Verifying password

New Password:                <---- réentrez le mot de passe sûr là
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name:          <---- ne rien entrer ici permet de quitter le programme

14.6.6. Tester l'ensemble

Il faut tout d'abord démarrer les ``daemons'' Kerberos. Notez que si vous avez correctement modifié votre fichier /etc/rc.conf, cela se fera automatiquement au redémarrage du système. Ceci n'est nécessaire que sur le serveur Kerberos. Les clients Kerberos récupéreront automatiquement les informations dont ils ont besoin via leur répertoire /etc/kerberosIV.

# kerberos &
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.

Master key entered. BEWARE!

Current Kerberos master key version is 1
Local realm: EXAMPLE.COM
# kadmind -n &
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead

Current Kerberos master key version is 1.

Master key entered.  BEWARE!

Nous pouvons maintenant utiliser la commande kinit pour obtenir un ``ticket d'entrée'' pour l'utilisateur jane que nous avons créé plus haut:

% kinit jane
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane"
Password:

Essayons de lister les informations associées avec la commande klist pour voir si nous avons vraiment tout ce qu'il faut:

% klist
Ticket file:    /tmp/tkt245
Principal:      jane@EXAMPLE.COM

  Issued           Expires          Principal
Apr 30 11:23:22  Apr 30 19:23:22  krbtgt.EXAMPLE.COM@EXAMPLE.COM

Essayons maintenant de modifier le mot de passe en utilisant la commande passwd(1) pour vérifier si le ``daemon'' kpasswd est autorisé à accéder à la base de données Kerberos:

% passwd
realm EXAMPLE.COM
Old password for jane:
New Password for jane:
Verifying password
New Password for jane:
Password changed.

14.6.7. Autoriser l'utilisation de la commande su

Kerberos permet d'attribuer à chaque utilisateur qui a besoin des droits du super-utilisateur son propre mot de passe su(1). Nous pouvons créer un identifiant qui est autorisé à utiliser su(1) pour devenir root. Cela se fait en associant une instance root un identificateur (``principal'') de base. En utilisant la commande kdb_edit nous pouvons créer l'entrée jane.root dans la base de données Kerberos:

# kdb_edit
Opening database...

Enter Kerberos master key:

Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.

Principal name: jane
Instance: root

<Not found>, Create [y] ? y

Principal: jane, Instance: root, kdc_key_ver: 1
New Password:                    <---- entrez un mot de passe SUR ici
Verifying password

New Password:            <---- réentrez le mot de passe ici

Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Laissez une valeur faible!
Attributes [ 0 ] ?
Edit O.K.
Principal name:                <---- ne rien entrer ici permet de quitter le programme

Vérifions maintenant les caractéristiques associées pour voir si cela fonctionne:

# kinit jane.root
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane.root"
Password:

Nous devons maintenant ajouter l'utilisateur au fichier .klogin de root:

# cat /root/.klogin
jane.root@EXAMPLE.COM

Essayons maintenant la commande su(1):

% su
Password:

et voyons quelles sont nos caractéristiques:

# klist
Ticket file:    /tmp/tkt_root_245
Principal:      jane.root@EXAMPLE.COM

  Issued           Expires          Principal
May  2 20:43:12  May  3 04:43:12  krbtgt.EXAMPLE.COM@EXAMPLE.COM

14.6.8. Utiliser d'autres commandes

Dans l'exemple précédent, nous avons créé une entrée principale nommée jane avec une instance root. Cette entrée reposait sur un utilisateur ayant le même nom que l'entrée principale, c'est ce que fait par défaut Kerberos; une <entrée_principale>.<instance> de la forme <nom_d_utilisateur>.root autorisera <nom_d_utilisateur>. à utiliser su(1) pour devenir root si le fichier .klogin du répertoire personnel de l'utilisateur root est correctement renseigné:

# cat /root/.klogin
jane.root@EXAMPLE.COM

De même, si un utilisateur a dans son répertoire des lignes de la forme:

% cat ~/.klogin
jane@EXAMPLE.COM
jack@EXAMPLE.COM

Cela permet à quiconque dans le domaine EXAMPLE.COM s'étant authentifié en tant que jane ou jack (via kinit, voir plus haut) d'accéder avec rlogin(1) au compte de jane ou à ses fichiers sur le système (grunt) via rlogin(1), rsh(1) ou rcp(1).

Par exemple, jane ouvre maintenant une session sur un autre système en utilisant Kerberos:

% kinit
MIT Project Athena (grunt.example.com)
Password:
% rlogin grunt
Last login: Mon May  1 21:14:47 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.   All rights reserved.

FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995

Ou bien jack ouvre une session sur le compte de jane sur la même machine (jane ayant modifié son fichier .klogin comme décrit plus haut, et la personne an charge de Kerberos ayant défini une entrée principale jack sans instance):

% kinit
% rlogin grunt -l jane
MIT Project Athena (grunt.example.com)
Password:
Last login: Mon May  1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.   All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995