Tutorial OpenLDAP. Installation et configuration (clients/serveurs) Migration NIS LDAP dans GRID5000 Sécurisation par SSL et optimisations

Transcription

1 Tutorial OpenLDAP Installation et configuration (clients/serveurs) Migration NIS LDAP dans GRID5000 Sécurisation par SSL et optimisations Version : 0.3 Février 2005 Résumé Ce document a pour objectif de familiariser le lecteur avec l installation et la configuration d un service d annuaire LDAP dans un environnement Linux, plus particulièrement dans l objectif de remplacer NIS. La première partie ( 1) est consacrée à ceux qui n ont pas de temps à perdre et qui souhaitent disposer rapidement d un environnement fonctionnel. Les sections suivantes détaillent plus amplement le fonctionnement de LDAP. Ainsi, après quelques rappels et définitions de principe ( 2), on trouvera une explication détaillée de l installation d un serveur LDAP ( 3) et de sa configuration ( 4). La section 5 est consacrée au principales commandes implémentées dans LDAP qui sont illustrées par des exemples tandis que la section 6 détaillera plus particulièrement les manipulations à effectuer pour migrer les tables NIS et plus généralement les fichiers systèmes dans la base LDAP de façon à ce que la gestion des comptes utilisateurs passe par LDAP. Alors que la section 7 détaille l installation et la configuration des clients LDAP, un dernière partie ( 8) traite des manipulations effectuées et des évolutions envisagées dans le cadre du projet Grid5000, cadre expérimental de ce document. A noter que le démon du service d annuaire LDAP est slapd et qu il est implémenté sur la plupart des plateformes UNIX. Les diverses manipulations présentées dans ce document sont largement orientées vers la distribution Debian, mais elles restent similaire dans le cadre d autres distributions comme RedHat ou Mandrake. 1

2 Table des matières 1 Pour les plus pressés : Ultra Quick Guide Prérequis Coté serveur Gestion des fichiers de configurations par LDAP Coté client Initialisation et configuration de base du client Gestion de l authentification des utilisateurs via LDAP Note à propos de la cohabitation NIS/LDAP Introduction Notion d annuaire electronique Mais qu apporte LDAP? LDAP, comment ca marche? Serveur local Annuaire local avec referrals Annuaire répliqué Annuaire distribué Le modèle de données LDAP Le Directory Information Tree (DIT) Les schémas LDIF La sécurité dans LDAP Authentification Contrôle d accès Protection des mots de passe Replications Referrals Installation du serveur LDAP Pré-requis Installation de OpenSSL Mise en place des certificats SSL Installation de Berkeley DB Installation de SASL Choix de l espace de nommage Installation de slapd Cas d une installation sur une Debian stable Autres cas Dans tous les cas Configuration du serveur LDAP Configurations globales Inclusion des schémas Logging, configuration d execution Options SASL

3 4.1.4 Options SSL/TLS Autres options de sécurité Configuration des Bases de Données Ajout d une base Configuration des ACLs Insertions minimales requises dans la base de données Modification du script de démarrage /etc/init.d/slapd Cas Debian stable Autres cas Faire en sorte que le serveur ne se lance pas sous root Vérifier que le serveur marche Les principales commandes LDAP Lancement du serveur slapd Commandes online/offline Ajouter des entrées dans la base LDAP Recherches dans la base LDAP Modifier/Supprimer des entrées dans la base Quelques outils graphiques Gestion des fichiers de configurations par LDAP Les outils de migration des fichiers de configuration Installation Configuration Migration les fichier passwd, group et hosts Recupération du contenu des tables NIS Conversion au format LDIF Insertion dans la base LDAP Migration des fichiers de configuration d automount Installation du package autofs-ldap Migration du fichier /etc/auto.home Installation du client LDAP Initialisation et configuration de base du client Cas d une installation sur une Debian stable Autres cas Dans tous les cas Vérifier que ça marche Authentification des utilisateurs via LDAP NSS (Name Service Switch) et LDAP PAM (Pluggable Authentication Module) et LDAP Configuration automount : le fichier auto.master Utilisation de NSCD

