NTP :

Les machines vont interagir entre elles. Du coup, elles doivent être synchrones.

On commence par l’installation de paquet NTP sur les deux machines :

Les machines doivent avoir la même horloge que server-kdc. Donc on doit configurer son ntp.conf en premier.

7

 Ces deux lignes indiquent au serveur qu'il doit se synchroniser sur l'horloge local. Comme vous le constatez 127.127.1.0 ne représente pas l'adresse IP de la boucle locale. C'est en fait un subterfuge pour indiquer un pilote factice qui aurait pu faire référence à un oscillateur externe.

 Ces lignes permettent de mettre en place des contrôles d'accès pour définir ce que sont autorisés à faire les serveurs nous fournissant le temps, et les clients se connectant.

Il faut indiquer sur quelle adresse ntp fait l’écoute, dans ce cas ntp écoute sur tous les adresses.

Maintenant on modifie le fichier /etc/ntp.conf sur la machine Client :

8

 Ces deux lignes permettent au client de synchroniser le temps avec la machine « server-kdc »

On redémarre le service ntp pour enregistrer les modifications en tapant « service ntp restart ».

Une fois les fichiers ntp.conf configurés, on peut synchroniser le réseau de machine avec le serveur de temps local 192.168.79.131 correspondant à notre machine Kerberos (KDC) :

La commande « ntpdate » permet de synchroniser une machine avec le serveur de temps « server-kdc ».

9 Sur la machine client :

« offset = -0.7977577 sec » : il y’a une synchronisation entre le serveur de temps la machine « server-kdc » et la machine client

3. Kerberos :

a. Configuration de kerberos sur la machine serveur (server-kdc):

Dans cette première partie, on va installer et configurer le KDC Kerberos. On exécute donc les commandes suivantes:

Lors de l'installation du paquet par apt-get, il nous est demandé le nom du royaume (realm) Kerberos par défaut. Il nous est ensuite demandé le nom du serveur Kerberos du royaume ainsi que le nom du serveur d'administration.

On a précisé "server-kdc", le nom de notre station :

10

b. Configuration du royaume:

On configure le fichier /etc/krb5.conf : En installant le package de Kerberos, on le configure comme suit :

 On définit server-kdc comme serveur Kerberos dans le royaume et comme serveur administratif du royaume

Ensuite, on configure le fichier /etc/krb5.conf :

ces lignes permettent d’envoyer la sortie vers ces fichiers log

Voici le contenu du fichier /etc/krb5kdc/kdc.conf correspondant à la configuration du KDC:

11 Ce fichier contient :

 Les informations sur les bases de données Kerberos, des keytab et des acl.

 Les ports du KDC.

 Les informations sur les encodages supportés et sur la durée de vie des credentials.

Puis, on crée notre royaume Kerberos:

Une fois le royaume créé, il faut l’administrer en créant un principal pour l’administration de la base.

Dans notre cas c’est « root/admin@INF.ED.AC.UK»:

La commande « kadmin.local » nous permet ainsi de nous connecter en local sur l'admin-server et de pouvoir créer des politiques, des principals...

12

Ensuite, on crée le fichier «/etc/krb5kdc/kadmin.acl » qui définit les privilèges des principaux à créer.

Enfin, on peut tester l’authentification Kerberos:

 kinit : qui va initialiser une connexion kerberos

 klist : qui va montrer les sessions kerberos

Pour pouvoir utiliser "kadmin" en distant, nous devons créer les keytab pour les deux utilisateurs kadmin/admin et kadmin/changepw :

Maintenant que tout est configuré, nous allons donc démarrer krb5kdc et kadmind pour pouvoir utiliser kadmin en local et en distant.

c. Configuration de la machine Client

Pour que le client bénéficie des apports de la méthode d’authentification de Kerberos, on peut installer le paquet krb5-user.

Nous devons tout d'abord rajouter dans /etc/krb5.conf de la machine enseignant la déclaration de notre royaume « INF.ED.AC.UK »

13

Chaque fois l’utilisateur demande un ticket il doit entrer son mot de passe mais en utilisant les fichiers keytab on peut avoir des tickets sans intervention humaine.

 Un keytab est un fichier contenant des paires de principals Kerberos avec une copie cryptée de la clé de chaque principal. Les fichiers keytab sont uniques à chaque hôte puisque leurs clés comprennent le hostname. Ce fichier est utilisé pour authentifier un principal sur un hôte pour Kerberos sans intervention humaine ou de stocker un mot de passe dans un fichier texte.

Sur la machine « server-kdc », on a ajouté un nouveau principal « utilisateur/admin »

Maintenant sur la machine « client » on sauvagarde pour le principal le mot de passe crypté dans un fichier keytab q’un doit indiquer

14

Maintenant, en demandant un ticket TGT et en indiquant le fichier keytab on n’a plus besoin de taper le mot de passe et si c’est le fichier par default if suffit de taper « kinit utilisateur/admin »

4. SSH :

SSH est un protocole de prise de commande a distance de manière sécurisée.

Il fonctionne en mode client/serveur.

Sur la machine serveur il suffit d’installer « openssh-server »

Pour la machine client, on doit installer « openssh-client »

Pour que ssh utilise kerberos pour son authentification , on doit modifier quelques parametres dans le fichier « /etc/ssh/sshd_config»

GSSAPI est une API pour homogénéiser l'authentification des échanges client-serveur sécurisés. Donc pour activer l’authentification avec il faut changer sa valeur a « yes »

De même pour la machine client, dans le fichier « /etc/ssh.ssh_config » , on doit modifier ces deux lignes en mettant ses valeurs a « yes »

Avant de tester le fonctionnement de ssh, chaque service kerborizé doit avoir un principal sur la machine KDC sous la forme « nom_service/nom_machine_KDC@REALM » avec l’option randkey un fichier « keytab » associé à ce service, ensuite il faut spécifier un autre principal qui prend le nom d’un « user » sur la machine client.

Dans le cas de ssh le principal associé à ce service doit prendre le nom « host »

15

Maintenant, on peut tester le fonctionnement du service ssh en tapant « ssh server-kdc » sur la machine client