14.7. Kerberos
Précédent | Chapitre 14. Sécurité | Suivant

## 14.7. Kerberos

Contribution de Mark Murray.
Basée sur une contribution de Mark Dapoz.

Kerberos est un protocole réseau supplémentaire qui permet aux utilisateurs de s'authentifier par l'intermédiaire d'un serveur sécurisé. Des services comme l'ouverture de session et la copie à distance, la copie sécurisée de fichiers entre systèmes et autres fonctionnalités à haut risque deviennent ainsi considérablement plus sûrs et contrôlables.

Les instructions qui suivent peuvent être utilisées comme guide d'installation de Kerberos dans la version distribuée pour FreeBSD. Vous devriez cependant vous référer aux pages de manuel correspondantes pour avoir une description complète.

### 14.7.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.7.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.7.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.7.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.7.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.7.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.7.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.7.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

Précédent | Niveau supérieur | Suivant
14.6. L'encapsuleur TCP (« TCP Wrappers ») | Sommaire | 14.8. Kerberos5 ** Traduction en Cours **

Ce document, ainsi que d'autres peut être téléchargé sur ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.