4 8 Evolution au sein du projet Grid Première experimentation : configuration locale Contexte Description Contribution des autres sites Seconde expérimentation : utilisation des referrals Quelques liens utiles 52 A Fichier de configuration slapd.conf 55 B Fichier de configuration ldap.conf 57 C Fichiers de configuration NSS 58 C.1 le fichier /etc/libnss-ldap.conf C.2 le fichier /etc/nsswitch.conf D Fichiers de configuration PAM 59 D.1 le fichier /etc/pam ldap.conf D.2 Le fichier /etc/pam.d/ssh D.3 Le fichier /etc/pam.d/su E le fichier automount.schema 61 F Quelques astuces et messages d erreurs rencontrés 62 G Programmation Perl avec LDAP 63 4

5 1 Pour les plus pressés : Ultra Quick Guide 1.1 Prérequis 1. Installation de openssl : apt-get install openssl 2. Mise en place des certificats SSL : suivre les instruction du page Installation de Berkeley DB : > apt-get install libdb3 libdb3-dev 4. Installation de SASL : en cours d investigation Coté serveur Installation de slapd (a) Sous debian stable : suivre les instructions du page 20. (b) Autres cas : apt-get install slapd libldap2 libldap2-dev ldaputils 2. Configuration du serveur : (a) Quelques initialisations : > mkdir -p /var/lib/ldap/grid5000.net > chmod 700 /var/lib/ldap/grid5000.net > cp /etc/ldap/slapd.conf /etc/ldap/slapd.conf_deb-orig (b) Récupérer le fichier slapd.conf fourni en annexe A page 55 et le placer dans /etc/ldap/slapd.conf (c) configurer syslog pour gérer les logs du serveur : ajouter la ligne suivante dans /etc/syslog.conf : local4.debug /var/log/slapd.log et relancer le service ( /etc/init.d/sysklogd restart ) Le fichier /etc/log/slapd.log sera une aide précieuse pour le débuggage. (d) Initialisation du contenu de la base LDAP : suivre les instructions du 4.3 page 27. (e) Modification du script de démarrage /etc/init.d/slapd : suivre les instructions du 4.4 page 28. (f) Faire en sorte que le serveur ne se lance pas sous root : en cours d investigations Vérifier que le serveur fonctionne : suivre les instructions du 4.6 page Gestion des fichiers de configurations par LDAP 1. Installer les outils de migration : (a) Sous Debian stable : forcer l install en testing : apt-get install -t testing migrationtools (b) Autres cas : apt-get install migrationtools 2. Configurer les outils de migration : suivre les instructions du page 37. 5

6 3. Migration les fichier passwd, group et hosts : suivre les instructions du 6.2 page Migration des fichiers de configuration d automount : Dans le cas ou une map automount est initialement gérée par NIS (/etc/auto.home dans notre cas) et que cette gestion doit passer par LDAP, suiver les instructions suivantes : (a) Installation du package autofs-ldap : apt-get install autofs-ldap (b) copier le fichier fourni en annexe E page 61 dans/etc/ldap/schema/ automount.schema (c) Décommenter dans le fichier de configuration slapd.conf la ligne : include /etc/ldap/schema/automount.schema (d) Migration du fichier /etc/auto.home sur le serveur LDAP suivre les instructions du page Coté client Initialisation et configuration de base du client 1. Installation (a) Cas Debian stable : compte tenu des remarques relatives à la gestion SSL pour le package client stable (voir 7.1 page 42), il convient de forcer l installation en testing : > apt-get install -t testing ldap-utils > apt-get install openssl (b) Autres cas : apt-get install ldap-utils openssl 2. cp /etc/ldap/ldap.conf /etc/ldap/ldap.conf_deb-orig 3. Recupérer le fichier fourni en annexe B page 57 et le placer dans /etc/ ldap/ldap.conf 4. copier le certificat du CA (qui a signé le certificat du serveur) et le placer dans /etc/ldap/ca-cert.pem 5. Vérifier que tout fonctionne : suivre les instructions du page Gestion de l authentification des utilisateurs via LDAP 1. NSS (Name Service Switch) et LDAP : (a) Installation : apt-get install libnss-ldap (en forcant en testing si vous êtes sur une Debian stable) (b) cp /etc/libnss-ldap.conf /etc/libnss-ldap.conf.old (c) Recupérer le fichier fourni en annexe C.1 page 58 et le placer dans /etc/libnss-ldap.conf (d) chmod 0600 /etc/libnss-ldap.conf (e) Recupérer le fichier fourni en annexe C.2 page 58 et le placer dans /etc/nsswitch.conf 6

