Manuel FreeBSD
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 | Sommaire | Suivant
L'encapsuleur TCP (“TCP Wrappers”) | Niveau supérieur | Kerberos5 ** Traduction en Cours **

Ce document, ainsi que d'autres peut être téléchargé sur 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>.