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

(1)

Tutorial OpenLDAP

Installation et configuration (clients/serveurs) Migration NIS → LDAP dans GRID5000 S´ecurisation par SSL et optimisations

[email protected] Version : 0.3 – F´evrier 2005

R´esum´e

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`erement dans l’objectif de remplacer NIS.

La première partie (§1) est consacrée à ceux qui n’ont pas de temps

`a perdre et qui souhaitent disposer rapidement d’un environnement fonctionnel. Les sections suivantes d´etaillent 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¸con à 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 dis- tributions comme RedHat ou Mandrake.

(2)

Table des mati` eres

1 Pour les plus press´es : Ultra Quick Guide 5

1.1 Pr´erequis . . . 5

1.2 Cot´e serveur... . . 5

1.3 Gestion des fichiers de configurations par LDAP . . . 5

1.4 Cot´e 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 `a 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´epliqu´e . . . 10

2.3.4 Annuaire distribu´e . . . 10

2.4 Le mod`ele de donn´ees LDAP . . . 10

2.4.1 Le Directory Information Tree (DIT) . . . 11

2.4.2 Les sch´emas . . . 11

2.4.3 LDIF . . . 12

2.5 La s´ecurit´e dans LDAP . . . 13

2.5.1 Authentification . . . 13

2.5.2 Contrˆole d’acc`es . . . 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´e-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´emas . . . 22

4.1.2 Logging, configuration d’execution . . . 23

4.1.3 Options SASL . . . 24

(3)

4.1.4 Options SSL/TLS . . . 24

4.1.5 Autres options de s´ecurit´e . . . 25

4.2 Configuration des Bases de Donn´ees . . . 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´ees . . . 27

4.4 Modification du script de d´emarrage /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´erifier 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´ees dans la base LDAP . . . 32

5.4 Recherches dans la base LDAP . . . 33

5.5 Modifier/Supprimer des entr´ees 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´eration 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´erifier que ¸ca 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

(4)

8 Evolution au sein du projet Grid5000 50

8.1 Premi`ere 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´erimentation : 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´es 62

G Programmation Perl avec LDAP 63

(5)

1 Pour les plus press´ es : Ultra Quick Guide

1.1 Pr´erequis

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´e 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 ldap- utils

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´ecup´erer le fichier slapd.conf fourni en annexe A page 55 et le placer

dans /etc/ldap/slapd.conf

(c) configurer syslog pour g´erer 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.logsera une aide pr´ecieuse pour le d´ebuggage.

(d) Initialisation du contenu de la base LDAP : suivre les instructions du §4.3 page 27.

(e) Modification du script de d´emarrage /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´erifier 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.

(6)

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´er´ee 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´ecommenter dans le fichier de configuration slapd.confla 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´e client...

1.4.1 Initialisation et configuration de base du client 1. Installation

(a) Cas Debian stable : compte tenu des remarques relatives `a la gestion SSL pour le package client stable (voir §7.1 page 42), il convient de forcerl’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´erer 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´e le certificat du serveur) et le placer dans/etc/ldap/CA-cert.pem

5. V´erifier 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 ˆetes sur une Debian stable)

(b) cp /etc/libnss-ldap.conf /etc/libnss-ldap.conf.old

(c) Recup´erer 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´erer le fichier fourni en annexe C.2 page 58 et le placer dans /etc/nsswitch.conf

(7)