7 (f) Pour vérifier que ça marche... : suivre les instructions du paragraphe associé au page PAM (Pluggable Authentication Module) et LDAP : Même si cette section est dédié aux utilisateurs pressés, il est bon, compte tenu l importance de PAM dans un système Linux, de lire complètement le page 47 et d en suivre les instructions Note à propos de la cohabitation NIS/LDAP Il est tout à fait possible de faire cohabiter une gestion des fichiers de configuration par NIS et par LDAP. En supposant que les étapes précédentes sont validées, il suffit de suivre les instructions suivantes : 1. Sauvegarder le fichier /etc/nsswitch.conf : cp /etc/nsswitch.conf /etc/nsswitch.conf.old 2. modifier /etc/nsswitch.conf pour qu il contienne les entrées suivantes : passwd: shadow: group: hosts: files nis ldap files nis ldap files nis ldap files nis ldap dns Pour vérifier que ça a bien été pris en compte utiliser la commande getent fichier où fichier peut-être *passwd, group ou hosts. Vous pourrez constater que le entrées de ces fichiers sont récupérer dans l ordre suivant : fichier local map NIS map LDAP 7

8 2 Introduction 2.1 Notion d annuaire electronique Un annuaire électronique est une base de données spécialisée qui permet de partager des bases d informations sur un réseau. Ces bases peuvent contenir toute sorte d informations, comme des coordonnées téléphoniques ou des données systèmes. Dans le cadre d un cluster de machine, un service d annuaire permettra par exemple de diffuser des données systèmes, comme celles contenues dans les principaux fichiers de configuration systèmes (/etc/passwd, /etc/shadow, /etc/ group, /etc/hosts ou encore /etc/auto.home etc...) Classiquement, ce service est rendu par le service NIS 1 développé par SUN. C est un protocole client/serveur qui permet de diffuser des données de configuration (utilisateurs, mots de passe, hote etc...) entre les ordinateurs sur un réseau. LDAP signifie Lightweight Directory Access Protocol, un protocole d annuaire sur TCP/IP utilisant les mêmes concepts que DNS 2, le service de nommage utilisé sur l Internet pour faire correspondre un nom explicite (comme www-id. imag.fr) à une adresse IP ( ). Le spectre des informations qui peuvent ainsi être diffusées est très large : cela va des coordonnées administratives aux données du compte utilisateur (login, passwd), en passant par les données systèmes de routage, de montage de partitions automatiques etc... Comme on l a dit, un annuaire éléctronique fonctionne de façon similaire à une base de données même si quelques différences subsistent : il est optimisé pour la lecture; l ajout et la modification de données peuvent être coûteuses; il fournit des fonctions de recherches plus avancées ; les données sont stockées sur un modèle distribué et des techniques de replications sont possibles, ce qui facilite un passage à l échelle efficace. la structure des données stockées, appelée schéma, peut être étendue en fonction de besoins locaux ; il est basé sur des standards établis qui assurent l interopérabilité entre plusieurs implémentations sur plusieurs supports (notamment OS). Ce document s intéressera à l implementation open source de LDAP développée à l université du Michigan, OpenLDAP 3 version 2.x sous Linux. LDAP apporte également de nombreuses garanties en terme de sécurité, puisque des mécanismes de chiffrement (SSL ou TLS) et d authentification (SASL 4 ), couplés à des mécanismes de règles d accès (ACL) permettent de protéger les transactions et l accès aux données. Par tous ces avantages, LDAP est un support de choix pour remplacer NIS dans la gestion des comptes machines et l authentification des utilisateurs. 1 Network Information System, ou Yellow Pages yp 2 Domain Name System 3 http :// 4 Simple Authentication and Security Layer 8

