TELECOM- ANNEE 2003/2004

(1)

TELECOM- ANNEE 2003/2004

Option SSR – Projet de fin d’étude

Authentification forte auprès d'un serveur LDAP par la méthode SASL Kerberos

EI3 Option SSR

Enseignant encadrant : Maryline MAKNAVICIUS-LAURENT

Vivien LE POUPON Vincent ROYER

(2)

Table de matières

Introduction ... 4

1. Kerberos ... 5

1.1 Présentation ... 5

1.2 Architecture ... 6

1.2.1 Le Royaume Kerberos (Kerberos Realm) :... 6

1.2.2 Les « principals » : ... 6

1.2.3 Le serveur Kerberos ... 8

1.2.4 Les services « kerbérisés » : ... 11

1.3 Fonctionnement d’une authentification Kerberos ... 12

2 LDAP ... 14

2.1 Introduction à LDAP ... 14

2.2 Qu'est-ce que LDAP ? ... 15

2.2.1 Un annuaire LDAP est-il une base de données ? ... 15

2.2.2 Les avantages des annuaires LDAP ... 16

2.2.3 Dans quel cas utiliser LDAP pour stocker des données ? ... 16

2.3 Structure d'un arbre d'annuaire LDAP ... 17

3 Authentification Kerberos/SASL pour accès LDAP : ... 19

3.1 Principe général... 19

3.2 Installation ... 20

3.2.1 Installation de OpenSSL et création de certificats ... 20

3.2.2 Installation Kerberos V ... 21

3.2.2.1 Installation des composants :... 21

3.2.2.2 Configuration du fichier krb5.conf : ... 21

3.2.2.3 Configuration du fichier kdc.conf : ... 22

3.2.2.4 Création de la base Kerberos pour notre « royaume » : ... 22

3.2.2.5 Configuration du fichier kadm5.acl : ... 23

3.2.2.6 Création des utilisateurs et des administrateurs Kerberos... 23

3.2.3 Installation Cyrus SASL... 24

3.2.4 Installation de OpenLDAP ... 25

3.2.4.1 Configuration du fichier ldap.conf : ... 26

3.2.4.2 Configuration du fichier slapd.conf : ... 27

3.2.4.3 Lancement du serveur LDAP :... 28

3.2.4.4 Création d’un principal LDAP dans la base Kerberos ... 28

3.2.4.5 Initialisation de la base LDAP : ... 29

3.2.4.6 A propos des listes d’accès de la base LDAP : ... 30

4 Tests ... 31

4.1 Test de services « kerbérisés » avec Kerberos V et SASL : ... 31

4.2 Test de OpenLDAP ... 34

4.2.1 Affichage des mécanismes d’authentification supportés : ... 34

4.2.2 Tests de recherches dans l’annuaire ... 35

4.2.3 Tests de modifications de la base ... 36

4.2.4 Captures de trames ... 41

(3)

Conclusion... 43

Annexe A : Génération des certificats sous OpenSSL ... 44

Annexe B : Fichiers configuration Kerberos V ... 48

1 Fichier krb5.conf : ... 48

2 Fichier kdc.conf :... 49

Annexe C : Fichiers configuration LDAP ... 50

1 Fichier ldap.conf : ... 50

2 Fichier slapd.conf : ... 54

Annexe D - Tests sur OpenLDAP ... 56

Références ... 59

(4)

Introduction

Kerberos et LDAP se sont établis comme des valeurs sûres dans leurs domaines respectifs. Leur association, d’ailleurs de plus en plus mise en pratique, est intéressante. Elle permet de sécuriser un annuaire LDAP efficacement, ce qui n’est pas réalisé par défaut par cette norme.

De plus, cette implémentation requiert l’utilisation d’éléments tels que SASL afin d’assurer le dialogue entre Kerberos et LDAP. En effet, LDAP n’est pas nativement prévu pour une mise en œuvre avec le programme d’authentification. Une

« couche » intermédiaire SASL est alors nécessaire.

Ces éléments ont donc étés pour nous une source d’intérêt supplémentaire, ce projet nous permettant de nous familiariser avec divers domaines et normes. Réussir à installer Kerberos, puis assurer son fonctionnement avec LDAP représente une expérience enrichissante, et c’est avec une grande motivation que nous nous sommes lancés dans ce projet.

Le travail s’est divisé en trois phases principales : familiarisation avec les éléments impliqués, installation et configuration de ces éléments, et enfin tests du fonctionnement.

Pour ce rapport, nous avons adoptés une structure similaire à celle de notre cheminement. Ainsi, nous allons nous appliquer à décrire brièvement Kerberos et son fonctionnement dans un premier temps, puis faire de même avec LDAP dans un deuxième temps. Ensuite, les différentes procédures d’installation et d’implémentation seront abordées. Enfin, nous détaillerons les tests qui ont étés mis en œuvre afin de s’assurer du bon fonctionnement de l’ensemble, et des paramètres de configuration à retenir.

(5)

1. Kerberos

1.1 Présentation

Kerberos est un protocole mis au point par le MIT. Il permet l’authentification forte des utilisateurs pour l’accès à certains services dits « kerbérisés ».

Kerberos est le nom du chien de la mythologie grecque gardant les portes du dieu des enfers Hadès. D'où le nom symbolique de ce protocole d’authentification réseau conçu par Miller et Neuman dans le cadre du projet Athena (démarré en 1983) du Massachusetts Institute of Technologie (MIT). Nous sommes aujourd'hui à la version 5 du protocole.

Il est standardisé et défini par 2 RFC : la RFC 1510 pour l’implémentation du protocole, et la RFC 1964 pour le mécanisme et le format d’insertion des jetons de sécurité dans les messages Kerberos.

Très largement utilisé dans le monde Unix/Linux, il également à la base du système d’authentification de l’Active Directory de Windows 2000 de Microsoft.

Le plus souvent les services accessibles au sein d’un réseau demandent l’authentification des utilisateurs. Cette authentification consiste en un login et un mot passe qui, la plupart du temps, circulent en clair sur le réseau. C’est par exemple le cas du FTP ou du Telnet.

Certaines procédures permettent de sécuriser ces échanges (certificats et cryptographie), mais étant donné le nombre, souvent très important, de services à sécuriser et le nombre d’utilisateurs et de serveurs, la mise en place et l’administration de telles architectures sont souvent très complexes.

Kerberos a pour vocation de simplifier cette architecture en centralisant l’authentification des utilisateurs et des services. Proche du concept de Single-Sign- On (SSO), Kerberos réalise l’authentification des utilisateurs et gère ensuite leur accès aux différents services. L’utilisateur s’authentifie une première fois auprès du serveur Kerberos et accède ensuite aux services de façon transparente, aucune nouvelle authentification ne lui sera demandée par aucun service dit « kerbérisé ».

(6)

1.2 Architecture

1.2.1 Le Royaume Kerberos (Kerberos Realm) :

Une architecture Kerberos est constituée de serveurs Kerberos, d’utilisateurs, de postes de travail et de serveurs hébergeant des services.

Toutes ces entités sont rassemblées et définies au sein d’un « Royaume Kerberos»

(Kerberos Realm).

1.2.2 Les « principals » :

Au sein de ce royaume, les utilisateurs et les hôtes (postes et serveurs) hébergeant des services constituent les « principals ». Il sont déclarés dans la base Kerberos selon le schéma : nom/instance@KRB-REALM

A chaque « principal » est associé un mot de passe qui fait office de clé secrète (hashage du mot de passe). Les utilisateurs doivent saisir leur mot de passe pour s’identifier auprès du serveur Kerberos et récupérer un ticket d’accès aux services.

Pour les hôtes et les services, qui ne peuvent pas saisir leur mot de passe, la clé secrète est stockée localement (sur l’hôte) dans un fichier .keytab (par exemple : /etc/krb5.keytab).

Par exemple pour le royaume INT-EVRY.FR :