(f) Pour v´erifier que ¸ca marche... : suivre les instructions du paragraphe associ´e 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 `a 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.confpour qu’il contienne les entr´ees suivantes : passwd: files nis ldap

shadow: files nis ldap group: files nis ldap hosts: files nis ldap dns

Pour vérifier que ¸ca 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

(8)

2 Introduction

2.1 Notion d’annuaire electronique

Un annuaire électronique est une base de données spécialisée qui permet de partager des bases d’informations sur un réseau. Ces bases peuvent contenir toute sorte d’informations, comme des coordonnées téléphoniques ou des don- né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¹ 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ˆemes concepts que DNS², le service de nommage utilis´e sur l’Internet pour faire correspondre un nom explicite (commewww-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 adminis- tratives 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¸con 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´ees ;

– 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éesché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’univer- sité du Michigan, OpenLDAP³ 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⁴), 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.

1Network Information System, ou Yellow Pages yp

2Domain Name System

3http ://www.openldap.org

4Simple Authentication and Security Layer

(9)

Nous nous interessons ici à la version 3 de LDAP, référencée sous le nom LDAPv3 [16].

2.2 Mais qu’apporte LDAP ?

Cot´e utilisateur, LDAP fournit les services suivants :

– un protocole d’acc`es `a l’information contenue dans l’annuaire ;

– unmodè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 ;

– unmodèle fonctionnel qui définit comment on accède à l’information ; – unmodèle de sécurité qui définit comment les données et les accès sont pro-

t´eg´es,

– unmodè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 dereferral) 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´etaill´ees dans la suite.

2.3.1 Serveur local

Dans ce cadre, il n’y a pas d’interactions entre le serveurslapd du domaine et un quelconque autre serveur. Ce mode de fonctionnement est illustr´e dans la figure 1

Client Serveur

2. Réponse 1. Requete

Fig. 1 –Configuration locale(source :[2])

Cette configuration est particuli`erement adapt´e au cas d’un intranet local.

2.3.2 Annuaire local avec referrals

Ici, le serveur est configur´e sur le domaine local pour rendre les services d’annuaires et de renvoyer un ”referral” (une sorte de pointeur) vers un serveur

(10)

supérieur capable de répondre aux requêtes en dehors du domaine local. Il est à noter que par défaut et pour éviter de surcharger le serveur, le client à a charge de relancer la requete vers le serveur pointé (figure 2).

Client Serveur

Supérieur Serveur

2. Referral 1. Requete 3. Nouvelle requete

Fig. 2 –Configuration locale avec referral(source :[2])

Ce mode de fonctionnement est particuli`erement adapt´e au cas des grilles de grappes, donc au cadre du projet Grid5000.

2.3.3 Annuaire r´epliqu´e

Dans ce cadre, le démonslurpd est chargé de propager les changements effectués d’un serveurslapd maˆıtre vers un ou plusieurs serveursslapd esclave (figure 3).

Fig. 3 –Configuration par r´eplication(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´e

Dans cette configuration, le service local est partitionné en plusieurs sous- services, 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`ele de donn´ees 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.

(11)

2.4.1 Le Directory Information Tree (DIT)

Les données LDAP sont structurées dans une arborescence hiérarchique com- parable à celle des systèmes de fichiers UNIX.

Chaque noeud de l’arbre correspond à une entrée⁵ 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 sondistingui- shed 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´eviations utilis´ees dans le champ DN

Le DN représente le nom de l’entrée sous la forme du chemin d’accès à celle- ci 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´ees 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´emas

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 classetop

`

a 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`u ’directory service entry’ (DSE) dans la litt´erature anglaise.

(12)

cn: g5k

objectClass: top userPassword: {crypt}x gidNumber: 24560 memberUid: svarrett memberUid: georget objectClass: posixGroup uid=svarrett uid=georget

ou=People ou=Group

cn=equipar cn=g5k

entry DIT

Liste d’attributs associés à une entry; format <type>:<valeur>

Distinguished Name:

RDN (Relative Distinguished Name) depuis dc=grid5000,dc=fr

dn: cn=g5k ,ou=Group,dc=grid5000,dc=fr

ou=Group,dc=grid5000,dc=fr

Fig.4 – Exemple de DIT : cas de la gestion NIS

identifier (OID) unique attribu´e par l’Internet Assigned Numbers Authority (IANA).

2.4.3 LDIF

LDAP Data Interchange Format (LDIF), définit dans [3], est un format texte⁶ 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 :

ou le premier attribut d’une entr´ee est le DN.

Un entr´ee aura donc la forme suivante :

# Ceci est un commentaire dn: <distinguished name>

objectClass: <object class>

...

Ainsi, comme précisé dans la figure 4, le format LDIF pour l’entrée de RDN cn=g5ksera :

dn: cn=g5k,ou=Group,dc=grid5000,dc=fr objectClass: posixGroup

6Le format utilisé est l’ASCII, les données binaires étant codées en base 64.

(13)

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´ecurit´e 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 read- only 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

