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

Tutorial OpenLDAP Installation et configuration (clients/serveurs) Migration NIS LDAP dans GRID5000 Sécurisation par SSL et optimisations Sebastien.Varrette@imag.fr 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

Table des matières 1 Pour les plus pressés : Ultra Quick Guide 5 1.1 Prérequis............................... 5 1.2 Coté serveur............................... 5 1.3 Gestion des fichiers de configurations par LDAP......... 5 1.4 Coté client................................ 6 1.4.1 Initialisation et configuration de base du client...... 6 1.4.2 Gestion de l authentification des utilisateurs via LDAP.. 6 1.4.3 Note à propos de la cohabitation NIS/LDAP....... 7 2 Introduction 8 2.1 Notion d annuaire electronique................... 8 2.2 Mais qu apporte LDAP?....................... 9 2.3 LDAP, comment ca marche?.................... 9 2.3.1 Serveur local......................... 9 2.3.2 Annuaire local avec referrals................. 9 2.3.3 Annuaire répliqué...................... 10 2.3.4 Annuaire distribué...................... 10 2.4 Le modèle de données LDAP.................... 10 2.4.1 Le Directory Information Tree (DIT)............ 11 2.4.2 Les schémas.......................... 11 2.4.3 LDIF............................. 12 2.5 La sécurité dans LDAP....................... 13 2.5.1 Authentification....................... 13 2.5.2 Contrôle d accès....................... 14 2.5.3 Protection des mots de passe................ 15 2.6 Replications.............................. 16 2.7 Referrals................................ 16 3 Installation du serveur LDAP 17 3.1 Pré-requis............................... 17 3.1.1 Installation de OpenSSL................... 17 3.1.2 Mise en place des certificats SSL.............. 17 3.1.3 Installation de Berkeley DB................. 19 3.1.4 Installation de SASL..................... 20 3.1.5 Choix de l espace de nommage............... 20 3.2 Installation de slapd......................... 20 3.2.1 Cas d une installation sur une Debian stable....... 20 3.2.2 Autres cas........................... 21 3.2.3 Dans tous les cas........................ 21 4 Configuration du serveur LDAP 22 4.1 Configurations globales........................ 22 4.1.1 Inclusion des schémas.................... 22 4.1.2 Logging, configuration d execution............. 23 4.1.3 Options SASL........................ 24 2

4.1.4 Options SSL/TLS...................... 24 4.1.5 Autres options de sécurité.................. 25 4.2 Configuration des Bases de Données................ 25 4.2.1 Ajout d une base....................... 25 4.2.2 Configuration des ACLs................... 26 4.3 Insertions minimales requises dans la base de données...... 27 4.4 Modification du script de démarrage /etc/init.d/slapd...... 28 4.4.1 Cas Debian stable...................... 28 4.4.2 Autres cas........................... 29 4.5 Faire en sorte que le serveur ne se lance pas sous root...... 29 4.6 Vérifier que le serveur marche.................... 29 5 Les principales commandes LDAP 31 5.1 Lancement du serveur slapd..................... 31 5.2 Commandes online/offline...................... 31 5.3 Ajouter des entrées dans la base LDAP.............. 32 5.4 Recherches dans la base LDAP................... 33 5.5 Modifier/Supprimer des entrées dans la base............ 34 5.6 Quelques outils graphiques...................... 36 6 Gestion des fichiers de configurations par LDAP 37 6.1 Les outils de migration des fichiers de configuration........ 37 6.1.1 Installation.......................... 37 6.1.2 Configuration......................... 37 6.2 Migration les fichier passwd, group et hosts............ 39 6.2.1 Recupération du contenu des tables NIS.......... 39 6.2.2 Conversion au format LDIF................. 39 6.2.3 Insertion dans la base LDAP................ 39 6.3 Migration des fichiers de configuration d automount....... 40 6.3.1 Installation du package autofs-ldap............. 40 6.3.2 Migration du fichier /etc/auto.home............ 40 7 Installation du client LDAP 42 7.1 Initialisation et configuration de base du client.......... 42 7.1.1 Cas d une installation sur une Debian stable....... 42 7.1.2 Autres cas........................... 42 7.1.3 Dans tous les cas........................ 42 7.1.4 Vérifier que ça marche.................... 43 7.2 Authentification des utilisateurs via LDAP............ 44 7.2.1 NSS (Name Service Switch) et LDAP........... 45 7.2.2 PAM (Pluggable Authentication Module) et LDAP.... 47 7.3 Configuration automount : le fichier auto.master......... 49 7.4 Utilisation de NSCD......................... 49 3

8 Evolution au sein du projet Grid5000 50 8.1 Première experimentation : configuration locale.......... 50 8.1.1 Contexte........................... 50 8.1.2 Description.......................... 50 8.1.3 Contribution des autres sites................ 50 8.2 Seconde expérimentation : utilisation des referrals......... 51 9 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.................... 58 C.2 le fichier /etc/nsswitch.conf..................... 58 D Fichiers de configuration PAM 59 D.1 le fichier /etc/pam ldap.conf.................... 59 D.2 Le fichier /etc/pam.d/ssh...................... 59 D.3 Le fichier /etc/pam.d/su....................... 60 E le fichier automount.schema 61 F Quelques astuces et messages d erreurs rencontrés 62 G Programmation Perl avec LDAP 63 4

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 3.1.2 page 17. 3. Installation de Berkeley DB : > apt-get install libdb3 libdb3-dev 4. Installation de SASL : en cours d investigation... 1.2 Coté serveur... 1. Installation de slapd (a) Sous debian stable : suivre les instructions du 3.2.1 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... 3. Vérifier que le serveur fonctionne : suivre les instructions du 4.6 page 29. 1.3 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 6.1.2 page 37. 5

3. Migration les fichier passwd, group et hosts : suivre les instructions du 6.2 page 39. 4. 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 6.3.2 page 40. 1.4 Coté client... 1.4.1 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 7.1.4 page 43. 1.4.2 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

(f) Pour vérifier que ça marche... : suivre les instructions du paragraphe associé au 7.2.1 page 46. 2. 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 7.2.2 page 47 et d en suivre les instructions. 1.4.3 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

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 (129.88.69.11). 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 ://www.openldap.org 4 Simple Authentication and Security Layer 8

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. 2.3.1 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. 2.3.2 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

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 Grid5000. 2.3.3 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. 2.3.4 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

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

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: 24560 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). 2.4.3 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 64. 12

objectclass: top cn: g5k userpassword: {crypt}x gidnumber: 24560 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). 2.5.1 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

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 Grid5000. 4. 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]) 2.5.2 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