9 Nous nous interessons ici à la version 3 de LDAP, référencée sous le nom LDAPv3 [16]. 2.2 Mais qu apporte LDAP? Coté utilisateur, LDAP fournit les services suivants : un protocole d accès à l information contenue dans l annuaire; un modèle d information définissant le type de données contenues dans l annuaire; un modèle de nommage définissant comment l information est organisée et référencée ; un modèle fonctionnel qui définit comment on accède à l information ; un modèle de sécurité qui définit comment les données et les accès sont protégés, un modèle de duplication qui définit comment la base est répartie entre serveurs, des APIs pour développer des applications clientes, LDIF, un format d échange de données. 2.3 LDAP, comment ca marche? Le service d annuaire LDAP est basé sur un modèle client/serveur. Un ou plusieurs serveurs LDAP contiennent les données. Un client LDAP se connecte à un serveur et lui pose sa question. Il recoit en retour une réponse ou un pointeur (on parle de referral) sur l endroit (typiquement un autre serveur) ou le client pourra trouver plus d informations. Quelque soit le serveur auquel le client se connectera, il aura la même vue de l annuaire :un nom réferera à une même entrée quelque soit le serveur accédé, comme pour DNS. Il existe plusieurs configurations possibles qui sont détaillées dans la suite Serveur local Dans ce cadre, il n y a pas d interactions entre le serveur slapd du domaine et un quelconque autre serveur. Ce mode de fonctionnement est illustré dans la figure 1 Client 1. Requete 2. Réponse Serveur Fig. 1 Configuration locale (source :[2]) Cette configuration est particulièrement adapté au cas d un intranet local Annuaire local avec referrals Ici, le serveur est configuré sur le domaine local pour rendre les services d annuaires et de renvoyer un referral (une sorte de pointeur) vers un serveur 9

10 supérieur capable de répondre aux requêtes en dehors du domaine local. Il est à noter que par défaut et pour éviter de surcharger le serveur, le client à a charge de relancer la requete vers le serveur pointé (figure 2). 3. Nouvelle requete Serveur Supérieur Client 1. Requete 2. Referral Serveur Fig. 2 Configuration locale avec referral (source :[2]) Ce mode de fonctionnement est particulièrement adapté au cas des grilles de grappes, donc au cadre du projet Grid Annuaire répliqué Dans ce cadre, le démon slurpd est chargé de propager les changements effectués d un serveur slapd maître vers un ou plusieurs serveurs slapd esclave (figure 3). Fig. 3 Configuration par réplication (source :[2]) On permet ainsi de garantir une certaine qualité de service. L utilisation de slurpd vient avantageusement complémenter le mode de configuration précédent dans le cadre d une grille Annuaire distribué Dans cette configuration, le service local est partitionné en plusieurs sousservices, qui peuvent éventuellement être répliqués, et qui sont rassemblés par un ensemble de referrals vers des serveurs supérieurs ou inférieurs. 2.4 Le modèle de données LDAP LDAP utilise une approche orientée objet dans sa représentation des données, ce qui inclue notamment la définition d objets (par un ensemble de règles et d attributs) et la notion d héritage entre objets. 10

11 2.4.1 Le Directory Information Tree (DIT) Les données LDAP sont structurées dans une arborescence hiérarchique comparable à celle des systèmes de fichiers UNIX. Chaque noeud de l arbre correspond à une entrée 5 de l annuaire. Au sommet de cet arbre (appelé Directory Information Tree-DIT) se trouve la racine ou suffixe. A noter que chaque serveur possède une entrée spéciale, appelée root directory specific entry (rootdse) qui contient la description de l arbre et de son contenu. Les entrées correspondent à des objets abstraits ou issus du monde réel (une personne, une ressource de la grille ou des paramètres de configuration). Elles contiennent un certain nombre de champs appelés attributs qui caractérisent chaque entrée. Chaque entrée est référencée de manière unique dans le DIT par son distinguished name (DN). Cette unicité est obtenue par la combinaison des attributs listés dans le tableau 1. DN distinguished name CN common name DC domain components SN surname OU organizational unit UID user ID O organization Tab. 1 Principales abréviations utilisées dans le champ DN Le DN représente le nom de l entrée sous la forme du chemin d accès à celleci depuis le sommet de l arbre. On peut comparer le DN au path d un fichier Unix. Bien entendu, comme pour le système de fichier Unix, on peut utiliser un relative distinguished names (RDNs) pour désigner une entrée depuis une position particulière de l arbre. Ces notions sont illustrées dans la figure 4. Pour faire le parallèle avec la terminologie des bases de données relationnelles, les entrées correspondent à un enregistrement dans une table tandis que les attributs seraient l équivalent d un champ d une table Les schémas Un schéma LDAP définit la liste des entrées possibles, appelées alors object classes. Celles-ci sont organisées hiérarchiquement, en partant de la classe top à la racine du DIT. Pour chacune d entres elles, on trouve la liste des attributs associés, déclinés par leurs types et leurs syntaxes. Ces attributs peuvent être requis (ex :le nom d une personne) ou optionnels (comme un numéro de FAX). On y ajoute également les opérations et les flitres de comparaison autorisés. A noter que chaque classe d objets hérite des attributs de ses prédécesseurs.dans la hiérarchie. Les objet classes et leurs attributs sont normalisés dans [15] afin d assurer l interopérabilité entre les logiciels. Il sont référencés par un object 5 entry où directory service entry (DSE) dans la littérature anglaise. 11