´ecriture (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´eration ”bind”.

LDAPv3 propose plusieurs m´ecanismes 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 confiden- tialité 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´ee via son mot de passe mais on peut imaginer un mode (non encore test´e) ou cette

(14)

authentification se fait sur simple présentation d’un certificat contenant la clé publique de l’utilisateur, la clé privée associée étant stockée sur un support sûr et personnel (carte à puce, clé USB etc...). Cette dernière approche sera étudiée dans le cadre de 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 signi- ficative contre un certain nombre d’attaques.

GSSAPI ⁷ permet d’utiliser les mécanismes de Kerberos V [6, 11], un système d’authentification sécurisé à tierce personne de confiance con¸cu 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´ecanisme de type OTP (One Time Password) bas´e sur MD5.

EXTERNAL permet d’utiliser des m´ecanismes d’authentification d’une couche inf´erieure, comme SSL/TLS

Il y a encore beaucoup d’autres m´ecanismes possibles, comme SRP (Secure Remote Passwords [17])

2.5.2 Contrˆole d’acc`es

Il s’agit de d´efinir les droits d’acc`es 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.confpar access to <quoi> by <qui> <type_d’acces_autoris´e>

Dans la partie<quoi>, on peut sp´ecifier :

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

7Generic Security Service Application Program Interface, d´efini dans [8]

(15)

* tous les utilisateurs, aussi bien anonymes qu’authentifi´es anonymous utilisateur non authentifi´e et donc anonyme

self utilisateurs associé à l’entrée ciblée users utilisateur authentifié

dn=<regex> utilisateur qui correspond `a l’expression reguli`ere 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´e/renomm´e

read lecture des r´esultats 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`es

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`es 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éfi- nies 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´ees 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¸con 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

(16)

communs :

{CRYPT} utilise un hachage par la fonction Unix crypt(), bas´e `e sur DES.

C’est mode le plus faible en terme de s´ecurit´e 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

(17)

3 Installation du serveur LDAP

3.1 Pr´e-requis

Il y a un certain nombre de composants `a installer en dehors de OpenLDAP pour ˆetre 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´etails de la compilation from scratch TODO : pr´eciser 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´eer sur le serveur le r´epertoire 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⁸. 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 unupdatedbavant d’obtenir une r´eponse 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.

8Source :http://www.openldap.org/faq/data/cache/185.html

(18)

What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value,

If you enter ’.’, the field will be left blank.

---

Country Name (2 letter code) [AU]:FR

State or Province Name (full name) [Some-State]:Isere Locality Name (eg, city) []:Grenoble

Organization Name (eg, company) [Internet Widgits Pty Ltd]:IMAG Organizational Unit Name (eg, section) []:ID

Common Name (eg, YOUR name) []:CA-IDPOT Email Address []:[email protected]

Cet appel a créé un répertoire (demoCA) contenant notamment le certificat du CA (’cacert.pem’).

2. Cr´eation 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 []:[email protected]

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

(19)

Enter PEM pass phrase:

Check that the request matches the signature Signature ok

The Subjects Distinguished Name is as follows countryName :PRINTABLE:’FR’

stateOrProvinceName :PRINTABLE:’Isere’

localityName :PRINTABLE:’Grenoble’

organizationName :PRINTABLE:’IMAG’

organizationalUnitName:PRINTABLE:’ID’

commonName :PRINTABLE:’ldap-idpot.clic.id’

emailAddress :IA5STRING:’[email protected]’

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´es 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 Description

bdb Berkeley DB transactional backend dnssrv DNS SRV backend

ldbm Lightweight DBM backend

ldap Lightweight Directory Access Protocol (Proxy) backend meta Meta Directory backend

monitor Monitor backend

passwd Provides read-only access to passwd(5) perl Perl programmable backend

shell Shell (external program) backend sql SQL programmable backend

Tab. 4 –Formats de bases de donn´ees 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-ˆetre tester la version 4)

(20)

3.1.4 Installation de SASL

En cours d’investigations... Pour le moment, une authentification simple s´ecu- ris´ee 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 or- ganisé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).

ou=Hosts

ou=People ou=auto.home

dc=grid5000,dc=net