¾ Les utilisateurs peuvent être déclarés comme :

o root/admin@INT-EVRY.FR pour un administrateur

(7)

o toto/eleve@INT-EVRY.FR pour un élève toto

o Dupond/enseignant@INT-EVRY.FR pour l’enseignant Dupond.

¾ Les postes de travail peuvent être déclarés comme :

o host/PC1.int-evry.fr@INT-EVRY.FR pour le poste déclaré en tant que PC1 dans le DNS du domaine int-evry.fr

o host/PC2.int-evry.fr@INT-EVRY.FR pour le poste déclaré en tant que PC2 dans le DNS du domaine int-evry.fr

¾ Les services peuvent être déclarés comme :

o ftp/server1.int-evry.fr@INT-EVRY.FR pour le serveur FTP hébergé sur le serveur déclaré en tant que server1 dans le DNS du domaine int-evry.fr

o ldap/server1.int-evry.fr@INT-EVRY.FR pour l’annuaire LDAP hébergé sur le serveur déclaré en tant que server1 dans le DNS du domaine int-evry.fr

(8)

1.2.3 Le serveur Kerberos

Le serveur Kerberos est constitué de plusieurs entités logiques qui sont souvent regroupées physiquement en un seul et même serveur.

KADMIN :

Ce module permet d’administrer le serveur Kerberos. Il gère les utilisateurs, les hôtes et services du domaine Kerberos, leurs droits d’accès (ACL), ainsi que les méthodes de chiffrement utilisées (des3-hmac-sha1, des-cbc-crc, des-cbc-md5,...).

Son accès est le plus souvent réservé à l’administrateur du domaine qui peut accéder localement au serveur (commande kadmin.local) ou à distance depuis un hôte du domaine (kadmin).

La configuration du serveur se fait à travers le fichier krb5.conf.

KDC (Key Distribution Center) :

Ce Centre de distribution des clés contient une base de données regroupant les utilisateurs, les services et les clés qui leur sont associés. Ce module a pour fonction d’authentifier les utilisateurs avant de leur offrir un accès aux services

« kerbérisés », il joue le rôle de serveur d’authentification (AS).

Pour obtenir un accès aux services « kerbérisés » un utilisateur doit avant tout obtenir un ticket d’accès (TGT : Ticket Granting Ticket) auprès du KDC.

Il s’identifie auprès du KDC en tant qu’utilisateur C (principal : C@INT-EVRY.FR, par exemple) et reçoit alors un ticket d’accès crypté avec sa clé sécrète. Il est important de noter que la clé sécrète ne circule à aucun moment sur le réseau, l’utilisateur saisit en local son mot de passe pour déchiffrer le ticket du KDC.

Le TGT reçu va ensuite permettre à l’utilisateur C de dialoguer avec le TGS (voir ci- dessous) afin d’obtenir des tickets d’accès pour les différents services « kerbérisés ».

Pour récupérer un TGT, l’utilisateur doit saisir la commande : kinit <principal> (où

« principal » désigne l’identifiant de l’utilisateur).

Le système demande alors à l’utilisateur de rentrer son mot de passe de façon à déchiffrer le ticket. Si le mot de passe est valide l’utilisateur dispose alors d’un ticket pour dialoguer avec le TGS.

(9)

Avec la commande : klist, l’utilisateur peut vérifier qu’il possède bien un ticket pour dialoguer avec le TGS.

Le TGT a une durée de vie limitée (par défaut huit heures) et prédéfinie dans le fichier de configuration kdc.conf :

L’utilisateur peut à tout moment détruire son ticket à l’aide de la commande : kdestroy.

En plus du TGT, le KDC fournit à l’utilisateur une clé de session pour dialoguer avec le TGS (clé notée Kc,tgs).

Le KDC constitue l'élément le plus sensible de tout le domaine Kerberos. S'il est compromis, c'est tout le domaine Kerberos qui est compromis avec lui. Il est donc nécessaire que le serveur hébergeant le KDC soit parfaitement sécurisé.

(10)

Le TGS (Ticket Granting Service) :

Le TGS a pour fonction de fournir des tickets d’accès aux services « kerbérisés ».

Lorsque un utilisateur souhaite accéder à un service « kerbérisé », il émet une demande auprès du TGS.

Dans cette demande le client («c») inclue l’identifiant du service auquel il souhaite accéder (« s »), le TGT qu’il a obtenu du KDC (voir partie précédente), un indicateur d’authentification (« Ac ») crypté avec la clé de session Kc,tgs (clé de session entre le client et le TGS, reçue du KDC).

Le TGS vérifie que le TGT est bien valide (ce qui signifie que le client a bien été authentifié par le KDC) ainsi que l’indicateur d’authentification, puis renvoie les informations pour accéder au service demandé.

Contenu du TGT :

Le TGT permet à l’utilisateur authentifié de récupérer des tickets d’accès aux services auprès du TGS.

Il contient un identifiant du client, la clé de session pour les échanges entre le TGS et le client ainsi qu’une durée de validité (lutter contre le rejeu).

Le TGT est crypté à l’aide de la clé secrète du TGS.

(11)

1.2.4 Les services « kerbérisés » :

De nombreux services peuvent s’appuyer sur Kerberos pour authentifier les utilisateurs. Les applications doivent toutefois être modifiées.

Certains services sont installés de base en version « kerbérisé » lors de l’installation de Kerberos. Ils comportent le préfixe « k » de façon à les différencier des services standard : kssh, krlogin, ksu,…

Ces services font référence aux fichiers krb5.conf et kdc.conf pour rediriger les authentifications vers le KDC correspondant.

Certaines applications n’existent pas en version « kerbérisée ». Plutôt que de modifier leur code source, on peut insérer une couche supplémentaire entre l’application et le service Kerberos qui se charge de convertir l’authentification Kerberos en un format valide pour l’application.

SASL (défini dans le RFC 2222) permet d’ajouter des mécanismes d’authentification à des protocoles orientés connexion (~ plug-in). SASL est implanté dans LDAPv3.

Parmi les mécanismes supportés par SASL, citons Kerberos IV, S/Key, Digest-MD5 ou GSSAPI.

On peut ainsi utiliser les librairies SASL (librairie Cyrus-SASL) pour réaliser ce type d’authentification. SASL (Simple Authentication and Security Layer) permet l’authentification de type Kerberos 5 grâce au mode GSSAPI.

Authentification de type Kerberos pour l’accès à un annuaire LDAP, basé sur SASL.

Source : CNRS

(12)

1.3 Fonctionnement d’une authentification Kerberos

Le schéma ci-dessous détaille toute la procédure d’authentification d’un utilisateur pour l’accès à un service à l’aide de Kerberos.

Etape 1 :

¾ L’utilisateur C contacte le KDC afin de demander un accès vers le TGS.

C s’identifie suivant un « principal » enregistré dans la base du KDC.

Etape 2 :

¾ Le KDC vérifie si le « principal » existe bien dans la base de Kerberos et si oui répond à la demande de C.

¾ Il envoie alors une clé de session (Kc,tgs) permettant le dialogue entre C et le TGS, cette clé est cryptée à l’aide de la clé secrète (Kc) de C.

(13)

Kc est un hash du mot de passe de C, à aucun moment elle ne circule sur le réseau. Lorsque C reçoit la réponse du TGS, une invite de commande lui demande de saisir son mot de passe de façon à décrypter la clé de session Kc,tgs.

¾ De plus, le KDC renvoie un ticket TGT constitué de l’identifiant de C, d’une clé de session (Kc,tgs) pour les dialogues entre C et le TGS, ainsi que d’une durée de validité du ticket, le tout crypté à l’aide de la clé secrète (Ktgs) du TGS.

Etape 3 :

