TELECOM- ANNEE 2003/2004

Transcription

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 Kerberos Présentation Architecture Le Royaume Kerberos (Kerberos Realm) : Les «principals» : Le serveur Kerberos Les services «kerbérisés» : Fonctionnement d une authentification Kerberos LDAP Introduction à LDAP Qu'est-ce que LDAP? Un annuaire LDAP est-il une base de données? Les avantages des annuaires LDAP Dans quel cas utiliser LDAP pour stocker des données? Structure d'un arbre d'annuaire LDAP Authentification Kerberos/SASL pour accès LDAP : Principe général Installation Installation de OpenSSL et création de certificats Installation Kerberos V Installation des composants : Configuration du fichier krb5.conf : Configuration du fichier kdc.conf : Création de la base Kerberos pour notre «royaume» : Configuration du fichier kadm5.acl : Création des utilisateurs et des administrateurs Kerberos Installation Cyrus SASL Installation de OpenLDAP Configuration du fichier ldap.conf : Configuration du fichier slapd.conf : Lancement du serveur LDAP : Création d un principal LDAP dans la base Kerberos Initialisation de la base LDAP : A propos des listes d accès de la base LDAP : Tests Test de services «kerbérisés» avec Kerberos V et SASL : Test de OpenLDAP Affichage des mécanismes d authentification supportés : Tests de recherches dans l annuaire Tests de modifications de la base Captures de trames

3 Conclusion Annexe A : Génération des certificats sous OpenSSL Annexe B : Fichiers configuration Kerberos V Fichier krb5.conf : Fichier kdc.conf : Annexe C : Fichiers configuration LDAP Fichier ldap.conf : Fichier slapd.conf : Annexe D - Tests sur OpenLDAP Références

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. 4

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é». 5

6 1.2 Architecture 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) 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 6

7 o 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 7

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 cidessous) 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. 8

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 K c,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é. 9

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 («A c») crypté avec la clé de session K c,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. 10

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 11

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 (K c,tgs ) permettant le dialogue entre C et le TGS, cette clé est cryptée à l aide de la clé secrète (K c ) de C. 12

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 K c,tgs. De plus, le KDC renvoie un ticket TGT constitué de l identifiant de C, d une clé de session (K c,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 (K tgs ) 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 A c crypté à l aide de la clé de session K c,tgs. Etape 4 : Le TGS répond à C de façon cryptée à l aide de la clé de session K c,tgs. Le TGS envoie à C un ticket d accès (T c,s ) au service S crypté avec la clé secrète (K s ) de S. Il envoi aussi une clé de session (K c,s ) permettant de chiffrer les futurs échanges entre C et S. Etape 5 : Le client C envoie le ticket d accès (T c,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 (A c ) de C, qui permet au service S d authentifier le client C et de tester la validité du ticket T c,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. 13

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. 14

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, 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. 15

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 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. 16

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 17

18 dc = com dc = org dc = fr dc = int-evry, dc = fr ou = people ou = servers ou = groups uid = jdupond 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 18

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 mci-0475e84aa8.int-evry.fr - 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-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. 19

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 aptget sous RedHat ( 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) 20

21 3.2.2 Installation Kerberos V 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 ( 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 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 } 21

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) 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 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 22

23 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 * 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 On créé ainsi les différents utilisateurs et administrateurs de la base Kerberos. 23