12 DIT dc=grid5000,dc=fr ou=people ou=group Liste d attributs associés à une entry; format <type>:<valeur> uid=svarrett uid=georget cn=equipar cn=g5k cn: g5k objectclass: posixgroup objectclass: top userpassword: {crypt}x gidnumber: memberuid: svarrett memberuid: georget entry Distinguished Name: dn: cn=g5k,ou=group,dc=grid5000,dc=fr RDN (Relative Distinguished Name) depuis ou=group,dc=grid5000,dc=fr Fig. 4 Exemple de DIT : cas de la gestion NIS identifier (OID) unique attribué par l Internet Assigned Numbers Authority (IANA) LDIF LDAP Data Interchange Format (LDIF), définit dans [3], est un format texte 6 standard qui permet de représenter les données LDAP. Il a pour vocation de donner une meilleur lisibilité des données. Il est utilisé pour importer,exporter ou modifier les données de la base et doit obéir aux règles définies dans le schéma de l annuaire (voir 2.4.2) Un fichier LDAP est constitué d une suite d entrées séparées par un saut de ligne. Le format est le suivant : <attribut> : <valeur> ou le premier attribut d une entrée est le DN. Un entrée aura donc la forme suivante : # Ceci est un commentaire dn: <distinguished name> objectclass: <object class> objectclass: <object class>... <attribute type:<attribute value> <attribute type:<attribute value> Ainsi, comme précisé dans la figure 4, le format LDIF pour l entrée de RDN cn=g5k sera : dn: cn=g5k,ou=group,dc=grid5000,dc=fr objectclass: posixgroup 6 Le format utilisé est l ASCII, les données binaires étant codées en base

13 objectclass: top cn: g5k userpassword: {crypt}x gidnumber: memberuid: svarrett memberuid: georget Comme on le verra dans la section 6, cela traduit la ligne g5k:x:24560:svarrett,georget du fichier /etc/group. 2.5 La sécurité dans LDAP Le succès de LDAP (et son intérêt dans le cadre de Grid5000) vient de sa capacité à adresser les problèmes de sécurité suivants : les accès non autorisés (authentification) les droits d accès aux données (autorisation) la confidentialité et l intégrité des communications avec le serveur. Le gros du travail est de déterminer les règles d accès aux données. Pour cela, LDAP utilise les ACLs (Access Control Lists). Le serveur peut être de type readonly ou read-write. Dans les deux cas il faut déterminer pour chaque attribut quel est son niveau de confidentialité (un mot de passe est plus sensible qu une adresse mail) et quel utilisateur ou quelle application pourra y accéder en lecture (tout le monde, certains utilisateurs, uniquement les administrateurs...) ou en écriture (utilisateur, manager, administrateur) Authentification Pour pouvoir accéder à l annuaire LDAP, le client LDAP doit d abord s authentifier, c est à dire spécifier qui va accéder aux données. Si l authentification réussi, alors le client peut envoyer une requete au serveur qui vérifiera si le client est autorisé ou non a effectuer la requète. On parle de contrôle d accès (voir 2.5.2). Dans LDAP, l authentification est fournie par une opération bind. LDAPv3 propose plusieurs mécanismes d authentification : 1. Anonymous Authentication : il s agit d une connexion présentant un champ DN vide et aucun mot de passe (la requète est directement envoyée). Cela permet de consulter facilement les données accessible en lecture pour tous. 2. Simple Authentication : c est la méthode classique où le DN de l utilisateur est transmis avec le mot de passe en clair, ce qui doit être évité bien entendu dans le cadre d une grille. 3. Simple Authentication Over SSL/TLS : la session entre le serveur et le client est chiffrée par le protocole SSL, qui garantit entre autre la confidentialité et l intégrité des communications. Ainsi, le mot de passe ne transite plus en clair sur le réseau. Dans ce cadre, l authentification d un utilisateur est soit effectuée via son mot de passe mais on peut imaginer un mode (non encore testé) ou cette 13