¾ L’utilisateur C contacte alors le TGS afin d’obtenir un accès au service S. En réalité cet échange est transparent pour l’utilisateur qui se contente de contacter le service auquel il souhaite accéder, par exemple : ftp myftp.mondomaine.fr. C’est l’application « kerbériséeé » (ici le FTP) qui se charge de contacter le TGS pour authentifier l’utilisateur.

¾ C envoi l’identifiant S du service auquel il souhaite accéder. Il envoi aussi Le TGT qu’il a obtenu du KDC lors de l’étape 2, ainsi qu’un identifiant Ac crypté à l’aide de la clé de session Kc,tgs.

Etape 4 :

¾ Le TGS répond à C de façon cryptée à l’aide de la clé de session Kc,tgs.

¾ Le TGS envoie à C un ticket d’accès (Tc,s) au service S crypté avec la clé secrète (Ks) de S. Il envoi aussi une clé de session (Kc,s) permettant de chiffrer les futurs échanges entre C et S.

Etape 5 :

¾ Le client C envoie le ticket d’accès (Tc,s) au service à S, qu’il a reçu du TGS. Ce ticket est crypté à l’aide de la clé secrète de S qui est alors le seul à pouvoir déchiffrer le ticket.

¾ Il envoie également un identifiant (Ac) de C, qui permet au service S d’authentifier le client C et de tester la validité du ticket Tc,s par comparaison.

Il est important de noter qu’aucune information compromettante n’a transité en clair sur le réseau lors de ces échanges. Si un pirate écoutait les communications, les informations qu’il récupèrerait seraient très difficilement exploitables.

(14)

2 LDAP

2.1 Introduction à LDAP

Dans l'industrie informatique, on entend de plus en plus parler de LDAP. Mais en quoi consiste cette norme, et comment la mettre en application ? Nous allons nous y intéresser, avec pour objectif de se familiariser avec les concepts sous-jacents à LDAP et son environnement plutôt que de rentrer dans les détails.

Pour commencer, la mise en oeuvre de LDAP à l'échelle d'une entreprise permet à n'importe quelle application, exécutée à partir de presque n'importe quelle machine, d'obtenir des informations provenant de l'annuaire LDAP. Et ce répertoire peut être utilisé pour stocker un large éventail de données : adresses électroniques et informations de routage du courrier, clés de sécurité publiques, données relatives aux RH, listes de contacts, et bien plus...

Mais il est aussi possible d'utiliser une base de données Oracle, Microsoft SQL,...

afin de stocker la plupart de ces mêmes données. En quoi LDAP est-il différent ? C'est ce que nous allons voir.

(15)

2.2 Qu'est-ce que LDAP ?

LDAP (Lightweight Directory Access Protocol) est basé sur la norme X.500, mais est sensiblement plus simple, et peut-être adapté plus aisément aux besoins des utilisateurs. Contrairement à X.500, LDAP supporte TCP/IP, ce qui est nécessaire pour l'accès à Internet. Les spécifications LDAP principales sont toutes définies dans des RFCs (dont une liste complète est donnée en annexe).

Source : F5 Network, http://www.f5.com/solutions/archives/whitepapers/ldap.html

2.2.1 Un annuaire LDAP est-il une base de données ?

Tout comme un Système de Gestion de Base de Données (SGBD) de Microsoft, Oracle, ou autre, est employé pour traiter les requêtes et mises à jours sur une base de données relationnelle, un serveur LDAP est employé pour traiter les requêtes et mises à jours sur un annuaire LDAP. En d'autres termes, un annuaire LDAP est un type de base de données, mais il ne s'agit pas d'une base de données relationnelle.

Et contrairement aux bases de données qui sont conçues pour traiter des centaines ou des milliers de modifications par minute, les annuaires LDAP sont fortement optimisés pour la lecture.

(16)

2.2.2 Les avantages des annuaires LDAP

Alors, quels sont les avantages des annuaires LDAP ? La popularité actuelle de LDAP est due à un certain nombre de facteurs que nous pouvons résumer ici.

Le meilleur argument en faveur de LDAP est sans doute le fait qu'une entreprise peut accéder à l'annuaire LDAP d'à peu près n'importe quelle plate-forme, et ceci à partir d'un nombre croissant d'applications qui lui sont compatibles. Il est également facile d'adapter les applications internes de l'entreprise de manières à ce qu'elles intègrent LDAP.

Le protocole LDAP étant à la fois « cross plate-forme » et normalisé, les applications n'ont pas à s'inquiéter du type de serveur accueillant l'annuaire. En fait, LDAP est beaucoup plus largement accepté dans l'industrie en raison de son statut de standard Internet. Les fournisseurs sont plus disposés à procéder à l'intégration de LDAP dans leurs produits du fait qu'ils n'ont pas se soucier de savoir ce qui est à l'autre extrémité. En revanche, les fournisseurs désirant intégrer directement un SGBD doivent habituellement concevoir leur produit de manière à ce qu'il fonctionne individuellement avec les solutions des différents fournisseurs de serveurs de base de données.

À la différence de beaucoup de bases de données relationnelles, il n'est pas nécessaire de payer le client logiciel de connexion ou une licence.

La plupart des serveurs LDAP sont simples à installer, faciles à maintenir et à optimiser.

Les serveurs LDAP peuvent dupliquer tout ou partie de leurs données via des méthodes « push » ou « pull », permettant de faire parvenir ces données à des bureaux distants, d'accroître la sécurité, etc... La technologie de duplication est intégrée et facile à configurer. A l'opposé, plusieurs des grands fournisseurs de SGBD facturent ce dispositif, et il est bien plus difficile à gérer convenablement.

LDAP permet d'affecter efficacement des droits de lecture et de modification suivant des besoins spécifiques, en utilisant des ACLs (Access Control Lists). Les ACLs peuvent contrôler l'accès selon l'identité du demandeur des données, quelles données sont demandées, où les données sont stockées, et d'autres aspects de l'enregistrement étant modifié. Tout ceci est fait par l'annuaire LDAP directement, ainsi il n'est pas nécessaire de s'inquiéter de mettre en oeuvre un contrôle d'accès au niveau d'applicatif.

2.2.3 Dans quel cas utiliser LDAP pour stocker des données ?

La plupart des serveurs LDAP sont fortement optimisés pour des opérations de lecture. A cause de ceci, la plupart des annuaires LDAP ne sont pas bien adaptés au stockage de données fréquemment modifiées. Par exemple, un serveur d'annuaire LDAP convient tout à fait pour stocker l'annuaire de téléphone interne d'une entreprise, mais il ne faut pas songer à l'employer pour la base de données principale d'un site d'e-commerce à fort débit.

(17)

2.3 Structure d'un arbre d'annuaire LDAP

Les serveurs d'annuaire LDAP stockent leurs données hiérarchiquement. La structure d'un annuaire est relativement similaire à ce que l'on peut trouver pour les arbres DNS ou les dossiers du système de fichier UNIX. Comme pour les noms d'hôte DNS, dans un annuaire LDAP, le champ Distinguished Name (DN) d'un enregistrement est lu du bas vers le haut, de l'entrée individuelle (feuille) vers la racine de l'arbre.

Le niveau supérieur d’un arbre d’annuaire LDAP est la base, généralement appelée

« base DN ». Il existe 3 notations pour cette base. Si on considère l’annuaire d’une entreprise française Yggdrasil localisée sur Internet à l’adresse yggdrasil.com, alors on aura :

o="Yggdrasil", c=FR (base DN au format X.500)

Ici, o=”Yggdrasil” fait référence à l’organisation, le second champ notifiant le pays d’origine. Ce format de notation étant source de confusion, il a évolué vers ceux présentés ci-dessous.

o=yggdrasil.com

(base DN dérivé de la localisation Internet de l’entreprise)

Ici, la base utilisée correspond au nom de domaine Internet de l’entreprise.

dc=yggdrasil, dc=com

(base DN dérivé des composants du domaine DNS de l’entreprise)

