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/[email protected] pour un administrateur 6

7 o pour un élève toto o Dupond/[email protected] pour l enseignant Dupond. Les postes de travail peuvent être déclarés comme : o host/[email protected] pour le poste déclaré en tant que PC1 dans le DNS du domaine int-evry.fr o host/[email protected] 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/[email protected] 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/[email protected] 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 : [email protected], 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>/[email protected] Dans le fichier kadm5.acl, on place la ligne : */[email protected] * 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>/[email protected] (en accord avec les ACL définies dans la partie précédente). Ainsi, l administrateur root sera nommé : root/[email protected] De même, l élève Dupond (simple utilisateur) pourrait être nommé : dupond/[email protected] 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/[email protected] NOTICE: no policy specified for "root/[email protected]"; 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/[email protected]: Re-enter password for principal root/[email protected]: Un message informe que le principal a bien été créé et on peut alors quitter kadmin avec la commande quit : Principal "root/[email protected]" created. kadmin.local: quit On créé ainsi les différents utilisateurs et administrateurs de la base Kerberos. 23

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» 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 : 24

25 Il est important d installer la dernière version ( 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) 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 : 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 -withcyrus-sasl -enable-crypt -enable-ldbm -enable-bdb=no On procède ensuite à l installation : # make # make depend # make install 25

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 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 port 636 # normal et TLS # 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) 26

27 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 sasl-host INT-EVRY.FR 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 suffix #suffix rootdn #rootdn ldbm "dc=int-evry,dc=fr" "o=my Organization Name,c=US" "cn=manager,dc=int-evry,dc=fr" "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 27

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

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 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: [email protected] telephonenumber: 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 < * >/[email protected]. 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 29

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 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 : Selon la syntaxe : Quoi? Qui? Quel accès? Qui? Quel accès? 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 : [email protected]), 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 dn="uid=[^/]+/admin\+(realm=int-evry\.fr)?" write by dn="uid=manager\+(realm=int-evry\.fr)?" write 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>/[email protected]. 30

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 cidessous). 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/[email protected] (avec mci-0475e2d1ae.intevry.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 31

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 : 32

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 33

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

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 ]# 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 dn: uid=jdupond,ou=people,dc=int-evry,dc=fr objectclass: inetorgperson cn: Jean Dupond givenname: Jean sn: Dupond mail: [email protected] telephonenumber: title: DSI 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/GSSAPI authentication started SASL SSF: 56 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. 35

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 dn="uid=[^/]+/admin\+(realm=int-evry\.fr)?" write by dn="uid=manager\+(realm=int-evry\.fr)?" write 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») : < * >/[email protected] et [email protected] Ainsi avec l authentification SASL, si nous disposons d un ticket TGT valide au nom de [email protected] 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 : # jdupond, people, int-evry, fr dn: uid=jdupond,ou=people,dc=int-evry,dc=fr objectclass: inetorgperson cn: Jean Dupond givenname: Jean sn: Dupond mail: [email protected] telephonenumber: title: DSI uid: jdupond userpassword:: 1r2ewu65ZEm9ePs56 36

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 # dn: uid=jdupond,ou=people,dc=int-evry,dc=fr objectclass: inetorgperson cn: Jean Dupond givenname: Jean sn: Dupond mail: [email protected] telephonenumber: title: DSI 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 [email protected] avec la commande : [root@mci-0475e2d1ae home]# kinit [email protected] 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 : 37

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

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 ([email protected]), 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.intevry.fr/ -ZZ SASL/GSSAPI authentication started SASL SSF: 56 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» [email protected] 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.intevry.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. 39

40 On commence par tester une recherche anonyme sur la base : [root@mci-0475e2d1ae home]# ldapsearch -H ldap://mci-0475e2d1ae.intevry.fr/ -ZZ "uid=*" -x version: 2 # # filter: uid=* # requesting: ALL # # jdupond, people, int-evry, fr dn: uid=jdupond,ou=people,dc=int-evry,dc=fr objectclass: inetorgperson cn: Jean Dupond givenname: Jean sn: Dupond mail: [email protected] telephonenumber: 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 ]# 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). 40

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

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 : 42

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). 43