14 authentification se fait sur simple présentation d un certificat contenant la clé publique de l utilisateur, la clé privée associée étant stockée sur un support sûr et personnel (carte à puce, clé USB etc...). Cette dernière approche sera étudiée dans le cadre de Grid Simple Authentication and Security Layer (SASL) : défini dans [10], est un mode de sécurité extensible proposant des mécanismes d authentification plus élaborés pour tout protocole orienté connexion tel que IMAP ou LDAP. Le mécanisme d authentification est négocier entre le client et le serveur. En voivi les principaux : PLAIN ou LOGIN ces mécanismes ne présentent pas plus d avantage que l authentification simple de LDAP, et peuvent donc être oubliés DIGEST-MD5 Bien que moins puissant que les approches à tierce partie de confiance comme Kerberos ou PKI, ce mécanisme DOIT être implémenté si l emploi de de SSL n est pas envisagé. Il présente l avantage d être relativement simple à mettre en place et se base sur un protocole de challenge/réponse qui offre une protection significative contre un certain nombre d attaques. GSSAPI 7 permet d utiliser les mécanismes de Kerberos V [6, 11], un système d authentification sécurisé à tierce personne de confiance conçu pour les réseaux TCP/IP. Ce type de système est particulièrement approprié aux environnement de type cluster. SKEY pour S/Key est un mécanisme de type OTP (One Time Password) basé sur MD5. EXTERNAL permet d utiliser des mécanismes d authentification d une couche inférieure, comme SSL/TLS Il y a encore beaucoup d autres mécanismes possibles, comme SRP (Secure Remote Passwords [17]) Contrôle d accès Il s agit de définir les droits d accès des utilisateurs sur les ressources de l annuaire (objets et attributs). La syntaxe est de la forme : Acces à <quoi> par <qui> : <type d accès autorisé> ce qui se traduit dans le format du fichier de configuration slapd.conf par access to <quoi> by <qui> <type_d acces_autorisé> Dans la partie <quoi>, on peut spécifier : une expression régulière, correspondant à un dn : dn=<regular expression> une liste d attributs : attrs=<attribute list> un filtre : filter=<ldap filter> Les possiblités pour <qui> (resp. <type d accès autorisé>) sont résumés dans le tableau 2 (resp. 3). 7 Generic Security Service Application Program Interface, défini dans [8] 14