* 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 5.4. 2.5.3 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

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

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 LDAPv3. 3.1.1 Installation de OpenSSL Sous Debian : > apt-get install openssl Le site officiel de OpenSSL est : http://www.openssl.org. TODO : donner les détails de la compilation from scratch TODO : préciser version minimale ou ca marche 3.1.2 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 : http://www.openldap.org/faq/data/cache/185.html 17

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

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 emailaddress :IA5STRING: Sebastien.Varrette@imag.fr Certificate is to be certified until Jun 14 12:25:03 2005 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 3.1.3 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

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. 3.1.5 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 3.2.1 Cas d une installation sur une Debian stable Si vous utilisez une debian stable, le package slapd (version 2.0.23 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

Pour activer SSL : > cd openldap2-2.0.23 puis éditer le fichier debian/rules en changeant--without-tls par--with-tls. Il suffit alors de compiler le package :./debian/rules binary. Cette commande va créer les packages.deb à installer : > cd ~/slapd_stable-sources > dpkg -i slapd_2.0.23-6.3_i386.deb libldap2_2.0.23-6.3_i386.deb \ libldap2-dev_2.0.23-6.3_i386.deb ldap-utils_2.0.23-6.3_i386.deb Debconf va vous poser une série de questions : 1. Directory initialization method : auto 2. Directory suffix style : custom 3. Enter your suffix : dc=grid5000,dc=net 4. Admin password : ne rien entrer, idem pour la vérification. Ainsi, un mot de passe sera généré automatiquement. Nous le changerons par la suite. 5. Replicate to another LDAP server : No Attention : pour empêcher la mise a jour automatique de ces packages via le dépot Debian, il faut les marquer HOLD, par exemple avec dselect (en appuyant sur = pour les packages en question) Cela signifie aussi que vous devrez vous-même vous assurer des alertes de sécurité! 3.2.2 Autres cas Dès la version testing, le package slapd (version 2.1.30) est correctement configuré. La seule manipulation à faire est alors : > apt-get install slapd libldap2 libldap2-dev ldap-utils Remarque : il semblerait que les versions de slapd > 2.1 utilisent le format berkeley DB 4.2... De même, Debconf va vous poser une série de questions : 1. DNS domain name : entrer grid5000.net afin que la base du DIT soit dc=grid5000,dc=net. 2. Enter the name of your organization : Laboratoire ID-IMAG 3. Admin password : tapez secret par exemple, on le changera par la suite. Re-tapez secret ensuite. 4. Allow LDAPv2 protocol : No 3.2.3 Dans tous les cas... Une fois l installation terminée, stopper le serveur LDAP par/etc/init.d/slapd stop; Les fichiers de configuration seront localisés dans /etc/ldap/ 21

4 Configuration du serveur LDAP C est le fichier slapd.conf qui gère la configuration du serveur. Le format général de ce fichier est le suivant : # Fichier /etc/ldap/slapd.conf #################################### # Section de configurations globales # Inclusion des schémas # configuration globales des logs, de SSL etc... ############################ # Database #1 - Berkeley DB # Parametres de la base de données # ACL de cette base ############################ # Database #2 - Berkeley DB # Paramètres de la base de données # ACL de cette base Il faut créer le répertoire qui contiendra la base de données. Sous root : > mkdir -p /var/lib/ldap/grid5000.net > chmod 700 /var/lib/ldap/grid5000.net Je vous conseille de garder une sauvegarde du fichier fourni par défaut : > cp /etc/ldap/slapd.conf /etc/ldap/slapd.conf_deb-orig Le fichier complet pour cette prise en main est fournie dans annexe A. Les sections 4.1 et 4.2 détaillent chaques parties de ce fichier. Si vous souhaitez utiliser directement le fichier fourni sans lire ces explications, n oubliez pas : 1. de configurer syslog pour gérer les logs du serveur ( 4.1.2 page 23). 2. de changer le mot de passe de l administrateur de la base LDAP (directive rootpw : voir 4.2.1 page 25) 3. de passer directement à la section 4.3 page 27 pour achever la configuration du serveur. 4.1 Configurations globales 4.1.1 Inclusion des schémas La première chose à définir : quels schémas 10 devra supporter le serveur?. Le tableau 5 liste les schémas les plus utiles (et qui sont pour la plupart fournis par défaut). Ce document ne traite pas de la création de nouveau schémas. Les schemas sont placés par défaut dans /etc/ldap/schema. On les ajoute par l appel include <filename> Typiquement, on aura donc les inclusions suivantes : 10 Les schémas ont été introduit au 2.4.2, page 11 22

Schéma Description core.schema LE fichier minimal à inclure. Définit les attributs basiques de LDAPv3 confomément à [16, 15] cosine.schema support des annuaires COSINE et X500 inetorgperson.schema informations sur les utilisateurs etc... (cf [13]) java.schema stockage d objets Java ou de références JDNI (cf [12]) misc.schema divers objets et attribut. nis.schema nécessaire pour remplacer NIS par LDAP (cf[4] et 6) openldap.schema divers objet utilisé dans opneldap, pour informations. automount.schema nécessaire pour migrer des map automount; schéma non fourni par défaut, voir 6.3 Tab. 5 Liste des principaux schémas disponibles # Schema and objectclass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema 4.1.2 Logging, configuration d execution Il s agit là de configuration la gestion des logs, des fichiers de PID etc... Niveau Description -1 enable all debugging 0 no debugging 1 trace function calls 2 debug packet handling 4 heavy trace debugging 8 connection management 16 print out packets sent and received 32 search filter processing 64 configuration file processing 128 access control list processing 256 stats log connections/operations/results 512 stats log entries sent 1024 print communication with shell backends 2048 print entry parsing debugging Tab. 6 Liste des niveaux de log (source :[2]) Le niveau des log est spécifié par la directive loglevel. Les valeurs possibles sont définies dans le tableau 6. La combinaison de plusieurs Niveau se fait en les ajoutant 11. 11 Le niveau par défaut est 296=256+32+8 23

A noter que les informations de log utilisent le facility LOG LEVEL4 de syslog. Il faut donc ajouter la ligne suivante dans /etc/syslog.conf : local4.debug /var/log/slapd.log et relancer le service ( /etc/init.d/sysklogd restart ) Ce fichier /etc/log/slapd.log sera une aide précieuse pour le débuggage. D autres paramètres contrôlent l exécution : pidfile <filename> : le fichier ou sera stocké le PID de slapd 12. argsfile <filename> : les argument passés à slapd. schemacheck <on off> : vérifie la conformité de toutes les entrées aux schémas supportés. Dans notre cas, on aura : ## Added logging parameters loglevel 296 ## Added execution control schemacheck on pidfile /var/run/slapd.pid argsfile /var/run/slapd.args # Where to store the replica logs replogfile /var/lib/ldap/replog 4.1.3 Options SASL [ En cours d investigations...] Typiquement sasl-host hostname sasl-realm string sasl-secprops propertie 4.1.4 Options SSL/TLS SSL/TLS recquiert la génération d un certificat valide pour le serveur, avec la clé privée associée. 3.1.2 a permis de creer le certificat pour l autorité de certification (CA) et le serveur. On trouve ainsi les directives : TLSCertificateFile : l emplacement du certificat du serveur. TLSCertificateKeyFile : l emplacement de la clé privée associée au certificatdu serveur. Ce fichier ne doit être lisible que par root!!! TLSCACertificateFile : l enplacement du certificat du CA qui a signer celui du serveur. Cette directive est obligatoire depuis OpenLDAP2.1 TLSCipherSuite : les specifications des algorithmes de chiffrement. Dans notre cas : ## TLS options for slapd TLSCipherSuite HIGH TLSCACertificateFile /etc/ldap/certificate/ca-cert.pem TLSCertificateFile /etc/ldap/certificate/ldapserver-cert.pem TLSCertificateKeyFile /etc/ldap/certificate/ldapserver-key.pem 12 Ce fichier est principalement utilisé par les script de shutdown 24

4.1.5 Autres options de sécurité On distingue un certain nombre d autres directives de sécurité : password-hash : définit le schéma de chiffrement des mots de passe par défaut. Les valeurs possibles sont celles évoquées dans le 2.5.3 page 15, celle par défaut étant {SSHA} security permet de définir un ssf 13 (une valeur entière comprise entreminssf et maxssf, paramètres définis dans 4.1.3) Par exemple : security update_sasl=128,update_tls=128 require : définit les conditions générales d accès à l annuaire. les principales options disponibles sont none, authc (pas d accès anonyme, tout client doit s authentifier), bind (requete bind obligatoire), LDAPv3 (le client doit utiliser la version 3 du protocole LDAP) allow/disallow : permet d activer/désactiver certaines fonctionnalités. Par exemple, allow bind_v2 autorise les requêtes bind de clients LDAPv2. Pour nous, on ne s intéressera qu à la première option : # Misc security settings password-hash {SSHA} 4.2 Configuration des Bases de Données Un serveur LDAP est capable de gérer plusieurs bases de données en même temps. On place les détails de la configuration de chaque base après les configurations globales dans le fichier slapd.conf ( 4 page 22). 4.2.1 Ajout d une base Dans notre exemple, on ajoute au fichier slapd.conf les lignes suivantes : ### Database Directives Berkeley DB ### database ldbm suffix "dc=grid5000,dc=net" rootdn "cn=admin,dc=grid5000,dc=net" rootpw {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxx directory "/var/lib/ldap/grid5000.net" mode 0600 La directive database précise le format de base de données utilisé (la liste des formats possibles est donnée dans le tableau 4, page 19) suffix permet de définir le DN racine géré Le rootdn est très important : il définit l utilisateur autorisé à créer des entrées dans la base de données. Cet utilisateur devra être ajouté à la base (voir?? page??.) rootpw correspond au mot de passe de l utilisateur rootdn. Pour le générer, il suffit d utiliser la commande suivante : 13 security strength factor 25

> slappasswd New password: Re-enter new password: {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxx La chaine renvoyée peut alors être ajouter à la directive rootpw. directory définit le répertoire ou sera physiquement stocké la base de données, tandis que mode précise les droits d accès des fichiers créés dans ce répertoire. On complète ensuite cette configuration par diverses optimisations : 1. La génération d index qui permettent d accélerer les recherches. Les types d index supportés sont les suivants : approx (approximate) eq (equality) pres (presence) sub (substring) 2. le paramètre cachesize qui définit le nombre d entrées qui doivent être gardées en mémoire (par défaut 1000). Dans notre cas, on utilisera : # Indexing options index objectclass index cn cachesize 2000 eq pres,eq Note : voici un indexage optimisé trouvé sur un site a tester pour le cas de la migration de données NIS. Je le place ici en attendant de le placer dans une partie dédiée : index uid eq index uidnumber index gidnumber index memberuid index cn index sn index objectclass index nisdomain index nisnetgrouptriple index membernisnetgroup index nismapname index amdmapname index amdmapkey eq eq eq pres,eq,sub pres,eq,sub pres,eq eq pres,eq,sub pres,eq,sub eq eq eq 4.2.2 Configuration des ACLs Les ACLs, notamment leur syntaxe, ont déjà été abordées dans le 2.5.2 page 14. Elles précisent pour la base de données en question qui a accès à quoi. Voici celle utilisée dans cet exemple : 26

# The userpassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry and the special user nss access to attribute=userpassword by dn="cn=admin,dc=grid5000,dc=net" write by dn="cn=nss,dc=grid5000,dc=net" read by self write by anonymous auth by * none # The admin dn has full write accesswhereas the special # user nss can read everything. Others should authenticate. access to * by dn="cn=admin,dc=grid5000,dc=net" write by dn="cn=nss,dc=grid5000,dc=net" read by * auth On peut voir le rôle particulier du DN cn=nss,dc=grid5000,dc=net qui sera utilisé pour toutes les requêtes de lecture (en particulier des mots de passe) dans la base (et ainsi éviter une lecture anonyme du contenu de la base). On verra un exemple de l impact de cette ACL au 5.4. 4.3 Insertions minimales requises dans la base de données A ce stade, la base de données est complètement vide et il convient d y intégrer au minimum la définition de la structure de la base et de l utilisateur administrateur et d un utilisateur spécial qui sera seul habilité à lire les données de la base directement. La section 5 détaillera les commandes que nous allons utiliser ici. Nous utiliserons des fichiers au format LDIF (voir 2.4.3, page 12) pour ces insertions. Les insertions de base sont incluses dans le fichier init_ldap-database.ldif : > cat /etc/ldap/init_grid5000-database.ldif ## Build the root node. dn: dc=grid5000,dc=net dc: grid5000 objectclass: dcobject objectclass: organization o: Annuaire LDAP Grid5000 ## Entry for the admin root # userpassword is the same as the one precised in # the rootpw attribute of /etc/ldap/slapd.conf dn: cn=admin,dc=grid5000,dc=net objectclass: organizationalrole objectclass: simplesecurityobject cn: admin description: LDAP administrator 27

userpassword: {SSHA}cYIqaZxwiHB8eMbTgV1SFTWBMJKWBi+Y ## Entry for the special user for user-lookups # here, password corresponds to nsslookup dn: cn=nss,dc=grid5000,dc=net objectclass: organizationalrole objectclass: simplesecurityobject cn: nss description: LDAP NSS user for user-lookups userpassword: {SSHA}EyAP39vIKLlR1uQR5PIC+liuERtwO0sK Remarque : 1. N oubliez pas de changer la valeur du champ userpassword pour cn= admin,dc=grid5000,dc=net : il doit correspondre à l entrée rootpw du fichier /etc/ldap/slapd.conf. 2. Le mot de passe de l utilisateur spécial n est pas très important car il figurera en clair (malheureusement) dans deux fichiers de configuration au niveau client (voir 7.2.1 et 7.2.2). Cet utilisateur évite simplement les requêtes anonymes... Pour ajouter ces données dans la base de données : > slapadd -v -l /etc/ldap/init_grid5000-database.ldif added: "dc=grid5000,dc=net" (00000001) added: "cn=admin,dc=grid5000,dc=net" (00000002) added: "cn=nss,dc=grid5000,dc=net" (00000003) 4.4 Modification du script de démarrage /etc/init.d/slapd Pour que le serveur puisse répondre à des requètes via une URL ldap TODO : expliquer le format des urls et notamment ldaps, il est nécessaire de modifier le script de démarrage de slapd (il s agit du script /etc/init.d/slapd). La première idée (qui semble la plus logique) serait de placer la ligne SLAPD_OPTIONS="-h ldap:/// ldaps:/// " dans le fichier /etc/default/slapd (qui est censé spécifier les options du binaire slapd pour le script de démarrage) mais l usage des guillemets pose problème. 4.4.1 Cas Debian stable Curieusement, même si un fichier/etc/default/slapd existe, les variables qu il spécifie ne sont pas utilisées dans le script de démarrage! Toujours est il qu on remplacera dans /etc/init.d/slapd --exec /usr/sbin/slapd dans la fonction start()par : --exec /usr/sbin/slapd -- -h ldap:/// ldaps:///. 28

4.4.2 Autres cas TODO : dans les versions récentes de slapd, le fichier /etc/default/slapd contient la ligne # Example usage: SLAPD_SERVICES="ldap:/// ldaps:///" a ajouter... On modifie /etc/init.d/slapd en remplacant : --exec /usr/sbin/slapd -- $SLAPD_OPTIONS 2>&1 dans la fonction start_slapd() par --exec /usr/sbin/slapd -- -h ldap:/// ldaps:/// $SLAPD_OPTIONS 2>&1 " Remarque : Il est impératif que toute requête arrivant sur le serveur soit encapsulée dans un tunnel SSL, ce qui impose soit l utilisation d url ldaps:// (configuration par défaut des clients), soit l utilisation d url ldap:// avec l option -ZZ dans la requête (à éviter) TODO : inclure les modifs proposées dans la section suivante. Inclure tout cela dans un fichier proposé en download... 4.5 Faire en sorte que le serveur ne se lance pas sous root Il est possible de faire ne sorte que le serveur ne soit pas lancer par l utilisateur root mais par un utilisateur dédié, typiquement slapd. En terme de sécurité, c est évidemment nettement mieux car une attaque sur le serveur LDAP fournira en général à l attaquant un accès avec les droits utilisés par le serveur. C est d autant plus intéressant si vous utilisez une Debian stable et que, comme on l a vu, vous devez vous charger personnellement des mises à jour de sécurité ce qui laisse du temps pour l exploitation d attaques sur le serveur! ->TODO détailler les manips et les tester. 4.6 Vérifier que le serveur marche On lance le serveur : /etc/init.d/slapd start (penser à jeter un coup d oeil aux logs en live par un tail -f /var/log/slapd.log sur une autre console par exemple). Les commandes suivantes 14, lancées sous root, doivent rendre un résultat sans erreur : ldapsearch -H "ldap://127.0.0.1" -b "dc=grid5000,dc=net" -x teste une requête non chiffrée sur le port standard 389 ldapsearch -H "ldap://ldap-idpot.clic.id" -b "dc=grid5000,dc=net" -x -ZZ teste une requête chiffrée sur le port standard 389. l option -ZZ montre que StartTLS marche correctement. Le nom spécifié dans l URL (ici, 14 en remplacant ldap-idpot.clic.id par le nom de votre serveur 29

ldap-idpot.clic.id) doit correspondre à celui utilisé dans le certificat du serveur, donc au résultat de la commande hostname -f (voir 3.1.2 page 17) ldapsearch -H "ldaps://ldap-idpot.clic.id" -b "dc=grid5000,dc=net" -x teste une requête chiffrée sur le port standard 636 (ldaps:// est la façon de spécifier l utilisation de SSL). Même remarque que précédemment pour le nom utilisé dans l URL. 30

5 Les principales commandes LDAP 5.1 Lancement du serveur slapd Options Description -h URI list Spécifie la liste des URIs LDAP que le démon slapd devra servir. Exemple typique : ldap:/// (LDAP sur port 389 ; par default), ldaps:/// (LDAP sur SSL on port 636) et ldapi:/// (LDAP sur IPC). -u username Spécifie l utilisateur et le groupe effectif pour slapd -g groupname -d integer Définit le niveau de log -f filename Utiliser le fichier de configuration spécifié Exemple : slapd -u slapd -h ldap :/// ldaps :/// Tab. 7 Principales options disponibles pour slapd Le serveur peut être lancé de deux façons : Soit directement (voir le tableau 7 pour les options possibles) :/usr/sbin/slapd On vérifie que le serveur est bien lancé par ps -ef grep slapd. ATTENTION : pour stopper proprement 15 le serveur lancé de cette façon : > kill -INT cat /var/run/slapd.pid Soit via le script de démarrage :/etc/init.d/slapd <start stop restart> Noter les modifications apportées à ce script au 4.4, page 28. 5.2 Commandes online/offline Offline Online Description slapadd ldapadd Ajout d entrées dans la base LDAP slapcat Utilitaire pour dumper le contenu de la base au format LDIF slappasswd Utilitaire LDAP pour obtenir le chiffrement de mots de passe ldappasswd Changer le mot de passe d une entrée LDAP ldapdelete Suppression d une entrée LDAP ldapmodify Modification d une entrée ldapsearch Recherche dans la base LDAP ldapmodrdn Renommage d une entrée LDAP Tab. 8 Principales commandes online/offline On distingue deux modes de fonctionnement : 1. méthode offline (sans passer par le serveur LDAP) : Dans ce cas, on utilisera la commande slapadd. Ces commandes sont nécessairement tapées 15 Shutting down slapd by more drastic means, such as kill -9, can result in data corruption and should be avoided at all costs. 31

sur le serveur LDAP. 2. méthode online (en passant par le serveur LDAP) : commande ldap* (comme ldapadd, ldapmodify etc...). Ces commandes peuvent êtres utilisées indifférement depuis le serveur ou un client LDAP 16 Le tableau 8 fournit les principales commandes disponibles, selon qu elles soient online ou offline. La plupart des commandes online ont des options communes (qui sont en fait les plus utilisées) qui sont détaillées dans le tableau 9. Options Description -D binddn spécifie le DN utilisé pour la connexion au serveur LDAP -f filename spécifie le fichier LDIF contenant les entrées à utiliser pour l opération -H URI Définit l URI LDAP à utiliser pour la requete de connexion -n ne pas effectuer l opération, juste dire ce qui aurait été fait -v mode verbeux -w password spécifie le mot de passe du DN utilisé pour la connexion -W demande un prompt pour entrer le mot de passe du DN utilisé pour la connexion -x Active la simple authentification et non SASL. en pratique, à ne pas utiliser sans SSL (voir 2.5.1 page 13) -Z[Z] Génère une requête StartTLS. l utilisation de -ZZ impose que cette requête soit réussie. -d integer spécifie les informations de débuggage à afficher (voir tableau 6 page 23) Tab. 9 Principales options communes à ldapsearch, ldapadd, ldapdelete, ldapmodify et ldapmodrdn 5.3 Ajouter des entrées dans la base LDAP Pour ajouter des entrées dans la base : 1. créer un fichier au format LDIF (voir 2.4.3 page 12), par exemple toto_add.ldif, qui contiendra les entrées à ajouter. 2. le plus simple ensuite est d utiliser la méthode offline pour ajouter le contenu du fichier dans la base (cela suppose que le serveur est arrêté) : slapadd -v -l toto_add.ldif l option -v fournit des infos supplémentaires. Pour la méthode online (si le serveur tourne) : (a) Définissez un alias pour éviter de retaper toujours les mêmes options 17 :alias MyLdapadd= ldapadd -W -x -H "ldaps://<votre_serveur>" -D "cn=admin,dc=grid5000,dc=net" 16 sous réserve évidemment que celui-ci soit correctement installé et configuré : voir pour cela la section 7 page 42 17 Il faut vraiment toutes ces options! En particulier, sans l option -W, l authentification de l adminitrateur echouera forcément et la requête deviendra anonyme. Or, un utilisateur anonyme n a pas les droits d écriture dans la base d après les ACLs de slapd.conf ( 4.2.2) et ajout echouera. Voir le tableau 9 pour bien comprendre à quoi chaque option correspond 32

(b) MyLdapadd -v -f toto_add.ldif pour ajouter le contenu du fichier à la base. A noter l existence de l option -c de ldapadd qui permet de continuer malgré les erreurs. Un exemple d ajout a déjà été présenté au 4.3 page 27.Sinon, voici le contenu du fichier toto_add.ldif utilisé en exemple : > cat toto_add.ldif ## Build the toto ou. dn: ou=toto,dc=grid5000,dc=net ou: toto objectclass: organizationalunit En cas de problèmes lors de l ajout simultané de plusieurs entrées (par exemple avec des messages d erreurs comme ldap_add: Invalid syntax et/ou additional info: value contains invalid data), assurez vous que les sauts de lignes ne comportent pas d espace au début de la ligne 18 et que vous incluez les bons schemas dans slapd.conf 5.4 Recherches dans la base LDAP ldapsearch [standard_options] [special_options] [filter] [attrs] le tableau 9 fournis les principales options standards disponibles les options spécifiques de ldapsearch sont fournies dans le tableau 10 le filtre de recherche doit être représenté par une chaine au format spécifié dans [5]. Par défaut, le filtre utilisé est (objectclass=*). si une ou plusieurs entrées sont trouvées, seuls les attributs attrs (tous par défaut) seront affichés sur la sortie standard. Options Description -b basedn définit le DN de base pour la recherche -l limit définit la durée limite (en seconde) pour la recherche -L-LL-LLL le résultat est fournit au format LDIFv1, -LL supprime les commentaires, comme -LLL qui supprime aussi les infos de version -s [sub base one] définit le scope de la recherche. sub (défaut) : recherche dans le sous-arbre de la base base : recherche dans les premier fils de la base one : recherche dans l entrée de base uniquement -S attribut les résultats sont trié selon les valeurs de l attribut -z limit Spécifie le nombre maximal d entrées à renvoyé Tab. 10 Principales options spécifiques de ldapsearch Voici quelques exemples d utilisation, qui illustrent également le fonctionnement des ACLs : 18 utiliser l option set list de vi pour le voir 33

Exemple 1 Voir tout ce que la base contient : ldapsearch -x -b "dc=grid5000,dc=net", identique à : ldapsearch -x -b "dc=grid5000,dc=net" "(objectclass=*)" Exemple 2 Rechercher l organizationalunit toto : ldapsearch -x -b "dc=grid5000,dc=net" "(ou=toto)" Exemple 3 idem que l exemple 2, en ne renvoyant que les attributs ou : ldapsearch -x -b "dc=grid5000,dc=net" "(ou=toto)" ou ATTENTION! Si vous utilisez les ACLs fournies au 4.2.2 page 26 ou le fichier de configuration de l annexe A, les commandes précédentes ne renverront aucun résultat! En effet, avec ces ACLs, comparer les résultats des commandes suivantes 19 : >ldapsearch -x -b "dc=grid5000,dc=net" "ou=toto" -LLL >ldapsearch -x -b "dc=grid5000,dc=net" "ou=toto" -LLL \ -D "cn=nss,dc=grid5000,dc=net" -W Enter LDAP Password: <----- Entrer le mot de passe du DN nss dn: ou=toto,dc=grid5000,dc=net ou: toto objectclass: organizationalunit On obtient un résultat dans le second cas et pas dans le premier. Que s est il passé? Dans le premier cas, la connexion est anonyme et d après l ACL, seul les DN authentifié sont autorisés à accéder au contenu de la base : (clause by * auth; en remplacant cette clause par by * read, vous obtiendriez bien sûr un résultat). En revanche dans le second cas et sous réserve que le bon mot de passe soit entré (sinon, la requête devient anonyme), le DN cn=nss,dc= grid5000,dc=net est authentifié et autorisé en lecture (clause by dn="cn=nss,dc=grid5000,dc=net" read). 5.5 Modifier/Supprimer des entrées dans la base Comme pour l ajout, on passera par un fichier LDIF pour modifier des entrées dans la base. On utilisera ensuite la commande ldapmodify. A noter que comme les fichiers LDIF sont lus séquentiellement, il est possible de modifier des entrées créées plus tôt dans le fichier Dans le fichier, chaque entrée à modifier contiendra un mot clé changetype: <type_modification> qui précisera le type de modification apporté. Les valeurs possibles pour le champ <type modification> sont résumées dans le tableau 11. Je vous conseille de définir un alias pour ldapmodify et les options que vous utiliserez à chaque fois : alias MyLdapmodify= ldapmodify -W -x -H "ldaps://<votre_serveur>" \ -D "cn=admin,dc=grid5000,dc=net" Voici maintenant un exemple suffisamment commenté qui illustre toutes ces possiblitités 19 l option -LLL n est utilisée que pour limiter la taille des résultats en sortie (voir tableau 10) 34

add ajouter l entrée dans l annuaire (choix par défaut) delete supprimer l entrée de l annuaire modify modifier les attributs de l entrée. On peut ainsi à la fois ajouter, modifier ou supprimer des attributs modrdn changer le RDN (Voir tableau 1 page 11) de l entrée moddn changer le DN de l entrée Tab. 11 Valeurs possibles pour le mot clé changetype > cat toto_modify.ldif ## Add an organization tata under toto. dn: o=tata,ou=toto,dc=grid5000,dc=net changetype: add o: tata objectclass: organization ## Add a new attribute description to o=tata dn: o=tata,ou=toto,dc=grid5000,dc=net changetype: modify add: description description: ajout d une description ## Change the value of attribute description for o=tata dn: o=tata,ou=toto,dc=grid5000,dc=net changetype: modify replace: description description: j ai modifie la description ## Delete the attribute description for o=tata dn: o=tata,ou=toto,dc=grid5000,dc=net changetype: modify delete: description ## Change the rdn of tata to turlututu dn: o=tata,ou=toto,dc=grid5000,dc=net changetype: modrdn newrdn: o=turlututu ## Change the dn of o=turlututu to o=leon and # move the entry at the same level than ou=toto dn: o=turlututu,ou=toto,dc=grid5000,dc=net changetype: moddn # create the new name (RDN) newrdn: o=leon # deletes old entry (0 to keep the current entry) deleteoldrdn: 1 35

# adds to grid5000 hierarchy newsuperior: dc=grid5000,dc=net On exécute ce fichier par l appel MyLdapmodify -f toto_modify.ldif Remarques : pour supprimer une entrée, on aurait aussi pu utiliser la commande : ldapdelete [standard_options] [-r] <dn_to_delete> Les options standards sont celles spécifiées dans le tableau 9 page 32. L option -r précise que la suppression est récursive (tous les noeuds fils de <dn to delete> seront aussi supprimés). pour toutes les modifications relatives au DN et au RDN, on peut aussi utiliser la commande : ldapmodrdn [standard_options] [-c] [-r] [-s superior_node] <dn> <new_rdn> L option -c permet de continuer malgré les erreurs. -r permet de supprimer l ancienne entrée (qui est conservée par défaut). Enfin, l option -s permet de préciser l entrée sous laquelle se greffera cette nouvelle entrée. 5.6 Quelques outils graphiques On l aura compris, la manipulation de fichiers LDIF n est pas forcément aisée. Voici quelques pointeurs vers des outils graphiques (pas encore testés) : GQ (http://biot.com/gq/) Java LDAP Browser/Editor (http://www.iit.edu/~gawojar/ldap/) Softerra LDAP Browser (http://www.ldapbrowser.com/) 36

6 Gestion des fichiers de configurations par LDAP A ce stade du tutorial, nous disposons d un serveur opérationnel que nous interrogeons de manière sécurisée. Mais la base de données LDAP est vide. Dans le cadre expérimental de ce document, nous souhaitons déleguer la gestion des comptes machines et de l authentification des utilisateurs au service d annuaire LDAP. Cela suppose en particulier que la base LDAP puisse fournir le contenu de fichiers de configurations systèmes tels que /etc/passwd, /etc/shadow, /etc/ group, /etc/hosts ou encore /etc/auto.home (ce dernier fichier localisant pour autofs les points de montages des répertoires home de chaque utilisateur). Sur un réseau ouvert, on trouve en général un ou plusieurs serveurs NIS[7] qui stockent et diffusent ces fichiers de configuration aux clients du réseau. Cette solution présente ce nombreux avantages : centralisation les informations (ce qui en facilite la maintenance) relative transparence d utilisation coté client. Cependant, NIS ne passe pas à l échelle et la solution la plus adaptée et la plus robuste pour remplacer NIS nous a sembler être LDAP. Nous allons voir dans cette section comment migrer le contenu des fichiers de configuration systèmes au format LDIF pour les intégrer dans la base LDAP selon un schéma standard. Nous verrons ensuite dans la section 7, page 42) l installation et la configuration des machines clientes pour une gestion transparente de ces fichiers. 6.1 Les outils de migration des fichiers de configuration On utilise les scripts de migrations développés par www.padl.com. 6.1.1 Installation Cas Debian stable : Le package Debian stable (version 40-1) est buggé et il est donc conseillé : 1. soit d installer la version testing du package (version 45-1) : apt-get install -t testing migrationtools 2. soit de récupérer directement les script à l adresse http://www.padl. com/download/migrationtools.tgz (version 45 au moment où ce document est écrit). Par cohérence avec la suite, nous supposons qu une fois l archive décompressée, les scripts qu elle contient seront placés au même endroit que ceux du package (/usr/share/migrationtools/). Autres cas : apt-get install migrationtools Les scripts seront placés dans le répertoire /usr/share/migrationtools TODO : voir pour les autres distrib 6.1.2 Configuration Dans le fichier /etc/migrationtools/migrate_common.ph, on modifie certaines variables : 37

# Default DNS domain $DEFAULT_MAIL_DOMAIN = "grid5000.net"; # Default base $DEFAULT_BASE = "dc=grid5000,dc=net"; La variable $DEFAULT BASE correspond à la base de l annuaire où sera stocké le contenu des fichiers. La valeur ci-dessus correspond à l architecture exposée dans la figure 5, page 20. Dans le cadre de la seconde experimentation présentée au 8.2, il faudra placer cette variable à la valeur o=<ma_ville>,dc=grid5000, dc=net. Dans les outils de migration, il y a plusieurs scripts permettant de transformer chaque fichier système au format LDIF. Les informations de chaque fichier sont sauvées dans des OrganizationalUnits (OU) différentes 20 : /etc/fstab ou=mounts /etc/hosts ou=hosts /etc/passwd et /etc/shadow ou=people /etc/group ou=group /etc/protocols ou=protocols /etc/rpc ou=rpc /etc/services ou=services /etc/networks ou=networks netgroups ou=netgroups Il faut créer ces OU sur le serveur. Pour cela, utiliser le scriptmigrate_base.pl : cd /usr/share/migrationtools./migrate_base.pl > /tmp/init_base_migration.ldif Il faut supprimer la première entrée du fichier/tmp/init_base_migration.ldif (qui créer l entrée correspondant à la base). Ensuite, retirer éventuellement les entrées dont vous ne vous servirez pas. On obtient dans notre cas : > cat /tmp/init_base_migration.ldif dn: ou=people,dc=grid5000,dc=net ou: People objectclass: top objectclass: organizationalunit dn: ou=group,dc=grid5000,dc=net ou: Group objectclass: top objectclass: organizationalunit dn: ou=hosts,dc=grid5000,dc=net ou: Hosts objectclass: top objectclass: organizationalunit 20 on verra au 6.3 où les fichiers de configuration de autofs seront gérés 38

Rapatrier éventuellement ce fichier sur votre serveur LDAP et ajouter son contenu à la base : # /etc/init.d/slapd stop Stopping OpenLDAP: slapd. # slapadd -v -l /tmp/init_base_migration.ldif added: "ou=people,dc=grid5000,dc=net" (0000000b) added: "ou=group,dc=grid5000,dc=net" (0000000c) added: "ou=hosts,dc=grid5000,dc=net" (0000000d) 6.2 Migration les fichier passwd, group et hosts 6.2.1 Recupération du contenu des tables NIS En effet, si ce sont les fichiers diffusés par NIS que vous souhaitez migrer (comme c est le cas dans le cadre de cette expérimentation), il faut déjà récupérer le contenu de ces fichiers. Pour cela, on exécute les commandes suivantes sur la machine cliente configurée avec NIS 21 : ypcat passwd > /tmp/nis_passwd ypcat group > /tmp/nis-group ypcat hosts > /tmp/nis_hosts et on transfère ces fichiers sur le serveur via scp : scp /tmp/nis_* root@<votre_serveur>:/tmp/ 6.2.2 Conversion au format LDIF cd /usr/share/migrationtools/./migrate_passwd.pl /tmp/nis_passwd /tmp/ldap_passwd.ldif./migrate_group.pl /tmp/nis_group /tmp/ldap_group.ldif./migrate_hosts.pl /tmp/nis_hosts /tmp/ldap_hosts.ldif Vous aurez compris que le format d utilisation des scripts est le suivant : migrate_<file> <file> <output_file>.ldif Vérifier que les fichiers générés ont un format correct (c est comme ça que j ai détecté le bug des packages stables) 6.2.3 Insertion dans la base LDAP En supposant que le serveur soit toujours arrêté : slapadd -v -c -l /tmp/ldap_passwd.ldif slapadd -v -c -l /tmp/ldap_group.ldif slapadd -v -c -l /tmp/ldap_hosts.ldif Attention! L option -c permet de continuer malgré les erreurs, qui sont dont plus difficiles à tracer. 21 il n y a avait pas dans notre cas de map shadow 39

6.3 Migration des fichiers de configuration d automount automount est un démon qui automatise le montage (et le démontage) de certains systèmes de fichiers. Si le système de fichiers n est pas monté (par exemple, un CD), et qu un utilisateur essaye d y accéder, il sera automatiquement (re)monté (en particulier, l utilisateur en question n aura pas a utiliser la commande mount). autofs contrôle les opérations du démon automount par le biais de fichiers de configuration, constitués du fichier /etc/auto.master, qui contient les points de montage et d un fichier par point de montage (typiquement/etc/auto.misc ou /etc/auto.home), détaillant les options systèmes de celui-ci. Pour plus de détails, voir [14]. Dans le cadre de notre expérience, le serveur NIS diffuse une map, /etc/auto. home, qui permettait de monter automatiquement le répertoire home de chaque utilisateur. Cette section montre comment intégrer le contenu de ces fichiers dans une base LDAP. Nous supposerons que le fichier principal /etc/auto.master restera local et propre à chaque machine cliente (nous verrons en 7.3 les modifications qu il faudra lui apporter). 6.3.1 Installation du package autofs-ldap Sur le serveur : apt-get install autofs-ldap Le package fournit notamment un nouveau schéma automount.schema et la librairie lookup_ldap.so Attention! lorsque j ai installé le package, le fichier automount.schema n a pas été installé. Le bug a été signalé mais en attendant, le contenu de ce fichier est fourni dans l annexe E page 61. Il suffit de copier ce fichier dans /etc/ldap/schema/automount.schema. Ensuite, on décommente dans le fichier de configuration slapd.conf (qui a été fourni en annexe A) la ligne : include /etc/ldap/schema/automount.schema 6.3.2 Migration du fichier /etc/auto.home En regardant les tables montées avec NIS initialement : > cat /etc/auto.master /var/autofs/misc #/var/autofs/net /home/nis /etc/auto.misc --timeout=3 /etc/auto.net auto.home On voit que seul le fichier auto.home était récupéré par NIS. On récupère son contenu : 40

> ypcat auto.home -rw,nfs,hard,intr,nosuid,rsize=8192,wsize=8192,retrans=6 \ serveur.clic.id:/home/nis/& On voit que dans notre cas particulier, on aura à traiter un mapping générique (le format de ce fichier n est pas de la forme classique (voir man 5 autofs ) : key [-options] location La démarche pour ajouter ce fichier dans la base LDAP a été la suivante : 1. Création du fichier des entrées LDIF à la main (ne PAS utiliser les scripts de migration!) : > cat /tmp/auto.home.ldif # This entry is more or less a place-holder for automount # entries for directories which get mounted under /home/nis. dn: ou=auto.home,dc=grid5000,dc=net objectclass: top objectclass: organizationalunit ou: auto.home # This is a wildcard entry for any user whose home directory # is under /home/nis. dn: cn=/,ou=auto.home,dc=grid5000,dc=net objectclass: top objectclass: automount description: generic home directory automountinformation: -rw,nfs,hard,intr,nosuid,rsize=8192,\ wsize=8192,retrans=6 serveur.clic.id:/home/nis/& cn: / (penser a enlever le retour \ de l avant-dernière ligne) TODO : donner exemple dans le cas d un mapping classique. 2. Ajout de ce fichier dans la base LDAP : slapadd -v -l /tmp/auto.home.ldif 3. Coté client, modification du fichier /etc/auto.master comme exposé au 7.3. 41

7 Installation du client LDAP A ce niveau, nous disposons d un serveur LDAP qui fonctionne et qui contient toutes les informations dont les machines clientes auront besoin. Cette section détaille l installation d un poste client et se découpe en plusieurs parties : 1. installation et configuration de base pour permettre l interrogation du serveur LDAP à distance ( 7.1) 2. installation et configuration de l authentification des utilisateurs via LDAP. Sous Linux, cette authentification se fait via deux outils que sont NSS (Name Service Switch) et PAM (Pluggable Authentication Module). ( 7.2) 3. modification de auto.master pour prendre en compte la gestion de certaines maps autofs par le serveur LDAP ( 7.3). A l issue de ces trois étapes, la machine cliente sera complètement configurée et fonctionnelle. 7.1 Initialisation et configuration de base du client 7.1.1 Cas d une installation sur une Debian stable Comme pour l installation du serveur (voir 3.2.1), il y a normalement une petite manipulation à faire pour que SSL soit supporté. Cependant, malgré toutes mes tentatives, je n ai pas réussi à faire fonctionner SSL/TLS avec le package stable ldap-utils (alors que j avais bien reconstruit le package avec l option--with-tls). Il semble en effet que cette version (2.0.23-6.3) de ldap-utils ne gère pas les options SSL (elle ne figurent même pas dans le man). C est pourquoi la seule solution (facilitant aussi le travail de mise à jour automatique des package au niveau client) est de forcer l installation en testing (avec tous les inconvénients que cela comporte, notamment la mise à jour de la libc6) : > apt-get install -t testing ldap-utils > apt-get install openssl 7.1.2 Autres cas Il n y a pas de problèmes (SSL est supporté directement) et il suffit de taper : apt-get install ldap-utils openssl 7.1.3 Dans tous les cas... Le fichier de configuration, /etc/ldap/ldap.conf est fourni dans l annexe B page 57. Faites une sauvegarde de ce fichier avant de l écraser : cp /etc/ldap/ldap.conf /etc/ldap/ldap.conf_deb-orig Voici les principales options disponibles : BASE <base> le DN de base à utiliser pour les recherches. Ici, dc=grid5000,dc=net 42

URI <url serveur> l url permettant permttant d interroger le serveur. Le nom du serveur spécifié dans l url doit être connu sans passer par le DNS du réseau 22. On précisera donc soit une adresse IP, soit un nom dont la correspondance en adresse IP figure dans le fichier local /etc/hosts. Dans notre cas, un aura : URI ldaps://ldap-idpot.clic.id Ainsi, toutes les requêtes clientes soient encapsulées dans un tunnel SSL. SIZELIMIT <integer> nombre maximal de réponses aux requêtes autorisé. (0 pour qu il n y ait pas de limite) TIMELIMIT <integer> délai maximal de recherche. BINDDN <dn> Contrairement à ce qu on pourrait penser, cette directive n est pas supportée par ldap.conf 23! C est là qu on devrait préciser que ce sera le DN cn=nss,dc=grid5000,dc=net qui aura accès à la base (c est l utilisateur spécial créé au 4.3 à cet effet). De toute façon, la directive BINDPW (qui précise le mot de passe de binddn) n est supportée ni par ldap.conf, ni par.ldaprc. TLS CACERT <filename> : spécifie le fichier qui contient tous les certificats des CA dans lesquel le client aura confiance. Dans notre cas, on aura : TLS_CACERT /etc/ldap/ca-cert.pem N oubliez pas de copier le certificat du CA et le placer dans /etc/ldap/ca-cert.pem 7.1.4 Vérifier que ça marche 1. On vérifie déjà qu un tunnel SSL peut effectivement être mis en place avec le serveur : openssl s_client -connect <your_serveur>:636 -showcerts \ -state -CAfile /etc/ldap/ca-cert.pem (quitter avec un CTRL-C) Vous devez avoir à la fin un message du style Verify return code: 0 (ok) 2. ldapsearch -x ne doit pas retourner d erreur (mais ne doit pas renvoyer d entrées compte tenu des ACLs) 3. ldapsearch -x -D "cn=nss,dc=grid5000,dc=net" -W doit vous renvoyer toutes les entrées de la base 4. on vérifie enfin que les communications sont bien chiffrées. Pour cela, on ouvre deux consoles sur la machine cliente. (a) test non chiffré : sur la première console : tcpdump -l -X port 389 grep dc Et sur la seconde : ldapsearch -x -H "ldap://<votre_serveur>". Si vous revenez sur la première console, vous verrez alors : 22 pour éviter qu un souci au niveau DNS empêche l accès au serveur 23 elle peut seulement être utilisée dans le fichier.ldaprc propre à chaque utilisateur 43

tcpdump: listening on eth0 0x0030 [...]...07...c2..dc= 0x0040 [...] grid5000,dc=net. Il y a donc bien une partie en texte clair. (b) test chiffré : tout est fait pour que, par défaut, les communications entre le client et le serveur soient chiffrées. On le vérifie en lancant sur la première console : tcpdump -X port 636 et sur la seconde, ldapsearch -x. Cette fois ci, parmi toutes les informations renvoyées, on vérifie qu il n y a plus de texte clair qui apparait. On peut renouveler cette expérience en utilisant une commande renvoyant plus de résultats, comme : ldapsearch -x -D "cn=nss,dc=grid5000,dc=net" -W (on ajoute l option -H "ldap://<votre_serveur>" pour passer en mode non chiffré). Remarque : Il est peut-être bon de rappeler également que pratiquement toutes les commandes LDAP bénéficie de l option -d <int> qui spécifie le niveau des informations des informations de debuggage (voir 6 page 23). Cela peut être utile pour le debuggage. 7.2 Authentification des utilisateurs via LDAP l authentification système par LDAP permet d unifier les bases de données utilisateur. De plus le système de répartition et de réplication procure une meilleure tolérance aux pannes. Enfin d autres services peuvent tirer partie de cette base commune d authentification. Sous Linux, l authentification d un utilisateur utilise deux composants : 1. le système PAM (Pluggable Authentication Module, voir 7.2.2) qui permet l intégration transparente de diverses technologies d authentification comme le standard UNIX (utilisant crypt), RSA, DCE, LDAP etc... sur des services du sytème comme login, passwd, rlogin, su, ftp, ssh etc. sans aucune modification sur ces services. Si au départ PAM n était implémenté que sous Solaris, c est aujourd hui un standard d authentification sur de nombreuses distributions Linux (Redhat, Debian etc...) PAM fournit une API par laquelle les requêtes d authentitification sont mappées sur des actions spécifiques aux technologies (et qui sont implémentées dans des modules PAM ). Ce mapping est fait par les fichiers de configuration PAM dans lesquels on spécifie pour chaque service les mécanismes d authentification utilisables. Dans notre cas, le module pam ldap, implémenté dans la librairie partagée pam_ldap.so, permet aux utilisateurs et aux groupes de s authentifier à l aide du service LDAP. Il suffira de le préciser dans les fichiers de configuration PAM. 44

2. le système NSS (Name Service Switch, voir 7.2.1) : une fois l utilisateur authentifié, de nombreuses applications ont toujours besoin d accéder aux informations relatives à cet utilisateur. Cette information est traditionnellement contenue dans des fichiers textes (/etc/passwd, /etc/shadow, /etc/group etc... Mais elle peuvent également être fournies par un service de nommage (comme NIS ou DNS). Lorsqu un nouveau nouveau service de nommage (comme LDAP) est introduit, il peut être implémenté soit dans une librairie C (comme c est le cas pour NIS ou DNS) ou au sein de l application qui utilisera ce service de nommage. Mais cela peut être éviter en utilisant une API commune et générale dédiée au service de nommage qui réalise une couche intermédiaire entre une application et un ensemble de services de nommage. C est ainsi que fut implémenté le Name Service Switch qui permet d obtenir des informations de nombreux services de nommage à travers une API commune. NSS utilise un fichier de configuration /etc/nsswith.conf dans lequel sont précisés les services de nommage à utiliser pour tel ou tel information (comme la base passwd, shadow, group ou encore hosts...) Ainsi, à partir de la librairie partagé nss_ldap.so, il est possible de récupérer ces informations en utilisant LDAP. On commencera par l installation de nss ldap car c est celle qui est la moins dangeureuse des deux : de mauvaises manipulations avec PAM peuvent casser le système complet!! 7.2.1 NSS (Name Service Switch) et LDAP Cas Debian stable Comme d habitude, on peut faire la manip pour permettre l utilisation de SSL : > cd; mkdir libnss-ldap_stable-source > cd libnss-ldap_stable-source/ > apt-get source libnss-ldap > cd libnss-ldap-186/ > vim debian/rules --> remplacer --disable-ssl par --enable-ssl >./debian/rules binary --> j ai eu un problème (puis normalement) > dpkg -i libnss-ldap_186-1_i386.deb Mais je n ai pas réussi à lancer la compilation (un problème dans le script rules apparemment 24 ). Et surtout, on a déjà forcé l installation de ldap-utils en testing, alors autant continuer, ca facilitera la mise à jour : apt-get install -t testing libnss-ldap 24 make : dh_testdir : Command not found Ce problème se résoud en installant le package debhelper mais on a alors un autre erreur : configure : error : could not locate <ldap.h>. Je n ai pas cherché plus loin (mais je suppose qu il faut installer libldap2-devel)... 45

Autres cas Un simple apt-get install libnss-ldap suffira. Debconf va vous poser une série de questions : 1. LDAP server host adress : mettez le nom du serveur LDAP (qui figure dans son certificat et dans /etc/hosts) 2. distinguished name of the search base : dc=grid5000,dc=net 3. LDAP version to use : 3 4. database requires login : yes 5. file permission : 0600 6. unprivileged database user : cn=nss,dc=grid5000,dc=net 7. password for database login account : entrer celui correspondant au DN cn=nss,dc=grid5000,dc=net. Configuration de libnss-ldap Le fichier de configuration est/etc/libnss-ldap.conf. Faites en une sauvegarde : > cp /etc/libnss-ldap.conf /etc/libnss-ldap.conf.old il convient d y ajouter la ligne uri ldaps://<votre_serveur>. Pour les plus pressés, ce fichier est fourni en annexe C.1 page 58 (penser à y mettre le mot de passe du DN cn=nss,dc=grid5000,dc=net et à y spécifier votre serveur). Il est primordial que ce fichier de configuration bénéficie de droits d accès 0600!!! (il contient le mot de passe en clair du DN spécial nss...) Ensuite, on retouche au fichier de NSS /etc/nsswitch.conf. On commence par une copie de sauvegarde : > cp /etc/nsswitch.conf /etc/nsswitch.conf.old Et on transforme les lignes suivantes : passwd: group: shadow: hosts: en compat compat compat files dns ## Define the order of lookups for users and groups. passwd: files ldap shadow: files ldap group: files ldap hosts: files ldap dns Toujours pour les plus pressés, le fichier /etc/nsswitch.conf est fourni en annexe C.2 page 58. Pour vérifier que ça marche... lancer le serveur : /etc/init.d/slapd restart (sur votre serveur) getent passwd sur le poste client devrait vous renvoyé le contenu de /etc/ passwd compléter avec les entrées du serveur LDAP (il faut peut-etre enlever l entrée + : : : : : : de /etc/passwd etc... pour que ca marche correctement.) 46

de façon similaire, tester les appels getent group et getent shadow (éventuellement) et getent hosts. Vous pouvez normalement vous logguer directement comme utilisateur non local mais géré par les maps LDAP (bien que vous n aurez pas de home monté) Optimisations de recherches possibles... Comme les users et les groups sont stockés dans des OU (OrganizationalUnit) différentes, on peut optimiser les recherches en ajoutant dans /etc/libnss-ldap.conf (c est déjà fait dans le fichier fourni) : ## Optimize the nss_ldap searches for these databases. # Syntax: # nss_base_xxx base?scope?filter nss_base_passwd ou=people,dc=grid5000,dc=net?one nss_base_shadow ou=people,dc=grid5000,dc=net?one nss_base_group ou=group,dc=grid5000,dc=net?one nss_base_hosts ou=hosts,dc=grid5000,dc=net?one 7.2.2 PAM (Pluggable Authentication Module) et LDAP Il est peut-être bon de le répeter : de mauvaises manipulations avec PAM peuvent casser le système complet!! Note sur les changements de mots de passe. On peut envisager deux mode de fonctionnement pour les postes clients, chacun ayant un impact sur la sécurité globale du système différent : 1. comportement similaire à une gestion locale, où le root local de chaque machine peut notamment changer les mots de passe. Pour cela, il faut que le fichier de configuration précise le DN ayant l accès en écriture sur la base LDAP (directive rootbinddn) et surtout son mot de passe (qui sera en pratique stocké dans le fichier /etc/ldap.secret). Malheureusement, ce mot de passe (comme celui figurant dans la directivebindpw) ne peut figurer qu en clair (et non sous forme hachée). Cela définit bien évidemment un considérable problème de sécurité puisque malgré un droit d accès qui doit être restreint à l utilisateur root pour le fichier /etc/ldap.secret (droit 0600), tout utilisateur ayant les droits root sur une machine cliente (ce que tout utilisateur peut faire très facilement à partir de n importe quel CD bootable par exemple (cf par exemple la distribution Knoppix)) aura accès au mot de passe root de la base LDAP, pourra modifier les entrées etc... Cela est évidemment inacceptable dans le cadre d un cluster, et notamment dans le cadre du projet Grid5000 où il convient de limiter au maximum les droits des clients sur la base LDAP. 2. configuration sans réel root local : dans ce cas, tout utilisateur local (y compris root) ne pourra changer d entrées de la base LDAP (en particulier les mots de passe gérés par LDAP). Ainsi, il n y aura pas besoin de stocker le mot de passe du DN administrateur de la base LDAP. En contrepartie, tout changement de mot de passe devra se faire directement sur le serveur 47

LDAP via l administrateur (physique) de cette machine. C est la solution que nous avons retenus pour le projet Grid5000. Installation Comme toujours, même si vous êtes en Debian stable, je vous conseille de forcer l install en testing : apt-get install -t testing libpam-ldap. Dans les autres cas, un simple apt-get install libpam-ldap suffira. Debconf va vous poser une série de questions : 1. Make local root Database admin : no (voir remarque plus haut) 2. Database requires logging in : yes 3. Unprivileged database user : cn=nss,dc=grid5000,dc=net 4. Password for the login account. : entrer celui correspondant au DN cn= nss,dc=grid5000,dc=net. 5. Local crypt to use when changing passwords. :crypt Configuration Le fichier de configuration est /etc/pam_ldap.conf. Il est très similaire à /etc/libnss-ldap.conf (et utilise quasiment les même directives) Faites une copie de sauvegarde : cp /etc/pam_ldap.conf /etc/pam_ldap.conf.old Ce fichier est également fourni en annexe D.1 page 59. Maintenant que le module PAM LDAP est installé, il faut l inclure dans les processus PAM. Nous allons voir dans le paragraphe qui suit les modifications a apporter pour permttre le login via ssh. Remarque : La plupart des applications compatibles PAM sont gérés via des fichiers de configuration qui leurs sont propres. Sous Debian, ces fichiers sont stockés dans /etc/pam.d/. Configuration de /etc/pam.d/ssh Le fichier de configuration PAM pour ssh est /etc/pam.d/ssh. Il est fourni en annexe D.2 page 59. Par rapport au fichier original, les changements suivants ont été opéré : addition des lignes contenant pam_ldap.so reordonnancement des lignes auth (puisque dès que pam ldap authentifie un utilisateur, aucune autre ligne auth ne sera utilisé compte tenu de l attribut sufficient (on ne peut pas utiliser l attribut required ici puisqu on veut utiliser le module pam unix en cas d échec d authentification par pam ldap, ce qui peut se produire si le serveur LDAP est inaccessible). la section session doit également être réordonnée. Il est important ensuite de relancer le serveur ssh!!!! Configuration de /etc/pam.d/su Un autre exemple est celui de la configuration de su. /etc/pam.d/su est lui aussi fourni en annexe D.3 page 60. Autres configurations Il faut retoucher aux fichiers /etc/pam.d/common-* 48

Note à propos de la distinction des fichiers de configuration On peut se demander pourquoi Debian a choisi de distinguer les fichiers de configuration ldap.conf, libnss-ldap.conf et pam_ldap.conf (ce n est pas le cas il semblerait sous RedHat par exemple). La meilleure réponse que l on puisse apporter est qu on peut très bien avoir plusieurs serveur LDAP ayant chacun un rôle précis (un serveur d authentification, un annuaire utilisateur etc...). Séparer les fichier assure la modularité dans les choix de configuration. 7.3 Configuration automount : le fichier auto.master On a vu au 6.3 comment exporter la map auto.home initialement gérée par NIS. Maintenant, il faut préciser a l automount des machines clientes que cette map est maintenant gérée par LDAP. Pour cela, on effectue les modifications suivantes au fichier /etc/auto.master (on a commenté l ancienne ligne) : > cat /etc/auto.master grep home #/home/nis auto.home /home/nis ldap:ldap-idpot:nismapname=auto_home,dc=grid5000,dc=net \ --timeout 60 7.4 Utilisation de NSCD Pour éviter que chaque machine interroge le serveur LDAP chaque fois qu une commande ls -l est effectuée, il est préférable de configurer les stations de travail pour placer des informations utilisateur en cache. Tant que des données en cache sont fraîches, la station de travail utilisera ce cache au lieu d interroger à nouveau le serveur LDAP. Cette tâche est réalisée en pratique par le name server caching daemon (nscd). Pour l installation : apt-get install nscd Le fichier de configuration pour nscd est/etc/nscd.conf : enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes 49

8 Evolution au sein du projet Grid5000 8.1 Première experimentation : configuration locale 8.1.1 Contexte Ce expérience s est déroulée au sein du cluster IDPOT de Grenoble. Dans cette premère expérience, la racine choisie est dc=grid5000,dc=net. Les données sont organisées selon le schéma exposé dans la figure 6, 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. 6 Architecture de la première expérience Grid5000 sur Grenoble 8.1.2 Description Sur le serveur LDAP (ldap-idpot.clic.id) les anciennes tables NIS complétant les utilisateurs ( /etc/passwd ), les groupes ( /etc/group ), le fichier /etc/hosts ou gérant les tables automount ( auto.home ) ont été exportées. Une machine cliente typique ( idpot8.clic.id ) a également été configurée. Toutes ce qui y était initialement géré par NIS l est maintenant par le serveur LDAP. Coté utilisateur, tout est transparent : il se logue comme d habitude sur cette machine avec son login/passwd fournit lors de la création de son compte sur le cluster et son home est monté automatiquement à sa connexion. Les communications LDAP entre la machine cliente idpot8 et le serveur LDAP, en particulier lors d une ouverture de session par un utilisateur, sont sécurisées par une connexion TLS/SSL (utilisant le port par défaut (636)). 8.1.3 Contribution des autres sites (une fois le pb de /etc/ldap.secret réglé) Les autres sites peuvent éventuellement configurer leurs machines clientes pour venir utiliser les données du serveur LDAP ldap-idpot.clic.id afin de compléter leurs propres entrées NIS. Pour cela, il leur faut : 1. tester l accessibilité au serveur ldap-idpot.clic.id (contacter Julien. Leduc@imag.fr en cas de problème) 2. installer les packages client ldap et les configurer (voir 7) 3. sauvegarder le fichier/etc/nsswitch.conf(en\etc/nsswitch.conf.withoutdalp par exemple) 4. lui apporter les modifications suivantes : 50

en passwd: group: shadow: hosts: passwd: shadow: group: hosts: compat compat compat files dns files nis ldap files nis ldap files nis ldap files nis ldap dns 5. (eventuellement) gerer auto.home via LDAP : voir?? 6. Vérifier que c est bien pris en compte coté utilisateur : getent passwd 8.2 Seconde expérimentation : utilisation des referrals Dans cette expérience, il s agit d experimenter une architecture totalement hiérarchique (voir figure 7). root ldap.grid5000.org Referral dc=grid5000,dc=org o=nice o=grenoble ldap nice.grid5000.org ldap grenoble.grid5000.org Nice Grenoble o=nice,dc=grid5000,dc=net o=grenoble,dc=grid5000,dc=net ou=people (/etc/passwd) ou=group (/etc/group) ou=hosts (/etc/hosts) ou=auto.home (/etc/auto.home) ou=people (/etc/passwd) ou=group (/etc/group) ou=hosts (/etc/hosts) ou=auto.home (/etc/auto.home) Fig. 7 Architecture envisagée de la Seconde expérience Grid5000 - modèle distribué totalement hiérarchique Cette expérience est en cours. Chaque site gère donc son propre domaine et est configuré pour renvoyer un referral vers un serveur racine s il ne sait pas répondre. Plusieurs problèmes à résoudre : 1. le client doit réemettre une requete après réception d un referral. Or pour éviter tout goulet d etranglement au niveau du serveur racine, les clients d un site A seront configurer pour intérroger le serveur associé au site A. S il réemet sa requete (par exemple pour trouver le password de l utilisateur svarrett), le serveur racine recherche dans tous ses fils? Car on 51

pourrait peut-être envisager de l empecher d interroger le serveur du site A puisque a priori, il n a pas su répondre? 2. Y a t il une configuration optimisée pour le client (cf directives nss_* de ldap.conf? 3. comment s effectue la recherche d un mot de passe dans l arbre dans la version standard de nss ldap? Je m explique : Considérons un client sur le site A, géré par le serveur ldap-a. Si celle-ci que ds le sous arbre spécifier dans ldap.conf 4. Peut-être doit on tester d abord une architecture distribué mais plate comme celle exposée dans la figure 8? ldap grenoble.grid5000.org Grenoble dc=grid5000,dc=org Referral o=nice o=grenoble ou=people (/etc/passwd) ou=group (/etc/group) ou=hosts (/etc/hosts) ou=auto.home (/etc/auto.home) ldap nice.grid5000.org dc=grid5000,dc=org Nice o=nice o=grenoble ou=people (/etc/passwd) ou=group (/etc/group) ou=hosts (/etc/hosts) ou=auto.home (/etc/auto.home) Fig. 8 Architecture envisagée de la Seconde expérience Grid5000 - modèle distribué mais plat 9 Quelques liens utiles En plus de la bibliographie (détaillée à la fin de ce document), vous trouverez ici une liste non exhaustive de liens fournissant de nombreuses informations en complément à tout ce qui a été exposé dans ce document. Un livre qui m a beaucoup aidé : [1]. Le guide officiel pour l installation d un serveur OpenLDAP [2] : OpenLDAP 2.2 Administrator s Guide, http://www.openldap.org/doc/admin22/ un très bon tutorial qui montre comment faire collaborer OpenLDAP, OpenSSL, Kerberos et SASL, par Turbo Fredriksson. http://www.bayour.com/ldapv3-howto.html#4.3.2.installing%20mit%20kerberos% 20V outline Quelques notes sur l installation de OpenLDAP : http://howto.aphroland.de/howto/ldap/frontpage 52

Un excellent tutorial, intitulé Using OpenLDAP on Debian Woody to serve Linux and Samba users, par Markus Amersdorfer, très complet et dédié à l installation sous Debian stable. http://aqua.subnet.at/~max/ldap/ Un guide rapide mais exhaustif (initialement en japonais) sur LDAPv3 sous Debian : http://www.tom.sfc.keio.ac.jp/~torry/ldap/ldap_en.html Les notes d installation et de configuration de LDAP à l INT evry, par Jehan Procaccia. http://www.int-evry.fr/mci/user/procacci/ldap/. un excellent tutorial (un peu ancien) sur les concepts liés à LDAP, par Laurent Mirtain. http://www-sop.inria.fr/semir/personnel/laurent.mirtain/ ldap-livre.html une page qui recense un certain nombre de liens vers LDAP (dans les discussion qui suivent l article, on trouvera encore plus de liens fournis par les visiteurs du site). http://linuxfr.org/2003/03/10/11659.html Notes sur la mise en place d un agenda via LDAP et de l authentification LDAP pour votre Linux. http://www.xenux.net/?article=22 installation et configuration LDAP sous Mandrake, avce quelques notes : http://www.mandrakesecure.net/en/docs/ldap-auth.php le Howto officiel : [9]. http://www.tldp.org/howto/ldap-howto/ un autre howto, un peu moins complet : http://sapiens.wustl.edu/~sysmain/info/openldap/ un tutorial sur Openldap and Debian Stable, pas très complet mais intéressant : http://wiki.osuosl.org/display/lnx/openldap+and+debian+stable La distribution perl-ldap, fournissant un ensemble de modules Perl permettant d interfacer un serveur LDAP. http://ldap.perl.org/. Voir aussi l annexe G page 63. 53

Annexes 54

A Fichier de configuration slapd.conf # This is the main sdapd configuration file. See slapd.conf(5) for more # info on the configuration options. ##################################### # Global Section ##################################### # Schema and objectclass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema # automount.schema is not provided by default # It is used to store autofs informations (package autofs-ldap). #include /etc/ldap/schema/automount.schema ## Added logging parameters, read slapd.conf(5) for possible values loglevel 296 ## Added execution control # force entries to match schemas for their objectclasses s schemacheck on pidfile /var/run/slapd.pid argsfile /var/run/slapd.args # Where to store the replica logs replogfile /var/lib/ldap/replog ## TLS options for slapd TLSCipherSuite HIGH TLSCACertificateFile /etc/ldap/certificate/ca-cert.pem TLSCertificateFile /etc/ldap/certificate/ldapserver-cert.pem TLSCertificateKeyFile /etc/ldap/certificate/ldapserver-key.pem # Misc security settings password-hash {SSHA} ####################################################################### # ldbm database definitions ####################################################################### # The backend type, ldbm, is the default standard database ldbm # The base of your directory suffix "dc=grid5000,dc=net" # Define a root DN for superuser privileges. rootdn "cn=admin,dc=grid5000,dc=net" # Define the password used with rootdn (use slappasswd to change). # This is the base64-encoded SHA hash of "secret." 55

rootpw {SSHA}fNYBYx93ZB2H7np+QEcRAaikffboQEQA # Where the database file are physically stored directory "/var/lib/ldap/grid5000.net" # Files should be created rw for the owner **only**. mode 0600 # Save the time that the entry gets modified lastmod on # Indexing options index objectclass eq index cn pres,eq # db tuning parameters; cache 2,000 entries in memory cachesize 2000 ################## Acces Control Lists ACLs ################ # The userpassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry and the special user nss access to attribute=userpassword by dn="cn=admin,dc=grid5000,dc=net" write by dn="cn=nss,dc=grid5000,dc=net" read by self write by anonymous auth by * none # The admin dn has full write access whereas the special # user nss can read everything. Others should authenticate. access to * by dn="cn=admin,dc=grid5000,dc=net" write by dn="cn=nss,dc=grid5000,dc=net" read by * auth 56

B Fichier de configuration ldap.conf # # LDAP Client configuration file # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE URI dc=grid5000,dc=net ldaps://ldap-idpot.clic.id #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # Gestion TLS/SSL # Emplacement du certicat du CA (recopié depuis le serveur) TLS_CACERT /etc/ldap/ca-cert.pem TLS_REQCERT demand 57

C Fichiers de configuration NSS C.1 le fichier /etc/libnss-ldap.conf N oubliez pas de mettre les droits 0600 à ce fichier! ########################################################## # /etc/libnss-ldap.conf ################################## # # Configuration file for libnss-ldap host <votre_serveur> # use TLS for connexion uri ldaps://<votre_serveur>/ # The distinguished name of the search base. base dc=grid5000,dc=net ldap_version 3 # The distinguished name to bind to the server with. binddn cn=nss,dc=grid5000,dc=net bindpw the_one_you_set_in_the_ldif-file as-plaintext(!) ######### Optimisations ###### # RFC2307bis naming contexts # Syntax: # nss_base_xxx base?scope?filter nss_base_passwd ou=people,dc=grid5000,dc=net?one nss_base_shadow ou=people,dc=grid5000,dc=net?one nss_base_group ou=group,dc=grid5000,dc=net?one nss_base_hosts ou=hosts,dc=grid5000,dc=net?one C.2 le fichier /etc/nsswitch.conf ######################################################## # /etc/nsswitch.conf ################################### # # Configuration of GNU Name Service Switch functionality # with LDAP capabilities. passwd: files ldap group: files ldap shadow: files ldap hosts: files ldap dns networks: files protocols: db files services: db filesethers: db files rpc: db files # not used netgroup: nis 58

D Fichiers de configuration PAM D.1 le fichier /etc/pam ldap.conf ########################################################## # /etc/pam_ldap.conf ################################## # # Configuration file for libnss-ldap host <votre_serveur> # use TLS for connexion uri ldaps://<votre_serveur>/ # The distinguished name of the search base. base dc=grid5000,dc=net ldap_version 3 # The distinguished name to bind to the server with. binddn cn=nss,dc=grid5000,dc=net bindpw the_one_you_set_in_the_ldif-file as-plaintext(!) pam_password crypt D.2 Le fichier /etc/pam.d/ssh #/etc/pam.d/ssh #%PAM-1.0 auth sufficient pam_ldap.so auth required pam_nologin.so auth required pam_unix.so auth required pam_env.so # [1] account sufficient pam_ldap.so account required pam_unix.so session sufficient pam_ldap.so session required pam_unix.so session optional pam_lastlog.so # [1] session optional pam_motd.so # [1] session optional pam_mail.so standard noenv # [1] session required pam_limits.so password sufficient pam_ldap.so password required pam_unix.so # Alternate strength checking for password. Note that this # requires the libpam-cracklib package to be installed. # You will need to comment out the password line above and # uncomment the next two in order to use this. 59

# # password required pam_cracklib.so retry=3 minlen=6 difok=3 # password required pam_unix.so use_authtok nullok md5 D.3 Le fichier /etc/pam.d/su A TESTER 60

E le fichier automount.schema A placer dans le répertoire /etc/ldap/schema : # File : automount.schema # # Should be included in autofs-ldap package # Yet, it was not the case for me # Got it from # https://init.linpro.no/pipermail/skolelinux.no/commits/2003-may/013856.html # Depends upon core.schema and cosine.schema # OID Base is 1.3.6.1.4.1.2312.4 # # Attribute types are under 1.3.6.1.4.1.2312.4.1 # Object classes are under 1.3.6.1.4.1.2312.4.2 # Syntaxes are under 1.3.6.1.4.1.2312.4.3 # Attribute Type Definitions attributetype ( 1.3.6.1.1.1.1.25 NAME automountinformation DESC Information used by the autofs automounter EQUALITY caseexactia5match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) objectclass ( 1.3.6.1.1.1.1.9 NAME automount SUP top STRUCTURAL DESC An entry in an automounter map MUST ( cn $ automountinformation $ objectclass ) MAY ( description ) ) objectclass ( 1.3.6.1.4.1.2312.4.2.2 NAME automountmap SUP top STRUCTURAL DESC An group of related automount objects MUST ( ou ) ) 61

F Quelques astuces et messages d erreurs rencontrés Il s agit de répertorier ici la liste des erreurs que j ai pu rencontré, ma principale source de compréhension des erreurs étant http://www.openldap.org/faq/data/cache/53.html 1. Si vos requêtes n aboutissent jamais, sachez que slapd utilise tcp wrappers, et la configuration par défaut est de rejeter toutes les connections venant de localhost. Il faut donc modifier/etc/hosts.allow pour permettre l accès à slapd depuis localhost an ajoutant la ligne : slapd : 127.0.0.1 2. Si a l ajout, vous otenez un message d erreur de la forme : adding new entry "ou=auto.home,dc=grid5000,dc=fr" ldap_add: No such object C est que la structure arboresscente dans laquelle vous insérer n existe pas (ici : dc=grid5000,dc=fr alors que celle définie dans/etc/ldap/slapd.conf est dc=grid5000,dc=net ) A propos de certains messages d erreur qui peuvent apparaitre dans les logs du demon slapd : 1. Jun 11 15:04:30 ldap-idpot slapd[28682]: daemon: socket() failed errno=97 (Address family not supported by protocol) http://www.openldap.org/faq/data/cache/652.html : This message indicates that the operating system does not support one of the (protocol) address families which slapd(8) was configured to support. Most commonly, this occurs when slapd(8) was configured to support IPv6 yet the operating system kernel wasn t. In such cases, the message can be ignored. 2. Jun 11 15:04:30 ldap-idpot slapd[28682]: /etc/ldap/slapd.conf: line 36: unknown directive "TLSCipherSuite" outside backend info and database definitions (ignored) Jun 11 15:04:30 ldap-idpot slapd[28682]: /etc/ldap/slapd.conf: line 37: unknown directive "TLSCertificateFile" outside backend info and database definitions (ignored) Jun 11 15:04:30 ldap-idpot slapd[28682]: /etc/ldap/slapd.conf: line 38: unknown directive "TLSCertificateKeyFile" outside backend info and database definitions (ignored) Jun 11 15:04:30 ldap-idpot slapd[28682]: /etc/ldap/slapd.conf: line 39: unknown directive "TLSCACertificateFile" outside backend info and database definitions (ignored) OpenLDAP n a pas été configuré (ou compilé) pour supporter TLS C est le cas par exemple de la version stable du package slapd qui avait été initialement installé, et correspondant à la version 2.0.23. On précise au 3.2.1 page 20 comment configurer le package pour utiliser SSL. 3. TLS: could not use key file /etc/ldap/certificate/server-key.pem Le chemin d accès au fichier incriminé (ou le fichier lui-même) est incorrect! Le vérifier et apporter les modifications correspondantes dans /etc/ldap/slapd.conf 62

G Programmation Perl avec LDAP Perl possède un ensemble de modules qui fournissent une interface orientée objet aux serveurs LDAP. Le développement le plus actif dans le domaine correspond à la distribution perl-ldap disponible sur l url http://ldap.perl.org/. Cette distribution fournit notamment le module Net::LDAP. Le chapitre 10 de [1] est consacré à l utilisation de ce module. Sous Debian, il vous suffit d installer le package libnet-ldap-perl : apt-get install libnet-ldap-perl D autres module perl peuvent être utile : 1. celui qui fournit une solution Perl de crypt() basé sur MD5 25. Il s agit plus spécifiquement du module Crypt::PasswdMD5. Pour installer ce module sous Debian : apt-get install libcrypt-passwdmd5-perl Pour disposer d une version entièrement Perl du crypt() UNIX, il suffit d installer le module Crypt::UnixCrypt : apt-get install libcrypt-unixcrypt-perl 2. Le module Term::ReadPassword permet de récupérer un mot de passe entré par l utilisateur : apt-get install libterm-readpassword-perl 25 Cette version de crypt() est utilisée dans les mots de passe 63

Historique de ce document 8 septembre 2004 Ajout de la partie sur perl-ldap 27 août 2004 Version 0.2 9 août 2004 Test du tutorial sur une install from scratch, étoffement de la biblio, refonte de certaines parties. 6 juillet 2004 Première version (0.1) 7 juin 2004 début de la réalisation Liste des tableaux 1 Principales abréviations utilisées dans le champ DN.......... 11 2 possibilité pour la directive <qui> dans les ACLs........... 15 3 possibilité pour la directive <type d accès autorisé> dans les ACLs.. 15 4 Formats de bases de données pour la base LDAP (source :[9])...... 19 5 Liste des principaux schémas disponibles................ 23 6 Liste des niveaux de log (source :[2])................... 23 7 Principales options disponibles pour slapd............... 31 8 Principales commandes online/offline.................. 31 9 Principales options communes à ldapsearch, ldapadd, ldapdelete, ldapmodify et ldapmodrdn......................... 32 10 Principales options spécifiques de ldapsearch.............. 33 11 Valeurs possibles pour le mot clé changetype............. 35 Références [1] Gerald Carter. LDAP System Administration. O Reilly, March 2003. [2] OpenLDAP community. OpenLDAP 2.2 Administrator s Guide, Feb 2004. http://www.openldap.org/doc/admin22/ [3] G. Good. RFC 2849 - The LDAP Data Interchange Format (LDIF) - Technical Specification. Technical report, Internet Engineering Task Force, June 2000. http://www.ietf.org/rfc/rfc2249.txt [4] L. Howard. RFC 2307 - An Approach for Using LDAP as a Network Information Service. Technical report, Internet Engineering Task Force, March 1998. http://www.ietf.org/rfc/rfc2307.txt [5] T. Howes. RFC 1558 - A String Representation of LDAP Search Filters. Technical report, Internet Engineering Task Force, December 1993. http://www.ietf.org/rfc/rfc1558.txt [6] J. Kohl and C. Neuman. RFC 1510 : The Kerberos Network Authentication Service (Version 5). Technical report, Massachusetts Institute of Technology, September 1993. ftp://ftp.isi.edu/in-notes/rfc1510.txt [7] T. Kukuk. The Linux NIS(YP)/NYS/NIS+ HOWTO. Technical report, The Linux Documentation Project, July 2003. http://www.tldp.org/ HOWTO/NIS-HOWTO/. 64

[8] J. Linn. RFC 2078 - Generic Security Service Application Program Interface, Version 2. Technical report, Internet Engineering Task Force, January 1997. http://www.ietf.org/rfc/rfc2078.txt [9] Luiz Ernesto Pinheiro Malère. LDAP Linux HOWTO. Technical report, The Linux Documentation Project, March 2004. http:// linux-universe.com/howto/ldap-howto/. [10] Myers. RFC 2222 - Simple Authentication and Security Layer (SASL). Technical report, Internet Engineering Task Force, October 1997. http://www.ietf.org/rfc/rfc2222.txt [11] C. Neuman and T. Ts o. Kerberos : An authentication service for computer networks. IEEE Communications Magazine, 32(9) :33 38, September 1994. http://gost.isi.edu/publications/kerberos-neuman-tso.html [12] V. Ryan and R. Lee. RFC 2713 - Schema for Representing Java(tm) Objects in an LDAP Directory. Technical report, Internet Engineering Task Force, October 1999. http://www.ietf.org/rfc/rfc2713.txt [13] M Smith. RFC 2798 - Definition of the inetorgperson LDAP Object Class. Technical report, Internet Engineering Task Force, April 2000. http://www.ietf.org/rfc/rfc2798.txt [14] R. Sundaram. Automount mini-howto. Technical report, The Linux Documentation Project, December 2002. http://tldp.org/howto/automount. html. [15] M. Wahl. RFC 2256 - A Summary of the X.500(96) User Schema for use with LDAPv3. Technical report, Internet Engineering Task Force, December 1997. http://www.ietf.org/rfc/rfc2256.txt [16] M. Wahl, T. Howes, and S. Kille. RFC 2251 - Lightweight Directory Access Protocol (v3). Technical report, Internet Engineering Task Force, December 1997. http://www.ietf.org/rfc/rfc2251.txt [17] T. Wu. The secure remote password protocol. Nov 1997. 65