Comme précédemment, le nom de domaine DNS est utilisé, mais il est décomposé en dc (domain components).

Sous la racine de l’annuaire, on créera des répertoires qui séparent logiquement les données. Pour des raisons historiques (X.500), la plupart des annuaires LDAP désignent ces séparations logiques par les initiales OU, pour « Organizational Unit ».

Dans X.500, OU était utilisé pour représenter l’organisation fonctionnelle à l’intérieur d’une entreprise : ventes, finance, etc… Les implémentations actuelles de LDAP ont gardé la convention d’appellation ‘ou=’, mais divisent les choses en larges catégories telles que ou=people, ou=groups, ou=serveurs, etc…

Par exemple, l’arbre d’un annuaire LDAP (entrées individuelles exclues) pourrait ressembler à ceci :

dc=int-evry, dc=fr ou=people

ou=eleves ou=enseigants ou=administratifs ou=servers

ou=groups ou=machines

(18)

dc = com dc = org dc = fr

dc = int-evry, dc = fr

ou = people

uid = jdupond

ou = servers ou = groups

Toutes les entrées stockées dans un annuaire LDAP ont un "Distinguished Name", ou DN, unique. Ce DN se compose de deux parties : le DN relatif (RDN), et l’endroit dans l’annuaire où se trouve l’enregistrement.

Le RDN a généralement pour base l’attribut cn (Common Name), ou l’attribut uid (User ID).

Des exemples de DN complets seraient :

cn=jotun, ou=machines, dc=yggdrasil, dc=com uid=gdupont, ou=people, dc=int-evry, dc=fr

(19)

3 Authentification Kerberos/SASL pour accès LDAP :

3.1 Principe général

Dans cette partie nous allons décrire la mise en œuvre de l’authentification de type Kerberos, basée sur SASL, pour l’accès à un annuaire LDAP. Le but étant de d’offrir un accès à l’annuaire LDAP pour les utilisateurs disposant d’un ticket Kerberos valide.

Configuration de la maquette :

Pour mettre en œuvre cette architecture nous avons disposé de deux postes de travail reliés au réseau de l’INT. Nous avons utilisé le réseau de l’INT de façon à bénéficier du serveur DNS de l’INT pour la résolution des noms de machines.

Ces deux postes fonctionnent sous une distribution Linux RedHat 9.

DNS INT

- Kerberos Kadmin - Kerberos KDC - Cyrus SASL - OpenSSL

- Client FTP « kerbérisé » - Client Telnet « kerbérisé » - Client OpenLDAP

- Kerberos Workstation - Cyrus SASL

- OpenSSL

- Serveur FTP « kerbérisé » - Serveur Telnet « kerbérisé » - Serveur openLDAP

mci-0475e84aa8.int-evry.fr

mci-0475e2d1ae.int-evry.fr

Le premier poste nous a servi de serveur Kerberos (KDC et TGS) et de client pour accéder aux services « kerbérisés » de l’autre serveur.

Sur le second poste nous avons installé les différents services « kerbérisés » (Telnet, FTP), ainsi que la base OpenLDAP dont l’authentification Kerberos sera effectuée par SASL.

(20)

3.2 Installation

Dans cette partie nous allons décrire l’installation et la configuration des différents logiciels.

