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.
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.
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#lsREADME 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.confEXAMPLE.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.realmsgrunt.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_initRealm name [default ATHENA.MIT.EDU ]:EXAMPLE.COMYou 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:
#kstashEnter 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.
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_editOpening 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:passwdInstance:grunt<Not found>,Create [y] ?yPrincipal: passwd, Instance: grunt, kdc_key_ver: 1New Password:<---- entrez RANDOM ici Verifying passwordNew Password:<---- enter RANDOM hereRandom password [y] ?yPrincipal's new key version = 1Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?Edit O.K.Principal name:rcmdInstance:grunt<Not found>,Create [y] ?Principal: rcmd, Instance: grunt, kdc_key_ver: 1New Password:<---- entrez RANDOM ici Verifying passwordNew Password:<---- entrez RANDOM iciRandom password [y] ?Principal's new key version = 1Expiration 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
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 gruntEnter 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
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_editOpening 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:janeInstance:<Not found>,Create [y] ?yPrincipal: jane, Instance: , kdc_key_ver: 1New Password:<---- entrez un mot de passe sûr ici Verifying passwordNew Password:<---- réentrez le mot de passe sûr là Principal's new key version = 1Expiration 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
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 janeMIT 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:
%klistTicket 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:
%passwdrealm EXAMPLE.COMOld password for jane:New Password for jane:Verifying passwordNew Password for jane:Password changed.
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_editOpening 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:janeInstance:root<Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1New Password:<---- entrez un mot de passe SUR ici Verifying passwordNew Password:<---- réentrez le mot de passe ici Principal's new key version = 1Expiration 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.rootMIT Project Athena (grunt.example.com) Kerberos Initialization for "jane.root"Password:
Nous devons maintenant ajouter l'utilisateur au fichier
.klogin de
root:
#cat /root/.kloginjane.root@EXAMPLE.COM
Essayons maintenant la commande su(1):
%suPassword:
et voyons quelles sont nos caractéristiques:
#klistTicket 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
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/.kloginjane.root@EXAMPLE.COM
De même, si un utilisateur a dans son répertoire des lignes de la forme:
%cat ~/.kloginjane@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:
%kinitMIT Project Athena (grunt.example.com)Password:%rlogin gruntLast 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 janeMIT 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
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>.