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
#
ls
README krb.conf krb.realmsS'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.govDans 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.EDUEncore 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
.
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 programmeIl 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
sur un support amovible et transportez-le par un moyen
physiquement sûr. Assurez-vous de le renommer en
client
-new-srvtabsrvtab
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_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 programmeIl 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.COMEssayons 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.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 programmeVé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.COMEssayons 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.COMDans 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.COMDe même, si un utilisateur a dans son répertoire des lignes de la forme:
%
cat ~/.klogin
jane@EXAMPLE.COM
jack@EXAMPLE.COMCela 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 1995Ou 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 1995Ce 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>.