Pour faciliter l’installation de certains composants nous avons installé l’utilitaire apt- get sous RedHat (http://apt.freshrpms.net/).

3.2.1 Installation de OpenSSL et création de certificats

Afin de sécuriser les échanges avec l’annuaire LDAP, nous pouvons utiliser SSL et TLS. De plus, Kerberos et SASL utilisent des fonctions cryptographiques faisant appel à des librairies de OpenSSL.

La première étape consiste donc à installer les librairies OpenSSL. L’installation est automatique à l’aide de la commande : apt-get install openssl

Nous commençons par générer un certificat pour notre serveur hébergeant les services. Ce certificat va être auto-signé, il faut pour cela générer un certificat d’Autorité de Certification (CA). Cette opération est réalisée à l’aide de OpenSSL et nous créons ainsi un certificat de CA : demoCA/cacert.pem

Puis, nous générons un certificat pour notre serveur que nous signons avec le certificat du CA que nous venons de créer.

Nous obtenons ainsi un certificat : server.crt.pem et une clé privée pour notre serveur : server.key.pem

Ces trois certificats ainsi crées sont placé dans le répertoire : /etc/openldap/certs/

et servirons ensuite pour la configuration de SSL/TLS avec OpenLDAP.

(Le détail de la création de ces certificats est donné dans l’annexe A)

(21)

3.2.2 Installation Kerberos V

3.2.2.1 Installation des composants :

La dernière version de Kerberos est la version 5, elle peut être récupérée à partir du site du MIT (http://web.mit.edu/kerberos/www/) ou bien à l’aide de apt-get sous RedHat.

Avec la commande « apt-cache search kerberos » on affiche la liste de tous les éléments Kerberos installables :

- krb5-devel

- krb5-lib

- krb5-serveur

- krb5-workstation

On installe ces divers éléments sur le serveur Kerberos à l’aide de la commande

« apt-get install <element> ».

Sur les postes utilisant Kerberos pour authentifier des utilisateurs ou hébergeant des services « kerbérisés », il faut également installer les éléments krb5-lib et krb5- workstation.

3.2.2.2 Configuration du fichier krb5.conf :

Le fichier /etc/krb5.conf est le fichier de paramétrage du serveur Kerberos, il permet de configurer le « royaume » Kerberos, les algorithmes de chiffrement utilisés ou encore l’adresse du KDC.

(Le fichier krb5.conf est donné en annexe de ce rapport).

¾ Dans la partie [ logging ], on renseigne le chemin vers les fichiers de log.

¾ Dans la partie [ libdefaults ], on paramètre les tickets Kerberos.

Il faut s’assurer que la ligne suivante est bien présente et que le fichier krb5.keytab existe (sinon il faut le créer). Ce fichier permet au serveur de stocker les services et hôtes auquel il peut accéder (stockage de la clé secrète du service). Ce fichier doit également être présent sur tous les serveurs hébergeant des services « kerbérisés ».

default_keytab_name = /etc/krb5.keytab

¾ Dans la partie [ realms ], on configure notre « royaume » Kerberos, en indiquant l’adresse du KDC , l’adresse du serveur d’administration (kadmin) et le nom de domaine par défaut :

[realms]

INT-EVRY.FR = {

kdc = mci-0475e84aa8.int-evry.fr:8800

admin_server = mci-0475e84aa8.int-evry.fr:7490 default_domain = int-evry.fr

(22)

¾ [ domain_realm ] permet de configurer notre « royaume » Kerberos et de faire le lien avec notre nom de domaine.

[domain_realm]

.int-evry.fr = INT-EVRY.FR int-evry.fr = INT-EVRY.FR localhost = INT-EVRY.FR

¾ Enfin, [ kdc ] permet de configurer le chemin vers le fichier de configuration du KDC (kdc.conf).

3.2.2.3 Configuration du fichier kdc.conf :

Le fichier /var/kerberos/krb5kdc/kdc.conf permet de paramétrer le KDC (serveur de distribution des clés). Il permet, par exemple, de régler la durée de vie des tickets Kerberos ou les ports d’écoute du KDC pour notre « royaume » INT-EVRY.FR.

[kdcdefaults]

kdc_ports = 8800,7500

[realms]

INT-EVRY.FR = {

profile = /etc/krb5.conf

database_name = /var/kerberos/krb5kdc/principal admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab acl_file = /var/kerberos/krb5kdc/kadm5.acl

kadmind_port = 7490

kdc_ports = 8800

max_life = 8h 0m 0s

max_renewable_life = 7d 0h 0m 0s default_principal_flags = +preauth }

Il faut s’assurer que les chemins vers les différents fichiers indiqués sont corrects. En fonction de la version du système d’exploitation ou des options d’installation, ces chemins peuvent être modifiés.

3.2.2.4 Création de la base Kerberos pour notre « royaume » :

Nous allons maintenant créer notre base de donnée Kerberos à l’aide de la commande :

[root@mci-0475e84aa8 root]# kdb5_util create -s

Le système demande alors un mot de passe pour l’administrateur de la base.

On lance ensuite les différents services Kerberos :

[root@mci-0475e84aa8 root]# /sbin/service krb5kdc start [root@mci-0475e84aa8 root]# /sbin/service Kadmin start

(23)

3.2.2.5 Configuration du fichier kadm5.acl :

Une fois la base Kerberos créée, il faut donner des droits d’accès à certains utilisateurs privilégiés comme les administrateurs.

Le ficher /var/kerberos/krb5kdc/kadm5.acl définit les droits d’accès des utilisateurs à la base Kerberos.

Nous allons ainsi donner tous les droits sur la base aux « principals » :

<nom>/admin@INT-EVRY.FR

Dans le fichier kadm5.acl, on place la ligne :

*/admin@INT-EVRY.FR *

3.2.2.6 Création des utilisateurs et des administrateurs Kerberos

Nous allons créer des utilisateurs et des administrateurs pour la base Kerberos. Les utilisateurs peuvent utiliser les services « kerbérisés » alors que les administrateurs peuvent modifier cette base (créer, supprimer ou modifier des « principals »).

Nous avons choisi de définir les administrateurs selon le schéma :

<nom>/admin@REALM.KRB (en accord avec les ACL définies dans la partie précédente). Ainsi, l’administrateur root sera nommé : root/admin@INT-EVRY.FR De même, l’élève Dupond (simple utilisateur) pourrait être nommé : dupond/eleve@INT-EVRY.FR

Il faut entrer ces « principals » dans la base Kerberos à l’aide de l’utilitaire kadmin.

Etant donné que aucun administrateur n’a encore été défini, la seule façon d’accéder à kadmin et de le lancer en local sur le serveur Kerberos avec la commande : kadmin.local

shell% kadmin.local

On peut ensuite ajouter un “principal” sous kadmin à l’aide de la commande

« addprinc <principal> » :

kadmin.local: addprinc root/admin@INT-EVRY.fr

NOTICE: no policy specified for "root/admin@INT-EVRY.FR";

assigning "default".

Le serveur Kerberos demande alors de saisir un mot de passe pour cet utilisateur (un hash de ce mot de passe va générer la clé sécrète associée à ce principal) :

Enter password for principal root/admin@INT-EVRY.FR:

Re-enter password for principal root/admin@INT-EVRY.FR:

Un message informe que le principal a bien été créé et on peut alors quitter kadmin avec la commande “quit” :

Principal "root/admin@INT-EVRY.FR" created.

kadmin.local: quit

(24)

Maintenant que les administrateurs sont inscrits dans la base Kerberos, on peut accéder à distance au serveur kadmin. Il suffit d’installer les packages Kerberos sur un poste distant et d’y copier nos fichiers de configuration. Depuis ce poste distant, on peut maintenant accéder à kadmin (plus besoin de la commande kadmin.local).

Mais il faut pour cela disposer d’un ticket Kerberos valide.

Pour obtenir un ticket Kerberos, on tape la commande « kinit <principal> », le système demande alors à l’utilisateur d’entrer son mot de passe :

Pour consulter la liste des tickets Kerberos qu’il possède, un utilisateur peut taper la commande « klist » :

A tout moment l’utilisateur peut détruire son ticket à l’aide de la commande

« kdestroy ».

3.2.3 Installation Cyrus SASL

La librairie Cyrus SASL va permettre de coupler l’authentification Kerberos avec l’accès à l’annuaire LDAP.

Pour une authentification de type Kerberos V, c’est le mode GSSAPI (Generic Security Service Application Program Interface) de SASL qui doit être utilisé.

Le package d’installation de la bibliothèque cyrus-sasl peut être téléchargée sur le site : http://asg.web.cmu.edu/sasl/

(25)

Il est important d’installer la dernière version (2.1.18 ou +) qui offre une meilleure compatibilité avec OpenLDAP.

Une fois le package téléchargé et « dépackagé » l’installation se fait de la façon suivante :

# ./configure [options]

La liste des options de configuration peut être affichée à l’aide de la commande : ./configure --help

Dans notre cas, nous avons utilisé les options :

./configure –-prefix=/usr –-disable-krb4 –-enable-gssapi --enable-ano –-with-openssl=/usr/include

On peut ensuite installer la bibliothèque :

# make

# make install

Arrivé à ce point, et avant de passer à l’installation et la configuration de OpenLDAP, il peut être intéressant d’effectuer des tests de la combinaison Kerberos/SASL-GSAPI avec des services simples comme FTP et Telnet.

Ceci doit permettre de s’assurer que tout a était jusqu’ici bien configuré. Le détail de ces tests est donné dans la partie suivante (4.1)

3.2.4 Installation de OpenLDAP

Une fois tous ces composants installés, nous pouvons passer à l’installation du serveur OpenLDAP.

La dernière version de OpenLDAP peut être téléchargée à partir de l’adresse : http://www.openldap.org/

Après avoir décompressé le fichier, l’installation s’effectue avec les commandes :

# ./configure [options]

Dans notre cas, nous avons utilisé les options :

./configure –-prefix=/usr –-with-tls –-enable-slapd –-with- cyrus-sasl –-enable-crypt –-enable-ldbm –-enable-bdb=no

On procède ensuite à l’installation :

# make

# make depend

# make install

(26)

Une fois l’installation effectuée, il faut éditer les fichiers /etc/openldap/slpad.conf et /etc/openldap/ldap.conf pour paramétrer l’annuaire.

3.2.4.1 Configuration du fichier ldap.conf :

Certaines modifications doivent être apportées au fichier ldap.conf :

¾ Configuration du nom d’hôte du serveur hébergeant l’annuaire :

# Your LDAP server. Must be resolvable without using LDAP.

HOST mci-0475e2d1ae.int-evry.fr

¾ Configuration de la base LDAP

# The distinguished name of the search base.

base dc=int-evry,dc=fr

¾ Ports pour accéder à l’annuaire (en mode normal, SSL ou TLS)

# The port.

# Optional: default is 389.

port 389 # normal et TLS

port 636 # SSL

¾ Activer cryptage TLS/SSL (pointer vers les certificats créés pour notre CA)

# OpenLDAP SSL mechanism

# start_tls mechanism uses the normal LDAP port, LDAPS typically 636 ssl start_tls

# OpenLDAP SSL options

# Require and verify server certificate (yes/no)

# Default is "no"

tls_checkpeer yes

# CA certificates for server certificate verification

# At least one of these are required if tls_checkpeer is "yes"

tls_cacertfile /etc/openldap/certs/cacert.pem

#tls_cacertdir /etc/ssl/certs

¾ Désactiver l’authentification du client par TLS/SSL

# Client certificate and key

# Use these, if your server requires client authentication.

#tls_cert

#tls_key ssl no

(Le fichier ldap.conf que nous avons utilisé est donné en annexe C)

(27)

3.2.4.2 Configuration du fichier slapd.conf :

Certaines modifications doivent être apportées au fichier sladp.conf :

¾ Ajouter le schéma Kerberos V pour l’authentification

include /etc/openldap/schema/krb5-kdc.schema

¾ Configurer la référence vers l’annuaire LDAP

# Do not enable referrals until AFTER you have a working

# directory service AND an understanding of referrals.

referral ldap://mci-0475e2d1ae.int-evry.fr

¾ Ajouter les chemins d’accès aux certificats OpenSSL pour l’utilisation du cryptage SSL/TLS :

#

# The next three lines allow use of TLS for connections using a

# dummy test certificate, but you should generate a proper

# certificate by changing to /usr/share/ssl/certs, running

# "make slapd.pem", and fixing permissions on TLSCipherSuite HIGH:MEDIUM:+SSLv2

TLSCertificateFile /etc/openldap/certs/server.crt.pem TLSCertificateKeyFile /etc/openldap/certs/server.key.pem TLSCACertificateFile /etc/openldap/certs/cacert.pem TLSVerifyClient never

¾ Activation de la méthode d’authentification SASL, avec déclaration du

« royaume » (reaml) Kerberos et l’adresse du serveur LDAP :

sasl-realm INT-EVRY.FR

sasl-host mci-0475e2d1ae.int-evry.fr

¾ Définitions des listes d’accès et des droits utilisateur :

# Write access to principals Manager and */admin , default read

# access for everything else access to *

by dn="uid=[^/]+/admin\+(realm=INT-EVRY\.FR)?" write by dn="uid=Manager\+(realm=INT-EVRY\.FR)?" write

by * read

¾ Paramétrage de l’annuaire et de l’administrateur :

database ldbm

suffix "dc=int-evry,dc=fr"

#suffix "o=My Organization Name,c=US"

rootdn "cn=Manager,dc=int-evry,dc=fr"

#rootdn "cn=Manager,o=My Organization Name,c=US"

# Cleartext passwords, especially for the rootdn, should

# be avoided. See slappasswd(8) and slapd.conf(5) for details.

# Use of strong authentication encouraged.

# rootpw manager

# rootpw {crypt}ijFYNcSNctBYg

(28)

3.2.4.3 Lancement du serveur LDAP :

LDAP est un service tournant sur le poste, par conséquent il peut être démarré à l’aide de la commande :

[root@mci-0475e2d1ae root]# /sbin/service ldap start

Mais il peut également être lancé avec la commande :

[root@mci-0475e2d1ae root]# slapd start

On peut également spécifier le port d’écoute (389 en normal ou avec TLS, 636 avec SSL) à l’aide de l’option « -h » :

Normal/TLS: [root@mci-0475e2d1ae root]# slapd –h ldap:///

SSL: [root@mci-0475e2d1ae root]# slapd –h ldaps:///

Une méthode efficace pour vérifier si le service est bien en écoute sur le port souhaité est d’utiliser la commande nmap :

[root@mci-0475e2d1ae root]# nmap localhost

3.2.4.4 Création d’un principal LDAP dans la base Kerberos

De façon à permettre l’authentification des utilisateurs de l’annuaire LDAP à travers Kerberos, il faut créer un principal correspond au service LDAP dans la base Kerberos avec l’utilitaire kadmin :

kadmin : addprinc -randkey ldap/mci-0475e2d1ae.int-evry.fr

(29)

La clé privée du service est générée de façon aléatoire et stockée dans le fichier cache krb5.keytab sur le serveur LDAP ainsi que sur le serveur Kerberos :

kadmin : ktadd –k /etc/krb5.keytab ldap/mci-0475e2d1ae.int-evry.fr

De plus sur on doit ajouter dans le fichier krb5.keytab du serveur LDAP les

« principals » des hôtes autorisés à se connecter à l’annuaire :

kadmin : ktadd –k /etc/krb5.keytab host/ mci-0475e84aa8.int-evry.fr

3.2.4.5 Initialisation de la base LDAP :

On initialise la base LDAP à l’aide d’un fichier init.ldif :

# Racine de la base dn: dc=int-evry,dc=fr objectclass: top objectclass: dcObject objectclass: organization o: Guessant

dc: guessant

# Définition de l’administrateur dn: cn=Manager,dc=int-evry,dc=fr objectclass: organizationalRole cn: Manager

# Ajout d’un utilisateur

dn: uid=jdupond,ou=people,dc=int-evry,dc=fr objectClass: inetOrgPerson

cn: Jean Dupond givenName: Jean sn: Dupond

mail: JDupond@int-evry.fr

telephoneNumber: +33 6 01 01 98 title: DSI

uid: jdupond

userPassword: 1r2ewu65ZEm9ePs56

Le fichier init.ldif est importé dans la base à l’aide de la commande :

ldapadd -H ldap://mci-0475e2d1ae.int-evry.fr/ -I -f init.ldif

Cette commande d’ajout ne fonctionnera que si l’utilisateur s’est authentifié auprès de Kerberos (et dispose donc d’un ticket TGT valide).

De plus, l’utilisateur doit disposer de droits suffisants au niveau des listes d’accès (voir partie suivante sur les listes d’accès LDAP). D’après notre fichier slpad.conf nous autorisons l’accès en écriture à la base pour les « principals » : Manager@INT- EVRY.FR et < * >/admin@INT-EVRY.FR.

Explicitons les arguments de cette commande ldapadd :

o -H ldap://mci-0475e2d1ae.int-evry.fr/ : spécifie l’annuaire LDAP vers lequel la requête doit être envoyée. L’option –ZZ pourrait être ajoutée afin de crypter la requête avec TLS. De même, si l’on avait spécifié l’adresse ldaps://mci-0475e2d1ae.int-evry.fr/ nous aurions

(30)

utilisé le cryptage SSL (à noter qu’il ne faut pas spécifier l’option –ZZ dans ce cas).

o –I : Active l’authentification par SASL

o -f init.ldif : spécifie que c’est le contenu du fichier init.ldif qui doit être ajouté la base LDAP.

3.2.4.6 A propos des listes d’accès de la base LDAP :

Les listes d’accès à la base LDAP sont définies dans le fichier slapd.conf. Nous aurions également pu définir ces règles dans un fichier myldap.access et ajouter un lien vers ce fichier dans splad.conf avec la commande : include /../…/myldap.access Par défaut (c'est-à-dire s’il l’on modifie par les listes d’accès) tous les utilisateurs, authentifiés ou non, ont accès en lecture sur la base et seul l’administrateur a un accès en écriture.

Les listes d’accès sont définies selon le modèle : Quoi ?

Qui ? Quel accès ? Qui ? Quel accès ?

…

Selon la syntaxe :

Access to <partie de l’annuaire>

by <utilisateur> <read/write/auth/none/…>

by <utilisateur> <read/write/auth/none/…>

…

L’utilisateur correspond à la personne qui se connecte à la base, si aucune authentification n’est demandée à l’utilisateur ce dernier est considéré comme anonymous.

Lorsque nous utilisons Kerberos/SASL pour l’authentification, les utilisateurs disposant de tickets TGT valides sont authentifiés et autorisés à accéder à la base.

Mais ces derniers n’étant pas connus par l’annuaire (sous le format : principal@REAML.KRB), ils sont considérés comme anonymes au niveau de LDAP et ne disposent que de droits en lecture.

Il faut donc, au niveau des listes d’accès effectuer un mappage entre le principal Kerberos et les utilisateurs LDAP :

access to *

by *

Dans la commande précédente « uid=Manager\+(realm=INT-EVRY\.FR)? » réalise ce mappage entre le « principal » Kerberos : Manager, et un utilisateur authentifié dans LDAP.

De même, "uid=[^/]+/admin\+(realm=INT-EVRY\.FR)?" représente tous les

« principals » définis comme <nom>/admin@INT-EVRY.FR.

(31)

4 Tests

4.1 Test de services « kerbérisés » avec Kerberos V et SASL :

¾ FTP « kerbérisé » :

Le service FTP est d’ordinaire peu sécurisé puisque l’identifiant et le mot de passe de l’utilisateur circulent en clair sur le réseau (cf. capture d’une trame FTP ci- dessous).

Trame FTP capturée avec Linkview entre le client et le serveur FTP, on voit que le l’identifiant et le mot de passe de l’utilisateur circulent en clair sur le réseau.

Cette authentification peut être sécurisée par l’utilisation du couple Kerberos/SASL.

Kerberos se charge de l’authentification et SASL (à travers le mode GSSAPI) fait correspondre cette authentification au niveau du serveur FTP.

Le package Kerberos-workstation doit être installé sur le serveur et sur le client FTP ainsi que les fichiers de configurations Kerberos (krb5.conf et kdc.conf) avec les mêmes paramètres que sur le serveur Kerberos.

De même, Cyrus-SASL doit être installé sur les deux postes, avec la prise en charge de GSSAPI comme mécanisme d’authentification.

Il faut ensuite créer dans la base Kerberos un « principal » correspondant au serveur FTP : ftp/mci-0475e2d1ae.int-evry.fr@INT-EVRY.FR (avec mci-0475e2d1ae.int- evry.fr le nom du poste hébergeant le serveur FTP, tel qu’il est déclaré dans le DNS).

Il s’agit d’un service et non d’un utilisateur, par conséquence le mot de passe Kerberos ne pourra être saisi. Le mot de passe doit donc être généré de façon aléatoire et enregistré dans le fichier cache krb5.keytab sur le serveur FTP.

Sur le serveur FTP, l’administrateur doit donc exécuter les commandes suivantes sous kadmin :

[root@mci-0475e2d1ae root]# kadmin

kadmin : ank -randkey ftp/mci-0475e2d1ae.int-evry.fr

kadmin : ktadd –k /etc/krb5.keytab ftp/mci-0475e2d1ae.int-evry.fr

(32)

De la même façon, on doit ajouter dans la base Kerberos des « principals » correspondant aux postes devant accéder au serveur FTP. Ces postes sont déclarés de la façon suivante : host/<hostname>@REAML.KRB

De plus ces postes doivent être inclus dans le cache krb5.keytab du serveur FTP.

[root@mci-0475e2d1ae root]# kadmin

kadmin : ank -randkey host/mci-0475e84aa8.int-evry.fr

kadmin : ktadd –k /etc/krb5.keytab host/mci-0475e84aa8.int-evry.fr

Il reste ensuite à créer un ticket Kerberos sur l’hôte hébergeant le serveur FTP avec la commande kinit.

Les utilisateurs authentifiés par Kerberos accéderont au serveur FTP en tant que root, certains systèmes (comme RedHat) interdisent, par défaut, l’accès au FTP en tant que root. Nous avons donc du modifier le fichier /etc/ftpuser pour supprimer cette interdiction.

L’utilisateur qui souhaite accéder au serveur FTP doit avant tout obtenir un ticket TGT auprès de Kerberos à l’aide de commande kinit :

Il peut ensuite accéder au serveur FTP et être authentifié avec le mécanisme GSSAPI de SASL :

(33)

Une fois que l’utilisateur a accédé au moins une fois au serveur FTP, en tapant la commande klist, on peut voir qu’un ticket correspondant au service FTP a était généré :

En capturant des Kerberos/SASL, on trames FTP avec l’authentification s’assure que la confidentialité des échanges est bien assurée :

¾ Telnet « kerbérisé » :

Pour la configuration de Telnet « kerbérisé » la configuration est à peu près identique, le service Telnet doit être déclaré au niveau du serveur Kerberos comme :

host/mci-0475e2d1ae.int-evry.fr

De plus, sur le poste client la commande Telnet doit être lancée avec l’option « -a » :

telnet –a mci-0475e2d1ae.int-evry.fr

(34)

Capture avec Linkview d’une trame Telnet « kerbérisée ».

4.2 Test de OpenLDAP

Dans cette dernière phase du projet, nous avons réalisé un ensemble de tests pour s’assurer du bon fonctionnement de l’annuaire LDAP avec la méthode d’authentification Kerberos/SASL.

4.2.1 Affichage des mécanismes d’authentification supportés :

Dans ce premier test, nous avons fait afficher par l’annuaire les différents mécanismes d’authentification qu’il supporte. C’est en fait une simple requête de recherche que nous avons testée sous différents modes :

- Connexion anonyme à l’annuaire (ldapsearch avec option –x) - Connexion anonyme avec cryptage SSL/TLS des échanges.

- Connexion Kerberos/SASL-GSSAPI (option –I)

Le détail de ce test est donné en annexe de ce rapport.

On remarque qu’avec l’authentification Kerberos/SASL, le fait que l’utilisateur dispose d’un ticket Kerberos valide suffit à l’authentifier auprès de l’annuaire LDAP.

Le concept de SSO semble bien fonctionner.

Les modes SSL/TLS sont implémentables avec OpenLDAP et permettent de chiffrer les échanges. Ils ne permettent toutefois pas de simplifier le mécanisme d’authentification de l’utilisateur qui doit toujours s’identifier auprès de LDAP.

(35)

4.2.2 Tests de recherches dans l’annuaire

Nous avons ensuite effectué une recherche sur le contenu de la base LDAP. La requête consiste à afficher tous les utilisateurs enregistrés dans l’annuaire. Nous avons employé la méthode d’authentification Kerberos/SASL-GSSAPI avec un cryptage des échanges basé sur SSL (ldaps://).

Avant de lancer la recherche nous obtenu un ticket TGT valide auprès du serveur Kerberos.

La requête donne le résultat suivant :

[root@mci-0475e2d1ae cyrus-sasl-2.1.18]# ldapsearch -H ldaps://mci- 0475e2d1ae.int-evry.fr/ "uid=*"

SASL/GSSAPI authentication started SASL SSF: 56

SASL installing layers version: 2

#

# filter: uid=*

# requesting: ALL

#

# jdupond, people, int-evry, fr

uid: jdupond

userPassword:: 1r2ewu65ZEm9ePs56

# search result search: 5

result: 0 Success

# numResponses: 2

# numEntries: 1

L’authentification SASL a bien fonctionné et l’annuaire nous à renvoyé la liste des utilisateurs qu’elle contient (un seul utilisateur : jdupond).

Les premières lignes décrivent le mécanisme d’authentification SASL :

SASL installing layers version: 2

« SASL SSF: 56 » désigne le fait que le cryptage utilisé lors de l’authentification SASL est effectué à l’aide d’une clé de 56 bits. Ce qui est parfaitement logique puisque Kerberos utilise le DES comme algorithme de chiffrement avec des clés de 56 bits.

(36)

4.2.3 Tests de modifications de la base

Jusqu’ici les tests que nous avons effectués ont consisté à effectuer des requêtes ldapsearch (recherches) sur l’annuaire LDAP. Or, ces requêtes ne nécessitent que des droits d’accès en lecture sur la base LDAP.

D’après le fichier slapd.conf (voir installation OpenLDAP) de notre annuaire nous autorisons l’accès en lecture à tous les utilisateurs (authentifiés ou non). Ainsi, par défaut, le fait d’être authentifié par la méthode SASL ne délivre qu’un accès anonyme à la base (en lecture seule).

C’est pourquoi dans notre fichier slpad.conf nous avons rajouté les lignes :

access to *

by * read

Ainsi les lignes 2 et 3 confèrent des accès en écriture sur toute la base aux utilisateurs authentifiés par Kerberos (« principals ») : < * >/admin@INT-EVRY.FR et Manager@INT-EVRY.FR

Ainsi avec l’authentification SASL, si nous disposons d’un ticket TGT valide au nom de Manager@INT-EVRY.FR nous devrions pouvoir avoir des droits d’accès en écriture sur la base.

Dans cette dernière série de test nous allons essayer d’illustrer toutes ces propriètés.

¾ Modification de l’entrée LDAP avec authentification SASL :

Pour modifier une entrée de la base LDAP on utilise la commande « ldapmodify ».

Avec l’option « –f <fichier> » cette commande compare le contenu de <fichier> avec l’annuaire et modifie la base en fonction.

Dans notre base initiale nous avions définit un utilisateur jdupond :

uid: jdupond

userPassword:: 1r2ewu65ZEm9ePs56

(37)

Pour réaliser nos tests de modifications nous allons modifier cet enregistrement à l’aide d’un fichier adduser1.ldif (où seul le numéro de téléphone de jdupond varie) :

# ---

# Fichier adduser1.ldif.ldif

# ---

uid: jdupond

userPassword: 1r2ewu65ZEm9ePs56

# ---

Ainsi, la commande « ldapmodify –f adduser1.ldif » devrait modifier le numéro de téléphone de l’utilisateur jdupond dans la base LDAP.

On commence par récupérer un ticket TGT auprès du serveur Kerberos en tant que Manager@INT-EVRY.FR avec la commande :

[root@mci-0475e2d1ae home]# kinit Manager@INT-EVRY.FR

Puis on envoie la requête « ldapmodify »à la base LDAP :

La modification semble avoir été prise en compte par l’annuaire. On peut visualiser le contenu de la base LDAP à l’aide de l’outil ldapbrowser (interface graphique en Java pour base LDAP : http://www.iit.edu/~gawojar/ldap/)

(38)

On voit que la modification de numéro de téléphone a bien été effectuée.

Si on essaye de détruire le ticket le ticket Kerberos, puis d’effectuer la modification à nouveau, la connexion est refusée.

(39)

¾ Modification suivant différents modes d’authentification :

Nous allons maintenant tester de modifier les entrées LDAP en utilisant différents modes d’authentification.

o Authentification SASL-GSSAPI avec cryptage TLS :

L’utilisateur qui souhaite se connecter dispose d’un ticket Kerberos valide (Manager@INT-EVRY.FR), il souhaite modifier le titre de l’utilisateur jdupond (DSI en RSSI) dans l’annuaire.

Il entre ainsi la commande :

[root@mci-0475e2d1ae home]# ldapmodify -H ldap://mci-0475e2d1ae.int- evry.fr/ -ZZ

SASL installing layers

dn: uid=jdupond, ou=people, dc=int-evry, dc=fr changetype: modify

replace: title title: RSSI

modifying entry "uid=jdupond, ou=people, dc=int-evry, dc=fr"

La modification est alors effectuée avec succès. Ce qui est normal puisque le

« principal » Manager@INT-EVRY.FR dispose de droits en écriture sur notre base LDAP.

o Authentification SASL-GSSAPI avec cryptage TLS sans ticket :

Pour ce deuxième test, nous supprimons notre ticket Kerberos puis nous effectuons à nouveau le même test :

[root@mci-0475e2d1ae home]# kdestroy

[root@mci-0475e2d1ae home]# ldapmodify -H ldap://mci-0475e2d1ae.int- evry.fr/ -ZZ

SASL/GSSAPI authentication started

ldap_sasl_interactive_bind_s: Local error

L’accès à la base LDAP nous est alors refusé.

o Authentification simple/anonyme :

Nous allons maintenant tester des connexions anonymes sur l’annuaire LDAP. Pour accèder de façon anonyme à la base on utilise l’option « -x » dans les requêtes LDAP.

(40)

On commence par tester une recherche anonyme sur la base :

[root@mci-0475e2d1ae home]# ldapsearch -H ldap://mci-0475e2d1ae.int- evry.fr/ -ZZ "uid=*" -x

version: 2

#

# filter: uid=*

# requesting: ALL

#

telephoneNumber: +33 6 01 01 99 uid: jdupond

userPassword:: NDVzNDU0ZHNkcXE=

title: RSSI

# search result search: 3

result: 0 Success

# numResponses: 2

# numEntries: 1

La commande s’effectue sans problème puisque, dans la liste d’accès de notre base LDAP, nous avons accordé un accès en lecture à tous les utilisateurs (même les connexions anonymes).

Nous allons maintenant tenter d’effectuer une modification sur la base à partir d’une connexion anonyme :

[root@mci-0475e2d1ae cyrus-sasl-2.1.18]# ldapmodify -H ldap://mci- 0475e2d1ae.int-evry.fr/ -ZZ -x

dn: uid=jdupond, ou=people, dc=int-evry, dc=fr changetype: modify

replace: title title: RSSI2

modifying entry "uid=jdupond, ou=people, dc=int-evry, dc=fr"

ldap_modify: Insufficient access

ldif_record() = 50

La connexion à l’annuaire est possible mais la requête de modification est refusée du fait que nous n’ayons pas de droits en écriture (ldap_modify: Insufficient access) sur la base (cf. connexion anonyme).

(41)

4.2.4 Captures de trames

Pour terminer notre série de test, nous avons réalisé quelques captures de trames portant sur les échanges avec l’annuaire LDAP selon différents modes d’authentification.

¾ Connexion simple à la base (anonyme et pas de cryptage) :

Dans ce cas on voit que les échanges passent en clair ainsi que le mot de passe (ici nul).

¾ Connexion simple avec cryptage SSL :

En appliquant le cryptage avec SSL pour les échanges avec l’annuaire on assure la confidentialité des échanges.

(42)

¾ Authentification Kerberos/SASL-GSSAPI (sans TLS/SSL) :

En utilisant l’authentification SASL, on voit que les informations de connexion ne circulent pas en clair :

(43)

Conclusion

Au cours de ce projet de fin d’étude, nous avons vu la mise en place et l’utilisation du protocole Kerberos pour sécuriser les mécanismes d’authentification.

Au premier abord, Kerberos apparaît comme compliqué à installer et à configurer.

Toutefois on trouve une grande quantité d’informations sur le sujet sur le site du MIT ou sur Internet en général. La vraie difficulté de la mise en oeuvre de Kerberos réside plutôt dans la « Kerbérisation » des applications.

Ce projet nous a permis de nous familiariser avec l’utilisation d’annuaires LDAP. Par défaut, les annuaires LDAP sont peu sécurisés, les informations d’authentification (utilisateur et mot de passe) circulent en clair sur le réseau.

Les échanges avec l’annuaire LDAP peuvent être cryptés à l’aide des protocoles SSL/TLS qui sont pris en charge dans OpenLDAP. Ceci permet de sécuriser les échanges et d’assurer la confidentialité des données. La mise en oeuvre de ces protocoles est assez simple, puisqu’il suffit à partir des bibliothèques OpenSSL de générer un ensemble de certificats et de clés et de configurer OpenLDAP en fonction.

On pourrait alors se poser des questions sur l’intérêt de mettre en œuvre l’authentification Kerberos/SASL sachant que SSL/TLS est bien plus simple à déployer.

En fait, l’authentification Kerberos/SASL offre plus qu’une sécurisation des données et des accès, il permet de mettre en oeuvre le concept de Single-Sign-On (SSO).

L’utilisateur s’authentifie une fois auprès de Kerberos et peut ensuite accéder à l’ensemble des services « kerbérisés » sans avoir à s’authentifier de nouveau.

L’architecture Kerberos/SASL a pourtant quelques inconvénients. Avant tout, les utilisateurs doivent être familiarisés avec la notion de ticket Kerberos les commandes permettant de les manipuler (kinit, klist ou kestroy). Les applications ne sont souvent pas nativement compatibles avec Kerberos, il faut soit les recompiler soit utiliser des couches intermédiaires comme SASL. Ceci peut compliquer la phase de déploiement des applications. De plus, le serveur Kerberos devient le point sensible du réseau, si ce serveur tombe les utilisateurs ne pourront plus accéder à aucun service. Il faut donc s’assurer que ce serveur est bien sécurisé et résiste aux attaques de type déni de service.

Au final notre maquette simulant l’authentification de type Kerberos/SASL pour l’accès à un serveur LDAP semble fonctionner correctement. Nous avons pu gérer la notion de privilèges des utilisateurs grâce aux contrôles d’accès de LDAP couplés aux « principals » Kerberos. Il serait intéressant de mettre en place cette authentification à partir d’une infrastructure LDAP existante et conséquente. De même, nous pourrions étudier ces mécanismes dans un environnement plus hétérogène (postes et serveurs sous Linux, Windows ou Unix).