(/etc/passwd)

ou=Group

(/etc/group) (/etc/hosts) (/etc/auto.home) Grenoble ldap−idpot.clic.id

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 serveurldap-idpot.clic.id(voir§1)

On verra dans la section 8 l’evolution envisag´ee pour cette architecture. La racine changera notamment pourdc=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⁹ 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

9Au 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 unapt-get update.

(21)

Pour activer SSL :

> cd openldap2-2.0.23

puis ´editer le fichierdebian/rulesen changeant--without-tlspar--with-tls.

Il suffit alors de compiler le package :./debian/rules binary.

Cette commande va cr´eer les packages.deb`a 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´erie 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ˆecher la mise a jour automatique de ces packages via le d´epot 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écu- rité !

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ˆeme, Debconf va vous poser une s´erie 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´ee, stopper le serveur LDAP par/etc/init.d/slapd stop; – Les fichiers de configuration seront localis´es dans/etc/ldap/

(22)

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´emas

# configuration globales des logs, de SSL etc...

############################

# Database #1 - Berkeley DB

# Parametres de la base de donn´ees

# ACL de cette base

############################

# Database #2 - Berkeley DB

# Param`etres de la base de donn´ees

# 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´efaut :

> 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´etaillent chaques parties de ce fichier. Si vous souhaitez utiliser directement le fichier fourni sans lire ces explications, n’oubliez pas :

1. de configurersyslogpour g´erer 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 `a la section 4.3 page 27 pour achever la configuration du serveur.

4.1 Configurations globales 4.1.1 Inclusion des sch´emas

La première chose à définir : quels schémas¹⁰ 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´es par d´efaut dans /etc/ldap/schema.

On les ajoute par l’appel include <filename>

Typiquement, on aura donc les inclusions suivantes :

10Les schémas ont été introduit au§2.4.2, page 11

(23)

Sch´ema 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´ef´erences JDNI (cf [12]) misc.schema divers objets et attribut.

nis.schema n´ecessaire pour remplacer NIS par LDAP (cf[4] et§6) openldap.schema divers objet utilis´e 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´emas 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`a 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¹¹.

11Le niveau par d´efaut est 296=256+32+8

(24)

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.logsera une aide pr´ecieuse pour le d´ebuggage.

D’autres paramètres contrôlent l’exécution :

– pidfile <filename>: le fichier ou sera stocké le PID de slapd¹². – 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 certifi- catdu 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

12Ce fichier est principalement utilis´e par les script de shutdown

(25)

4.1.5 Autres options de s´ecurit´e

On distingue un certain nombre d’autres directives de s´ecurit´e :

– 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}

– securitypermet de définir un ssf¹³(une valeur entière comprise entreminssf etmaxssf, 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_v2autorise 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´ees

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 fichierslapd.conf (§4 page 22).

4.2.1 Ajout d’une base

Dans notre exemple, on ajoute au fichierslapd.confles 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)

– suffixpermet 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 ??.)

– rootpwcorrespond au mot de passe de l’utilisateurrootdn. Pour le g´en´erer, il suffit d’utiliser la commande suivante :

13security strength factor

(26)

> slappasswd New password:

Re-enter new password:

{SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

La chaine renvoyée peut alors être ajouter à la directiverootpw.

– directorydéfinit le répertoire ou sera physiquement stocké la base de don- né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´es sont les suivants : – approx (approximate)

– eq (equality) – pres (presence) – sub (substring)

2. le paramètre cachesizequi 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 eq

index cn pres,eq

cachesize 2000

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 eq

index gidNumber eq

index memberUid eq

index cn pres,eq,sub

index sn pres,eq,sub

index objectClass pres,eq

index nisDomain eq

index nisNetgroupTriple pres,eq,sub index memberNisNetgroup pres,eq,sub

index nisMapName eq

index amdMapName eq

index amdMapKey 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´ee dans cet exemple :

(27)

# 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=netqui 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´etaillera les commandes que nous allons utiliser ici. Nous utilise- rons des fichiers au format LDIF (voir§2.4.3, page 12) pour ces insertions.

Les insertions de base sont incluses dans le fichierinit_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

(28)

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 `a l’entr´ee 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´ees dans la base de donn´ees :

> 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´ecessaire de modifier le script de d´emarrage de slapd (il s’agit du script /etc/init.d/slapd).

La premi`ere id´ee (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 bi- naire slapd pour le script de démarrage) mais l’usage des guillemets pose pro- blème.

4.4.1 Cas Debian stable

Curieusement, même si un fichier/etc/default/slapdexiste, 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:///’.

(29)

4.4.2 Autres cas

TODO : dans les versions r´ecentes de slapd, le fichier /etc/default/slapd contient la ligne

# Example usage:

SLAPD_SERVICES="ldap:/// ldaps:///"

a ajouter...

On modifie /etc/init.d/slapden remplacant :

--exec /usr/sbin/slapd -- $SLAPD_OPTIONS 2>&1‘

dans la fonctionstart_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 en- capsulée dans un tunnel SSL, ce qui impose soit l’utilisation d’url ldaps://

(configuration par défaut des clients), soit l’utilisation d’urlldap://avec l’option-ZZdans la requête (à éviter)

TODO : inclure les modifs propos´ees dans la section suivante. Inclure tout cela dans un fichier propos´e 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 rootmais par un utilisateur d´edi´e, typiquementslapd.

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

`

a jour de s´ecurit´e ce qui laisse du temps pour l’exploitation d’attaques sur le serveur !

->TODO d´etailler les manips et les tester.

4.6 V´erifier que le serveur marche On lance le serveur :

/etc/init.d/slapd start

(penser `a jeter un coup d’oeil aux logs en live par untail -f /var/log/slapd.log sur une autre console par exemple).

Les commandes suivantes¹⁴, lanc´ees sous root, doivent rendre un r´esultat sans erreur :

ldapsearch -H "ldap://127.0.0.1" -b "dc=grid5000,dc=net" -x teste une requˆete non chiffr´ee sur le port standard 389

ldapsearch -H "ldap://ldap-idpot.clic.id" -b "dc=grid5000,dc=net" -x -ZZ teste une requˆete chiffr´ee sur le port standard 389. l’option -ZZ montre

que StartTLS marche correctement. Le nom sp´ecifi´e dans l’URL (ici,

14en remplacant ldap-idpot.clic.idpar le nom de votre serveur

(30)

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¸con de spécifier l’utilisation de SSL). Même remarque que précédemment pour le nom utilisé dans l’URL.

(31)

5 Les principales commandes LDAP

5.1 Lancement du serveur slapd

Options Description

-h URI list Sp´ecifie la liste des URIs LDAP que le d´emon slapd devra servir.

Exemple typique : ldap:/// (LDAP sur port 389 ; par default), ldaps:///(LDAP sur SSL on port 636) etldapi:///(LDAP sur IPC).

-u username Sp´ecifie l’utilisateur et le groupe effectif pour slapd -g groupname

-d integer D´efinit le niveau de log

-f filename Utiliser le fichier de configuration sp´ecifi´e Exemple :slapd -u slapd -h ’ldap :/// ldaps :///’

Tab. 7 –Principales options disponibles pour slapd Le serveur peut ˆetre lanc´e de deux fa¸cons :

– Soit directement (voir le tableau 7 pour les options possibles) :/usr/sbin/slapd On v´erifie que le serveur est bien lanc´e par ps -ef | grep slapd.

ATTENTION : pour stopper proprement¹⁵ le serveur lanc´e de cette fa¸con :

> kill -INT ‘cat /var/run/slapd.pid‘

– Soit via le script de d´emarrage :/etc/init.d/slapd <start|stop|restart>