15 * tous les utilisateurs, aussi bien anonymes qu authentifiés anonymous utilisateur non authentifié et donc anonyme self utilisateurs associé à l entrée ciblée users utilisateur authentifié dn=<regex> utilisateur qui correspond à l expression regulière regex dn.<scope>=<dn> utilisateur dans le scope (voir??) du DN Tab. 2 possibilité pour la directive <qui> dans les ACLs Niveau Privilège accordé write modifié/renommé read lecture des résultats de recherche search requis pour l application de filtre de recherche compare requis pour les comparaisons auth requis pour s authentifier (bind) none aucun accès Tab. 3 possibilité pour la directive <type d accès autorisé> dans les ACLs A noter que dans le tableau 3, un niveau donné accorde également les privilèges des niveaux inférieurs. Quelques exemples : L exemple suivant donne l accès en lecture pour tout le monde : access to * by * read La directive qui suit autorise un utilisateur à modifier son entrée et les autres utilisateurs à lire les entrées. access to * by self write by * read L évaluation des contrôles d accès se fait dans l ordre ou les règles sont définies dans le fichier de configuration avec un arret d évaluation à la première correspondance ( first match ). On verra un exemple de l impact d une ACL sur les recherches d entrées au Protection des mots de passe Dans LDAP, les mots de passe peuvent posséder un préfixe qui précise la façon dont ils sont encoder. Par exemple, si on considère l entrée dn: cn=svarrett,ou=people,dc=grid5000,dc=fr objectclass: person cn: Sebastien Varrette sn: varrette userpassword: {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ... On voit ici que le mot de passe a été haché avec MD5 puis encodé en base 64. [4] définit les préfixes de plusieurs algorithmes de chiffrement. Voici les plus 15

16 communs : {CRYPT} utilise un hachage par la fonction Unix crypt(), basé è sur DES. C est mode le plus faible en terme de sécurité par arpport aux autres. {MD5} hachage par MD5 puis encodage en base64. {SHA} (Secure Hash Algorithm) hachage par SHA-1 puis encodage en base64. {SSHA} (Salted Secure Hash Algorithm) : développé par Netscape, il s agit du mode précédent avec une meilleur gestion du seed. {SSHA} est le mode recommandé pour le stockage sûr de données dans LDAP. 2.6 Replications La réplication est une technique permettant à un serveur (maître) de diffuser le contenu de sa base LDAP à un ou plusieurs serveurs (esclave). Toute modification apportée sur la base LDAP dans l annuaire principal est automatiquement répercutée sur l esclave dès que celui-ci est joignable pour réaliser l opération. Cette réplication permet ainsi d assurer une continuité du service d authentification, même si l un des deux serveurs est momentanément indisponible. Mais cela ne dispense absolument pas de la nécessité de sauvegarder régulièrement la base LDAP. 2.7 Referrals TODO 16

17 3 Installation du serveur LDAP 3.1 Pré-requis Il y a un certain nombre de composants à installer en dehors de OpenLDAP pour être totalement compatible avec LDAPv Installation de OpenSSL Sous Debian : > apt-get install openssl Le site officiel de OpenSSL est : TODO : donner les détails de la compilation from scratch TODO : préciser version minimale ou ca marche Mise en place des certificats SSL Le protocole TLS/SSL repose sur la présente de certificats (au moins au niveau serveur). Un certificat est un fichier contenant une clé publique et un certain nombre de renseignements sur le serveur. Ce certificat est signé numériquement par une autorité de certification (CA) qui certifie ainsi que le serveur possède effectivement la clé privée. On commence par créer sur le serveur le répertoire qui contiendra les certificats : > mkdir -p /etc/ldap/certificates Depuis la version 2.1 de OpenLDAP, les client vérifie complètement les certificats des serveurs, ce qui va nous obliger à creer un certificat pour le CA 8. On distingue plusieurs étapes : 1. Creation du certificat pour le CA : On utilisera le script CA.sh > locate CA.sh /usr/lib/ssl/misc/ca.sh Note : vous aurez certainement besoin de lancer un updatedb avant d obtenir une réponse de locate. > cd /etc/ldap/certificate/ > /usr/lib/ssl/misc/ca.sh -newca CA certificate filename (or enter to create) Making CA certificate... Using configuration from /usr/lib/ssl/openssl.cnf Generating a 1024 bit RSA private key writing new private key to./democa/private/./cakey.pem Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: You are about to be asked to enter information that will be incorporated into your certificate request. 8 Source : 17

18 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) [AU]:FR State or Province Name (full name) [Some-State]:Isere Locality Name (eg, city) []:Grenoble Organization Name (eg, company) [Internet Widgits Pty Ltd]:IMAG Organizational Unit Name (eg, section) []:ID Common Name (eg, YOUR name) []:CA-IDPOT Address []:Sebastien.Varrette@imag.fr Cet appel a créé un répertoire (democa) contenant notamment le certificat du CA ( cacert.pem ). 2. Création du certificat du serveur LDAP (le common name doit correspondre au nom complet du serveur, rendu par la commande hostname -f ) : > openssl req -new -nodes -keyout newreq.pem -out newreq.pem \ -days 365 Using configuration from /usr/lib/ssl/openssl.cnf 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) [AU]:FR State or Province Name (full name) [Some-State]:Isere Locality Name (eg, city) []:Grenoble Organization Name (eg, company) [Internet Widgits Pty Ltd]:IMAG Organizational Unit Name (eg, section) []:ID Common Name (eg, YOUR name) []:ldap-idpot.clic.id Address []:Sebastien.Varrette@imag.fr L option -nodes empeche le chiffrement de la clé secrète (il semblerait que OpenLDAP ne marche qu avec des clés privées non chiffrées). Cet appel a généré le fichier newreq.pem qui contient la clé secrete RSA et une requête de signature de certificat par le CA. 3. Signature du certificat du serveur par le CA : > /usr/lib/ssl/misc/ca.sh -sign Using configuration from /usr/lib/ssl/openssl.cnf 18