44 Annexe A : Génération des certificats sous OpenSSL Génération du certificat du CA : [root@mci-0475e2d1ae mycerts]# /usr/share/ssl/misc/ca -newca CA certificate filename (or enter to create) Making CA certificate... Generating a 1024 bit RSA private key writing new private key to './democa/private/./cakey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank Country Name (2 letter code) [FR]: State or Province Name (full name) [Essonne]: Locality Name (eg, city) [EVRY]: Organization Name (eg, company) [INT]: Organizational Unit Name (eg, section) []:SSR Common Name (eg, your name or your server's hostname) []:monca Address []: Génération du certificat du serveur : Pour le champ Common Name il est indispensable de saisir le hostname du serveur tel qu il est définit dans le DNS. [root@mci-0475e2d1ae mycerts]# openssl req -nodes -out newreq.pem -keyout newreq.pem -days 365 -newkey rsa:1024 Generating a 1024 bit RSA private key writing new private key to 'newreq.pem' You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank Country Name (2 letter code) [FR]: 44

45 State or Province Name (full name) [Essonne]: Locality Name (eg, city) [EVRY]: Organization Name (eg, company) [INT]: Organizational Unit Name (eg, section) []:SSR Common Name (eg, your name or your server's hostname) []:mci- 0475e2d1ae.int-evry.fr Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:intssr An optional company name []:INT Il faut ensuite signer le certificat du serveur avec le certificat de notre CA : [root@mci-0475e2d1ae mycerts]# /usr/share/ssl/misc/ca -sign Using configuration from /usr/share/ssl/openssl.cnf Enter pass phrase for./democa/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 1 (0x1) Validity Not Before: Jun 22 14:52: GMT Not After : Jun 22 14:52: GMT Subject: countryname = FR stateorprovincename = Essonne localityname = EVRY organizationname = INT organizationalunitname = SSR commonname = mci-0475e2d1ae.int-evry.fr X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 31:CD:4C:79:77:0B:B0:57:63:85:57:05:EE:05:8F:24:3E:D2:8A:08 X509v3 Authority Key Identifier: keyid:e3:7f:d2:b5:b5:34:7b:bf:8e:a7:67:3b:88:1a:16:ce:b5:ab:d8:65 DirName:/C=FR/ST=Essonne/L=EVRY/O=INT/OU=SSR/CN=monCA serial:00 Certificate is to be certified until Jun 22 14:52: GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5withrsaencryption Issuer: C=FR, ST=Essonne, L=EVRY, O=INT, OU=SSR, CN=monCA Validity Not Before: Jun 22 14:52: GMT Not After : Jun 22 14:52: GMT 45

46 Subject: C=FR, ST=Essonne, L=EVRY, O=INT, OU=SSR, CN=mci- 0475e2d1ae.int-evry.fr Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c3:dd:9d:c5:54:7f:eb:2c:f8:8f:6c:87:59:dd: 08:73:75:2f:1d:02:7e:ab:b4:ed:7c:88:3d:0b:a9: bc:4a:a8:b1:88:85:ae:95:09:67:bf:7d:a5:31:43: 98:80:38:e1:9f:0c:6e:63:2b:2d:03:64:e8:3a:ac: 52:b1:f1:e7:a0:0c:b9:79:0c:6a:b9:42:d2:23:4f: 68:6d:a1:26:2a:c2:15:4a:5a:04:66:76:22:39:e3: fe:14:68:84:61:06:6e:2c:1c:22:8a:e8:3f:f6:73: 71:4f:34:46:2c:88:e3:22:d5:f5:6a:88:25:78:e6: 75:ab:34:c0:af:21:19:01:05 Exponent: (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 31:CD:4C:79:77:0B:B0:57:63:85:57:05:EE:05:8F:24:3E:D2:8A:08 X509v3 Authority Key Identifier: keyid:e3:7f:d2:b5:b5:34:7b:bf:8e:a7:67:3b:88:1a:16:ce:b5:ab:d8:65 DirName:/C=FR/ST=Essonne/L=EVRY/O=INT/OU=SSR/CN=monCA serial:00 Signature Algorithm: md5withrsaencryption 7f:36:8a:2b:ad:95:d7:83:cf:9c:e9:bd:bb:a7:fc:7e:43:9b: d3:74:f1:02:c9:e4:0c:d1:51:e5:4a:1c:6c:14:db:6b:43:7e: e8:7a:86:fc:91:56:08:1d:b5:0c:50:dc:68:0c:c7:a5:6d:6e: 83:80:c8:c2:1e:e9:c8:d5:37:39:a0:ec:f6:a3:90:67:c9:25: 41:a4:09:e5:50:56:d7:7e:63:76:90:e7:91:90:73:15:41:12: ad:24:96:7f:5f:3f:35:d8:f1:14:06:2d:91:ec:6e:5a:70:cc: 58:dc:c2:31:bc:2d:b6:db:69:dc:ec:ec:0c:d9:3f:59:58:dc: c9: BEGIN CERTIFICATE----- MIIDIDCCAomgAwIBAgIBATANBgkqhkiG9w0BAQQFADBaMQswCQYDVQQGEwJGUjEQ MA4GA1UECBMHRXNzb25uZTENMAsGA1UEBxMERVZSWTEMMAoGA1UEChMDSU5UMQww CgYDVQQLEwNTU1IxDjAMBgNVBAMTBW1vbkNBMB4XDTA0MDYyMjE0NTI0NloXDTA1 MDYyMjE0NTI0NlowbzELMAkGA1UEBhMCRlIxEDAOBgNVBAgTB0Vzc29ubmUxDTAL BgNVBAcTBEVWUlkxDDAKBgNVBAoTA0lOVDEMMAoGA1UECxMDU1NSMSMwIQYDVQQD ExptY2ktMDQ3NWUyZDFhZS5pbnQtZXZyeS5mcjCBnzANBgkqhkiG9w0BAQEFAAOB jqawgykcgyeaw92dxvr/6yz4j2yhwd0ic3uvhqj+q7ttfig9c6m8sqixiiwulqln v32lmuoygdjhnwxuyysta2tooqxssfhnoay5eqxquulsi09obaemksivsloeznyi OeP+FGiEYQZuLBwiiug/9nNxTzRGLIjjItX1aogleOZ1qzTAryEZAQUCAwEAAaOB 4DCB3TAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRl ZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUMc1MeXcLsFdjhVcF7gWPJD7SiggwgYIG A1UdIwR7MHmAFON/0rW1NHu/jqdnO4gaFs61q9hloV6kXDBaMQswCQYDVQQGEwJG UjEQMA4GA1UECBMHRXNzb25uZTENMAsGA1UEBxMERVZSWTEMMAoGA1UEChMDSU5U MQwwCgYDVQQLEwNTU1IxDjAMBgNVBAMTBW1vbkNBggEAMA0GCSqGSIb3DQEBBAUA A4GBAH82iiutldeDz5zpvbun/H5Dm9N08QLJ5AzRUeVKHGwU22tDfuh6hvyRVggd tqxq3ggmx6vtbooaymie6cjvnzmg7pajkgfjjugkcevqvtd+y3aq55gqcxvbeq0k ln9fpzxy8rqglzhsblpwzfjcwjg8lbbbadzs7azzp1ly3mkz -----END CERTIFICATE----- Signed certificate is in newcert.pem 46

47 Déplacement des certificats pour leur utilisation avec OpenLDAP : Il reste à renommer les certificats ainsi générés et les déplacer vers le répertoire /etc/openldap/certs (cette opération doit être effectuée après l installation de OpenLDAP) : # certificat de CA cp democa/cacert.pem /etc/openldap/certs/ # Déplacement du certificat serveur mv newcert.pem /etc/openldap/certs/server.crt.pem # Déplacement de la clé privée du serveur mv newreq.pem /etc/openldap/certs/server.key.pem # L'utilisateur qui lance slapd de openldap doit pouvoir lire le certificat et la clé privée (par défaut ldap) chown ldap:ldap /etc/openldap/certs/server.*.pem # La clé privée ne doit être lisible uniquement par cet utilisateur chmod u=r,go= /etc/openldap/certs/server.key.pem 47

48 Annexe B : Fichiers configuration Kerberos V 1 Fichier krb5.conf : [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] ticket_lifetime = default_realm = INT-EVRY.FR default_keytab_name = /etc/krb5.keytab default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc permitted_enctypes = des3-hmac-sha1 des-cbc-crc dns_lookup_realm = false dns_lookup_kdc = false kdc_req_checksum_type = 2 checksum_type = 2 ccache_type = 1 forwardable = true proxiable = true [realms] INT-EVRY.FR = { kdc = mci-0475e84aa8.int-evry.fr:8800 admin_server = mci-0475e84aa8.int-evry.fr:7490 default_domain = int-evry.fr } [domain_realm].int-evry.fr = INT-EVRY.FR int-evry.fr = INT-EVRY.FR localhost = INT-EVRY.FR [kdc] profile = /var/kerberos/krb5kdc/kdc.conf 48

49 2 Fichier kdc.conf : [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 49

50 Annexe C : Fichiers configuration LDAP 1 Fichier ldap.conf : ldap.conf,v /09/20 14:12:26 lukeh Exp $ # # This is the configuration file for the LDAP nameservice # switch library and the LDAP PAM module. # # PADL Software # # # Your LDAP server. Must be resolvable without using LDAP. HOST mci-0475e2d1ae.int-evry.fr # The distinguished name of the search base. base dc=int-evry,dc=fr # Another way to specify your LDAP server is to provide an # uri with the server name. This allows to use # Unix Domain Sockets to connect to a local LDAP Server. #uri ldap:// / #uri ldaps:// / #uri ldapi://%2fvar%2frun%2fldapi_sock/ # Note: %2f encodes the '/' used as directory separator # The LDAP version to use (defaults to 3 # if supported by client library) #ldap_version 3 # The distinguished name to bind to the server with. # Optional: default is to bind anonymously. #binddn cn=proxyuser,dc=example,dc=com # The credentials to bind with. # Optional: default is no credential. #bindpw secret # The distinguished name to bind to the server with # if the effective user ID is root. Password is # stored in /etc/ldap.secret (mode 600) #rootbinddn cn=manager,dc=example,dc=com # The port. # Optional: default is 389. port 389 port 636 # The search scope. #scope sub #scope one #scope base # Search timelimit #timelimit 30 # Bind timelimit 50

51 #bind_timelimit 30 # Idle timelimit; client will close connections # (nss_ldap only) if the server has not been contacted # for the number of seconds specified below. #idle_timelimit 3600 # Filter to AND with uid=%s #pam_filter objectclass=account # The user ID attribute (defaults to uid) #pam_login_attribute uid # Search the root DSE for the password policy (works # with Netscape Directory Server) #pam_lookup_policy yes # Check the 'host' attribute for access control # Default is no; if set to yes, and user has no # value for the host attribute, and pam_ldap is # configured for account management (authorization) # then the user will not be allowed to login. #pam_check_host_attr yes # Group to enforce membership of #pam_groupdn cn=pam,ou=groups,dc=example,dc=com # Group member attribute #pam_member_attribute uniquemember # Specify a minium or maximum UID number allowed #pam_min_uid 0 #pam_max_uid 0 # Template login attribute, default template user # (can be overriden by value of former attribute # in user's entry) #pam_login_attribute userprincipalname #pam_template_login_attribute uid #pam_template_login nobody # HEADS UP: the pam_crypt, pam_nds_passwd, # and pam_ad_passwd options are no # longer supported. # Do not hash the password at all; presume # the directory server will do it, if # necessary. This is the default. #pam_password clear # Hash password locally; required for University of # Michigan LDAP server, and works with Netscape # Directory Server if you're using the UNIX-Crypt # hash mechanism and not using the NT Synchronization # service. #pam_password crypt # Remove old password first, then update in # cleartext. Necessary for use with Novell # Directory Services (NDS) #pam_password nds # Update Active Directory password, by 51

52 # creating Unicode password and updating # unicodepwd attribute. #pam_password ad # Use the OpenLDAP password change # extended operation to update the password. #pam_password exop # RFC2307bis naming contexts # Syntax: # nss_base_xxx base?scope?filter # where scope is {base,one,sub} # and filter is a filter to be &'d with the # default filter. # You can omit the suffix eg: # nss_base_passwd ou=people, # to append the default base DN but this # may incur a small performance impact. #nss_base_passwd ou=people,dc=example,dc=com?one #nss_base_shadow ou=people,dc=example,dc=com?one #nss_base_group ou=group,dc=example,dc=com?one #nss_base_hosts ou=hosts,dc=example,dc=com?one #nss_base_services ou=services,dc=example,dc=com?one #nss_base_networks ou=networks,dc=example,dc=com?one #nss_base_protocols ou=protocols,dc=example,dc=com?one #nss_base_rpc ou=rpc,dc=example,dc=com?one #nss_base_ethers ou=ethers,dc=example,dc=com?one #nss_base_netmasks ou=networks,dc=example,dc=com?ne #nss_base_bootparams ou=ethers,dc=example,dc=com?one #nss_base_aliases ou=aliases,dc=example,dc=com?one #nss_base_netgroup ou=netgroup,dc=example,dc=com?one # attribute/objectclass mapping # Syntax: #nss_map_attribute rfc2307attribute mapped_attribute #nss_map_objectclass rfc2307objectclass mapped_objectclass # configure --enable-nds is no longer supported. # For NDS now do: #nss_map_attribute uniquemember member # configure --enable-mssfu-schema is no longer supported. # For MSSFU now do: #nss_map_objectclass posixaccount User #nss_map_attribute uid mssfuname #nss_map_attribute uniquemember posixmember #nss_map_attribute userpassword mssfupassword #nss_map_attribute homedirectory mssfuhomedirectory #nss_map_objectclass posixgroup Group #pam_login_attribute mssfuname #pam_filter objectclass=user #pam_password ad # configure --enable-authpassword is no longer supported # For authpassword support, now do: #nss_map_attribute userpassword authpassword #pam_password nds # For IBM SecureWay support, do: #nss_map_objectclass posixaccount aixaccount #nss_map_attribute uid username #nss_map_attribute gidnumber gid #nss_map_attribute uidnumber uid 52

53 #nss_map_attribute userpassword passwordchar #nss_map_objectclass posixgroup aixaccessgroup #nss_map_attribute cn groupname #nss_map_attribute uniquemember member #pam_login_attribute username #pam_filter objectclass=aixaccount #pam_password clear # Netscape SDK LDAPS #ssl on # Netscape SDK SSL options #sslpath /etc/ssl/certs/cert7.db # OpenLDAP SSL mechanism # start_tls mechanism uses the normal LDAP port, LDAPS typically 636 ssl start_tls #ssl on # 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 #TLS_CACERT /etc/openldap/certs/cacert.pem #TLS_REQCERT demand # SSL cipher suite # See man ciphers for syntax #tls_ciphers TLSv1 # Client certificate and key # Use these, if your server requires client authentication. #tls_cert #tls_key ssl no pam_password md5 53

54 2 Fichier slapd.conf : # $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v /09/27 20:00:31 kurt Exp $ # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/redhat/rfc822-mailmember.schema include /etc/openldap/schema/redhat/autofs.schema include /etc/openldap/schema/redhat/kerberosobject.schema include /etc/openldap/schema/krb5-kdc.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. referral ldap://mci-0475e2d1ae.int-evry.fr #pidfile #argsfile //var/run/slapd.pid //var/run/slapd.args # Create a replication log in /var/lib/ldap for use by slurpd. #replogfile /var/lib/ldap/master-slapd.replog # Load dynamic backend modules: # modulepath /usr/sbin/openldap # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # # 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 sasl-realm sasl-host INT-EVRY.FR mci-0475e2d1ae.int-evry.fr # 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 ####################################################################### 54

55 # ldbm database definitions ####################################################################### database suffix #suffix rootdn #rootdn ldbm "dc=int-evry,dc=fr" "o=my Organization Name,c=US" "cn=manager,dc=int-evry,dc=fr" "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 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd/tools. Mode 700 recommended. directory /var/lib/ldap # Indices to maintain index objectclass,uid,uidnumber,gidnumber,memberuid eq index cn,mail,surname,givenname eq,subinitial # Replicas to which we should propagate changes #replica host=ldap-1.example.com:389 tls=yes # bindmethod=sasl saslmech=gssapi # authcid=host/[email protected] 55

56 Annexe D - Tests sur OpenLDAP Affichage des différents mécanismes supportés : Connexion anonyme (simple/anonymous bind) : On test avant tout une connexion anonyme (option -x) vers l annuaire : [root@mci-0475e2d1ae root]# ldapsearch -h localhost -p 389 -x -b "" -s base -LLL supportedsaslmechanisms L annuaire affiche bien une réponse à la requête => Connexion établie avec succès. Connexion anonyme sécurisée par SSL/TLS : o TLS (option -ZZ ): [root@mci-0475e2d1ae root]# ldapsearch -H ldap://mci-0475e2d1ae.intevry.fr/ -p 389 -x -b "" -s base -LLL -ZZ supportedsaslmechanisms L annuaire affiche bien une réponse à la requête => Connexion établie avec succès. 56

57 o SSL (ldaps://): root]# ldapsearch -H ldaps://mci-0475e2d1ae.intevry.fr/ -x -b "" -s base -LLL supportedsaslmechanisms L annuaire affiche bien une réponse à la requête => Connexion établie avec succès. Authentification Kerberos/SASL : o Sans ticket Kerberos : [root@mci-0475e2d1ae root]# ldapsearch -H ldaps://mci-0475e2d1ae.intevry.fr/ -I -b "" -s base -LLL supportedsaslmechanisms L utilisateur ne disposant pas de ticket Kerberos valide, il est rejeté par l authentification SASL/GSSAPI. o Création d'un ticket Kerberos et test de nouveau : On tente maintenant d obtenir un ticket en tant qu utilisateur root/admin : [root@mci-0475e2d1ae root]# kinit root/admin 57

58 On vérifie que le ticket à bien été accordé avec la commande : klist On tente à nouveau de se connecter à l'annuaire LDAP. Lorsque le terminal demande l'authorization name, on laisse le champ vide, laissant ainsi le soin de l'authentification à GSSAPI : L'accès à l'annuaire LDAP a alors était acceptée par l'intermédiaire de Kerberos. On peut vérifier la présence d'un ticket LDAP sur le poste client avec, à nouveau, la commande klist : On remarque, ainsi, que l utilisateur dispose maintenant d un ticket Kerberos d accès à l annuaire LDAP. 58

59 Références o Kerberos V : o Kerberos V5 Installation guide, o OpenAFS, Kerberos 5, LDAP and Linux, o SASL : o RFC 1964 : Simple Authentication and Security Layer (SASL), o Project Cyrus, o Authentication service or what is Cyrus-SASL, o LDAP : RFC - Initial LDAP specs : o RFC Lightweight Directory Access Protocol o RFC The String Representation of Standard Attribute Syntaxes o RFC String Representation of Distinguished Names o RFC An LDAP URL Format (obsoleted by RFC 2255) RFC - LDAP v3 specs : o RFC Lightweight Directory Access Protocol (v3) o RFC Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions o RFC Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names o RFC The String Representation of LDAP Search Filters o RFC The LDAP URL Format o RFC A Summary of the X.500(96) User Schema for use with LDAPv3 59

60 URL : o LDAPMAN.ORG, o OpenLDAP 2.0 Guide de l'administrateur, o OpenLDAP, o LDAP v3 How to?, 60