Noter les modifications apport´ees `a ce script au §4.4, page 28.

5.2 Commandes online/offline

Offline Online Description

slapadd ldapadd Ajout d’entr´ees 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´ee LDAP ldapdelete Suppression d’une entr´ee LDAP

ldapmodify Modification d’une entr´ee ldapsearch Recherche dans la base LDAP ldapmodrdn Renommage d’une entr´ee LDAP

Tab.8 –Principales commandes online/offline On distingue deux modes de fonctionnement :

1. méthodeoffline (sans passer par le serveur LDAP) : Dans ce cas, on utilisera la commandeslapadd. 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.’

(32)

sur le serveur LDAP.

2. m´ethode online (en passant par le serveur LDAP) : commande ldap*

(comme ldapadd,ldapmodify etc...). Ces commandes peuvent êtres uti- lisées indifférement depuis le serveur ou un client LDAP¹⁶

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´ecifie le DN utilis´e 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´ecifie le mot de passe du DN utilis´e pour la connexion

-W demande un prompt pour entrer le mot de passe du DN utilis´e 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ˆete soit r´eussie.

-d integer spécifie les informations de débuggage à afficher (voir tableau 6 page 23)

Tab.9 –Principales options communes `a ldapsearch, ldapadd, ldapdelete, ldapmodify et ldapmodrdn

5.3 Ajouter des entr´ees dans la base LDAP Pour ajouter des entr´ees dans la base :

1. créer un fichier au format LDIF (voir§2.4.3 page 12), par exempletoto_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´ementaires.

Pour la m´ethode online (si le serveur tourne) :

(a) Définissez un alias pour éviter de retaper toujours les mêmes op-

tions¹⁷:alias MyLdapadd=’ldapadd -W -x -H "ldaps://<votre_serveur>"

-D "cn=admin,dc=grid5000,dc=net"’

16sous réserve évidemment que celui-ci soit correctement installé et configuré : voir pour cela la section 7 page 42

17Il 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 deslapd.conf(§4.2.2) et

’ajout echouera. Voir le tableau 9 pour bien comprendre `a quoi chaque option correspond

(33)

(b) MyLdapadd -v -f toto_add.ldifpour ajouter le contenu du fichier

`

a la base.

A noter l’existence de l’option -c de ldapadd qui permet de continuer malgr´e les erreurs.

Un exemple d’ajout a déjà été présenté au§4.3 page 27.Sinon, voici le contenu du fichiertoto_add.ldifutilisé 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 commeldap_add: Invalid syntaxet/ou

additional info: value contains invalid data), assurez vous que les sauts de lignes ne comportent pas d’espace au d´ebut de la ligne¹⁸ et que vous incluez les bons schemas dansslapd.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 deldapsearchsont fournies dans le tableau 10 – le filtre de recherche doit être représenté par une chaine au format spécifié

dans [5]. Par d´efaut, le filtre utilis´e est(objectClass=*).

– si une ou plusieurs entrées sont trouvées, seuls les attributsattrs(tous par défaut) seront affichés sur la sortie standard.

Options Description

-b basedn d´efinit le DN de base pour la recherche

-l limit d´efinit la dur´ee limite (en seconde) pour la recherche

-L-LL-LLL le r´esultat est fournit au format LDIFv1, -LL supprime les com- mentaires, comme -LLL qui supprime aussi les infos de version -s [sub|base|one] d´efinit 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´ecifiques de ldapsearch

Voici quelques exemples d’utilisation, qui illustrent ´egalement le fonctionnement des ACLs :

18utiliser l’option ’set list’ de vi pour le voir

(34)

Exemple 1 Voir tout ce que la base contient :ldapsearch -x -b "dc=grid5000,dc=net", identique `a :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´esultats des commandes suivantes¹⁹ :

>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 DNcn=nss,dc=

grid5000,dc=netest authentifi´e et autoris´e en lecture (clause by dn="cn=nss,dc=grid5000,dc=net" read).

5.5 Modifier/Supprimer des entr´ees 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 commandeldapmodify. 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´efinir un alias pour ldapmodify et les options que vous utiliserez `a chaque fois :

alias MyLdapmodify=’ldapmodify -W -x -H "ldaps://<votre_serveur>" \ -D "cn=admin,dc=grid5000,dc=net"’

Voici maintenant un exemple suffisamment comment´e qui illustre toutes ces possiblitit´es

19l’option -LLL n’est utilis´ee que pour limiter la taille des r´esultats en sortie (voir tableau 10)

(35)

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´ee. On peut ainsi `a la fois ajouter, modifier ou supprimer des attributs

modrdn changer le RDN (Voir tableau 1 page 11) de l’entr´ee moddn changer le DN de l’entr´ee

Tab.11 – Valeurs possibles pour le mot cl´e ’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