19 Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryname :PRINTABLE: FR stateorprovincename :PRINTABLE: Isere localityname :PRINTABLE: Grenoble organizationname :PRINTABLE: IMAG organizationalunitname:printable: ID commonname :PRINTABLE: ldap-idpot.clic.id address :IA5STRING: Certificate is to be certified until Jun 14 12:25: GMT (365 days) Sign the certificate? [y/n]:y [...] Signed certificate is in newcert.pem 4. Installation de tous ces certificats, afin qu ils soient utilisés par OpenL- DAP : > mv newreq.pem LDAPserver-key.pem > mv newcert.pem LDAPserver-cert.pem > ln -s democa/cacert.pem CA-cert.pem > chmod 600 LDAPserver-key.pem Installation de Berkeley DB La base LDAP peut être stockée sous plusieurs formats qui sont résumés dans le tableau 4 Type bdb dnssrv ldbm ldap meta monitor passwd perl shell sql Description Berkeley DB transactional backend DNS SRV backend Lightweight DBM backend Lightweight Directory Access Protocol (Proxy) backend Meta Directory backend Monitor backend Provides read-only access to passwd(5) Perl programmable backend Shell (external program) backend SQL programmable backend Tab. 4 Formats de bases de données pour la base LDAP (source :[9]) On se propose ici d utiliser le format berkeley DB (BDB) > apt-get install libdb3 libdb3-dev (Il faudrait peut-être tester la version 4) 19

20 3.1.4 Installation de SASL En cours d investigations... Pour le moment, une authentification simple sécurisée par SSL nous paraît suffisante Choix de l espace de nommage Cette étape consiste à définir comment les entrées de l annuaire vont être organisées, nommées et accédées. L objectif est de faciliter leur consultation et leur mise à jour mais aussi de prévoir leur duplication, leur répartition entre plusieurs serveurs ou leur gestion par plusieurs personnes. Dans le cadre de la première expérience grid5000 sur Grenoble,la racine choisie est dc=grid5000,dc=net. Les données sont organisées selon le schéma exposé dans la figure 5, correspondant à une configuration locale (voir 2.3.1). ldap idpot.clic.id dc=grid5000,dc=net Grenoble ou=people (/etc/passwd) ou=group ou=hosts ou=auto.home (/etc/group) (/etc/hosts) (/etc/auto.home) Fig. 5 Architecture de la première expérience Grid5000 sur Grenoble Dans un premier temps, les machines des autres site pourront être configurées pour venir compléter leur configuration NSS avec les données LDAP présentes sur le serveur ldap-idpot.clic.id (voir 1) On verra dans la section 8 l evolution envisagée pour cette architecture. La racine changera notamment pour dc=grid5000,dc=org 3.2 Installation de slapd Cas d une installation sur une Debian stable Si vous utilisez une debian stable, le package slapd (version au moment où ce document est écrit) n est pas configuré pour supporter TLS. Il faudra récupérer les sources 9 du package et changer une règle de compilation. > cd ; mkdir slapd_stable-sources > cd slapd_stable-sources > apt-get source slapd > apt-get build-dep slapd > apt-get install libssl-dev 9 Au besoin, ajouter les lignes suivantes dans /etc/apt/sources.list : deb-src http ://security.debian.org/ stable/updates main contrib non-free deb-src ftp ://ftp.fr.debian.org/debian-non-us stable non-us/main non- US/contrib non-us/non-free puis lancer un apt-get update. 20