FAI Local » Docs publiques

{{>toc}}

h1. Annuaire LDAP

*Installation d'OpenLDAP*

Documentation:

http://www.openldap.org/doc/admin24 (la doc de référence openldap en anglais)

http://www.zytrax.com/books/ldap/ (en anglais mais très bien pour apprendre)

http://www.vogelweith.com/debian_server/050_openldap.php (pas forcément très à jour)

http://doc.ubuntu-fr.org/openldap-server

Versions utilisées dans le cadre de cette documentation:

Ubuntu 11.04 Natty Narwal / Debian Wheezy

openldap 2.4.23

Approche choisie pour l'installation:

* utilisation de debconf pour générer un début de conf

* le strict minimum de configuration à la main dans /etc/ldap/slapd.d

* utilisation du client lourd Apache Directory Studio pour terminer la configuration et administrer le serveur

L'intérêt d'utiliser précocement un client ldap lourd pour faire la conf est de donner le plus tôt possible à l'utilisateur néophyte une vision globale de l'arborescence ldap, de rendre celle-ci un peu plus facile à appréhender. Les autres docs en ligne exploitent davantage les outils ldap de base en ligne de commande (slapadd, fichiers ldif, etc), et peuvent sembler encore plus absconses quand on a pas l'habitude d'OpenLDAP.

Note:

* dans openldap, SHA signifie SHA1

* dans openldap, SSHA signifie _Seeded_ SHA1 (un _salt_ en plus)

h1. Installation du package / debconf

+Note+: il semble raisonnable de ne pas ouvrir le LDAP sur l'extérieur tant que l'on a pas terminé son installation, la configuration des ACL et celle de TLS.

<pre>

sudo apt-get install slapd ldap-utils

</pre>

Debconf:

* Please enter the password for the admin entry in your LDAP directory.

-> saisir n'importe quoi à ce stade. ce mdp sera écrasé par le suite

Debconf a créé un début de configuration pour openldap, ainsi qu'un annuaire basé sur le fqdn du système, qui ne va pas convenir à nos besoins.

h1. Configuration d'openldap

http://www.openldap.org/doc/admin24/slapdconf2.html

h2. Description

Le LDAP a une structure arborescente.

La racine s'appelle le root DSE (root directory specific entry).

Juste en dessous du DSE, deux sous-arbres identifiés par leur Distinguished Name:

* +DN="cn=config"+: la configuration d'OpenLDAP, organisée de manière arborescente, avec la conf des backends de données, avec les schémas de données installés, la réplication, etc. *Problème: l'install debian n'a pas défini de compte admin pour cette branche du LDAP. On ne peut donc pas encore y accéder avec un client LDAP.* Par contre, cette branche de l'annuaire est stockée au format ldif dans /etc/ldap/slapd.d et elle est modifiable à froid.

* +DN="o=ILLYSE,l=Villeurbanne,st=RHA,c=FR"+: l'annuaire d'Illyse. Les données, avec les comptes d'utilisateurs, les groupes, etc. Cette branche de l'annuaire est stockée dans une base HDB sous /var/lib/ldap. *Problème: debconf n'a pas généré un "contexte de nommage" convenable pour cette branche: les objets ont des noms (DN) se terminant en "dc=xxx,dc=yyy" (en fonction du fqdn du serveur) au lieu de "o=ILLYSE,l=Villeurbanne,st=RHA,c=FR"*. Il faut corriger cela sous /etc/ldap/slapd.d également.

+Note+: le choix du contexte de nommage en o=ILLYSE,l=Villeurbanne,st=RHA,c=FR permet d'avoir une cohérence entre les noms (DN) des objets du ldap et les noms (DN) des certificats issus de la [[PKI]]. Cela facilite l'utilisation conjointe du ldap et de la [[PKI]] pour faire de l'authentification forte. (Pour en savoir plus: http://en.wikipedia.org/wiki/Directory_information_tree - ici, on a fait le choix de tout aligner sur la structure par défaut des DN dans openssl. On aurait à priori pu choisir une autre structure et adapter la configuration d'openssl.)

h2. Configuration de base dans /etc/ldap/slapd.d

*Permettre l'accès à cn=config*

Il faut ajouter un DN de login et un mot de passe dans le fichier ldif définissant le backend pour la branche cn=config. On utilise slappasswd pour calculer un hachage.

<pre>

sudo /etc/init.d/slapd stop

</pre>

<pre>

lemur@rigel:/etc/ldap/slapd.d$ slappasswd

New password:

Re-enter new password:

{SSHA}foobarEbUllsH1tolnl8CXbUllsH1tFi

</pre>

<pre>

sudo vi /etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif

</pre>

Modifier la ligne olcRootDN et ajouter la ligne olcRootPW, avec le hachage produit par slappasswd:

<pre>

olcRootDN: cn=admin,cn=config

olcRootPW: {SSHA}foobarEbUllsH1tolnl8CXbUllsH1tFi

</pre>

<pre>

sudo /etc/init.d/slapd start

</pre>

Il est maintenant possible de se connecter au LDAP en tant que cn=admin,cn=config et de modifier la configuration du serveur.

*Correction du contexte de nommage*

Le fichier slapd.d/cn=config/olcDatabase={1}hdb.ldif définit le backend pour la branche du ldap contenant les données. Il est nécessaire de le corriger pour passer au contexte de nommage o=ILLYSE,l=Villeurbanne,st=RHA,c=FR

<pre>

sudo /etc/init.d/slapd stop

sudo vi /etc/ldap/slapd.d/cn=config/olcDatabase\=\{1\}hdb.ldif

</pre>

Modifier les lignes suivantes (il s'agit essentiellement de remplacer les occurrences de dc=xxx,dc=yyy par o=ILLYSE,l=Villeurbanne,st=RHA,c=FR et de définir un mot de passe admin)

<pre>

olcSuffix: o=ILLYSE,l=Villeurbanne,st=RHA,c=FR

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by cn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write by * none

olcAccess: {2}to * by self write by dn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write by * read

olcRootDN: cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR

olcRootPW: {SSHA}foobarEbUllsH1tolnl8CXbUllsH1tFi

</pre>

Utiliser le même hachage de mot de passe que précédemment pour olcRootPW.

+Note+: les lignes sont coupées à 78 caractères par défaut dans les fichiers LDIF. Pour faciliter l'édition, il n'est pas gênant de joindre les lignes fractionnées (pour les olcAccess, notamment). slapd saura quand même les lire.

+Note+: on pourrait avoir des mdp différents pour l'administrateur de la configuration (cn=admin,cn=config) et pour celui des données (cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR). En pratique, sur un serveur en prod, on peut même ne pas définir du tout les comptes administrateurs, et faire les modifs en ligne de commande.

Purger la base HDB initialement créée par debconf. Openldap recréera une base vierge au redémarrage de slapd.

<pre>

sudo rm /var/lib/ldap/*

</pre>

<pre>

sudo /etc/init.d/slapd start

</pre>

h2. Connexion avec Apache Directory Studio

http://directory.apache.org/studio/downloads.html

+Note+: pour le moment, la branche o=ILLYSE,l=Villeurbanne,st=RHA,c=FR est encore vide.

A ce stade, avec les ACL par défaut (stockées sous cn=admin), il existe trois niveaux d'accès:

* +anonyme+: accès en consultation à tout o=ILLYSE,l=Villeurbanne,st=RHA,c=FR, à l'exception des attributs sensibles (hachages de mots de passe). Dans DS, choisir _Pas d'authentification_ sur l'onglet Authentification de la fenêtre de connexion.

* +admin o=ILLYSE,l=Villeurbanne,st=RHA,c=FR+: accès complet à o=ILLYSE,l=Villeurbanne,st=RHA,c=FR. Dans DS, choisir _Authentification simple_ et se connecter en tant que cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR avec le mdp.

* +admin cn=config+: accès complet à la configuration d'openldap, ainsi qu'à o=ILLYSE,l=Villeurbanne,st=RHA,c=FR. Dans DS, choisir _Authentification simple_, se connecter en tant que cn=admin,cn=config avec le mdp, _et sur l'onglet Options du navigateur, *choisir cn=config comme DN de base_.*

Maintenant qu'on dispose d'un accès facile à cn=config, on peut commencer la configuration proprement dite.

h2. Configuration

_Se connecter en tant que cn=admin,cn=config._

!https://www.illyse.org/attachments/download/214/dirstudio-ldap-install1.PNG!

*Interdiction des connexions anonymes / restriction des droits des users authentifiés*

_En tant que cn=admin,cn=config._

http://www.openldap.org/doc/admin24/access-control.html

L'objet qui définit le backend de stockage pour la branche o=ILLYSE,l=Villeurbanne,st=RHA,c=FR est olcDatabase={1}hdb,cn=config. 

Les ACL de base régissant l'accès à la branche o=ILLYSE,l=Villeurbanne,st=RHA,c=FR se trouvent dans les attributs _olcAccess_ de cet objet.

+Valeur par défaut des attributs olcAccess de olcDatabase={1}hdb,cn=config+

<pre>

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write by * none

olcAccess: {1}to dn.base="" by * read

olcAccess: {2}to * by self write by dn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write by * read

</pre>

Un minimum d'explication de texte s'impose:

+Première ligne+: concerne spécifiquement les attributs d'authentification ("to attrs=userPassword,shadowLastChange")

* by self write: un user authentifié a le droit de changer son propre mot de passe

* by anonymous auth: une connexion non authentifiée peut y accéder, mais uniquement dans le cadre du process d'authentification (permet le login)

* by dn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write: droit en écriture pour l'administrateur de la branche o=ILLYSE,l=Villeurbanne,st=RHA,c=FR

* by * none: aucun accès pour le reste du monde

+Deuxième ligne+: je ne suis pas encore certain de la signification de _dn.base=""_ mais cette ligne est nécessaire à l'authentification SASL.

+Troisième ligne+: concerne l'ensemble de l'annuaire o=ILLYSE,l=Villeurbanne,st=RHA,c=FR ("to *")

* by self write: un user authentifié peut modifier sa propre entrée dans l'annuaire

* by dn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write: l'admin accède à tout en écriture

* by * read: accès en lecture à tout le monde (y compris les connexions non authentifiées). On va changer ça tout de suite.

Les clauses des ACL sont évaluées dans l'ordre. L'évaluation s'arrête à la première clause qui matche.

On modifie ces ACL pour interdire la consultation anonyme et limiter les droits des utilisateurs authentifiés.

+Configuration modifiée+

<pre>

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write by users none by * none

olcAccess: {1}to dn.base="" by * read

olcAccess: {2}to * by self write by users none by * none

</pre>

Désormais, les connexions anonymes (by anonymous, by *) n'ont plus accès qu'à la procédure d'authentification.

Les utilisateurs authentifiés n'ont accès (en lecture/écriture) qu'à leur propre entrée dans le ldap (by self write / by users none).

*Indexation*

_En tant que cn=admin,cn=config._

Certains attributs sont indexés pour accélérer les recherches dans l'annuaire. On spécifie les attributs habituellement indexés dans olcDatabase={1}hdb,cn=config.

=>modifier l'attribut olcDbIndex de olcDatabase={1}hdb,cn=config:

<pre>

olcDbIndex: objectclass,entryCSN,uid,cn,entryUUID eq

</pre>

Cette ligne signifie que les attributs objectclass, entryCSN, uid, cn et entryUUID seront indexés pour l'opérateur d'égalité.

+Note+: *attributs indexés au 17/1/2012* (pour référence - nécessite des schémas de données qui ne sont pas installés à ce stade)

<pre>

olcDbIndex: objectclass,entryCSN,uid,cn,entryUUID,mail,dlzType eq

</pre>

Il faut maintenant exécuter slapindex (à froid) en tant que openldap pour mettre à jour l'indexation.

<pre>

sudo /etc/init.d/slapd stop

su - openldap -s /bin/bash

/usr/sbin/slapindex

# ou sudo -u openldap slapindex -v

#indexing id=00000001

#indexing id=00000002

#indexing id=00000003

# ...

sudo /etc/init.d/slapd start

</pre>

*StartTLS*

_En tant que cn=admin,cn=config._

http://www.openldap.org/doc/admin24/tls.html

Produire un certificat pour le serveur LDAP en utilisant la [[PKI]].

Spécificités concernant la génération des certificats LDAP: [[ldap-pki]]

+Note+: la clé privée du certificat du serveur LDAP ne doit pas être protégée par mot de passe. Openldap ne le gère pas.

Stockage des certificats (CA+serveur LDAP) et de la clé:

<pre>

lemur@rigel:/etc/ldap$ ls -al *.crt *.key

-rw-r--r-- 1 openldap openldap 1797 2011-10-16 23:05 ca.crt

-rw-r--r-- 1 openldap openldap 5649 2011-10-17 11:21 ldap0.illyse.org.crt

-rw------- 1 openldap openldap 1679 2011-10-17 11:21 ldap0.illyse.org.key

</pre>

Note/FIXME: on doit pouvoir faire mieux pour les droits sur la clé, en ajoutant openldap au groupe ssl-cert.

Se connecter cn=admin,cn=config, afficher l'objet cn=config (et non plus olcDatabase={1}hdb), et ajouter les attributs suivants:

<pre>

olcTLSCACertificateFile: /etc/ldap/ca.crt

olcTLSCertificateFile: /etc/ldap/ldap0.illyse.org.crt

olcTLSCertificateKeyFile: /etc/ldap/ldap0.illyse.org.key

olcTLSVerifyClient: allow

</pre>

<pre>

sudo /etc/init.d/slapd restart

</pre>

On peut maintenant se connecter à l'annuaire avec StartTLS sur le port 389.

=> modifier les connexions dans Apache Directory Studio

l'attribut _olcTLSVerifyClient=allow_ signifie que l'on peut s'authentifier en utilisant un certificat client, mais que ce n'est pas exigé par le serveur. Les connexions avec du simple chiffrement TLS restent autorisées. Forcer l'authentification forte rendrait le ldap difficile à exploiter depuis la plupart des clients/services. Elle sera toutefois employée dans le cadre de la réplication entre serveurs LDAP, entre autres pour éviter de laisser des mots de passe en clair dans la configuration.

*ldaps* (optionnel)

_En tant que cn=admin,cn=config._

Certains services n'implémentent pas le chiffrement StartTLS, mais plutôt ldaps (SSL).

Il faut l'activer dans /etc/default/slapd en ajoutant ldaps:/// à la ligne SLAPD_SERVICES:

<pre>

sudo vi /etc/default/slapd

</pre>

<pre>

# slapd normally serves ldap only on all TCP-ports 389. slapd can also

# service requests on TCP-port 636 (ldaps) and requests via unix

# sockets.

# Example usage:

# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"

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

</pre>

<pre>

sudo /etc/init.d/slapd restart

</pre>

On peut maintenant se connecter à l'annuaire avec ldaps sur le port 636.

*Copies d'écran dans ADS*

!http://www.illyse.org/attachments/download/25/dirstudio-ldap-install2.PNG!

!https://www.illyse.org/attachments/download/215/dirstudio-ldap-install3.PNG!

*Modification des ACL*

On va maintenant modifier les ACL pour forcer les connexions chiffrées. (On ne peut empêcher complètement les connexions sans chiffrement/authentification, mais on fait en sorte que ces connexions n'aient aucun droit sur l'annuaire, pas même en consultation.)

Pour cela, on utilise le Security Strength Factor (SSF) en ajoutant "ssf=128" devant les portions des ACL indiquant à qui s'applique tel ou tel droit.

Au passage, on supprime les références à cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR: ce dn étant défini dans olcDatabase={1}hdb,cn=config par l'attribut olcRootDN, ses droits administrateur sont implicites.

+Configuration modifiée+

<pre>

olcAccess: {0}to attrs=userPassword,shadowLastChange by ssf=128 self write by anonymous auth by users none by * none

olcAccess: {1}to dn.base="" by * read

olcAccess: {2}to * by ssf=128 self write by users none by * none

</pre>

FIXME: passer à ssf=256 si possible. A ce jour, lorsqu'on se connecte avec un certificat client, on obtient seulement ssf=128, ce qui suggère que l'on pourrait utiliser de meilleurs algos de chiffrement (au niveau de la [[PKI]]?). A creuser.

h1. Peuplement de l'annuaire

La configuration terminée, on peut maintenant se consacrer aux données.

On privilégiera désormais les connexions TLS.

*Création de la racine des données*

_Se connecter en tant que cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR._

Pour l'instant, la branche de données de l'annuaire est encore vide. On va maintenant créer sa première entrée, o=ILLYSE,l=Villeurbanne,st=RHA,c=FR. Cette entrée est dite _context entry_. Elle définit le contexte de nommage de la branche des données, dont elle est la racine.

Dans Apache Directory Studio, clic-droit sur l'objet Root DSE / Nouveau / Nouvelle context entry.

Une boite de dialogue apparaît. Choisir:

* créer l'entrée à partir de zéro

* object class: organization (la classe top est ajoutée automatiquement au passage)

* DN de la context entry: o=ILLYSE,l=Villeurbanne,st=RHA,c=FR

*Unités organisationnelles*

_En tant que cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR._

Habituellement, les données sont organisée en plusieurs _Organizational Units_. Ce sont les branches principales de l'annuaire. Cette organisation peut posséder plusieurs niveaux.

Pour créer une structure classique, nous allons créer dans l'arborescence, sous l'objet parent o=ILLYSE,l=Villeurbanne,st=RHA,c=FR, deux nouveaux objets de classe organizationalUnit.

Pour créer ces deux objets dans Apache Directory Studio, clic-droit sur o=ILLYSE,l=Villeurbanne,st=RHA,c=FR / Nouveau / Nouvelle entrée.

* créer l'entrée à partir de zéro

* classe organizationalUnit. La classe parente top est automatiquement ajoutée.

* RDN=ou. Cela définit la "clé" de l'objet qui fera partie de son nom complet, le DN (Distinguished Name, par exemple "ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR").

* ou: groups ou users, voir ci-dessous

Exports LDIF:

* Comptes d'utilisateurs

<pre>

dn: ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR

objectClass: organizationalUnit

objectClass: top

ou: users

</pre>

Une fois la première unité organisationnelle créée, ADS offre la possibilité de l'utiliser comme modèle pour créer la suivante.

On peut aussi faire un simple copier-coller dans l'arborescence. ADS proposera de renommer l'objet collé.

* Groupes

<pre>

dn: ou=groups,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR

objectClass: organizationalUnit

objectClass: top

ou: groups

</pre>

Ultérieurement, on pourra créer d'autres unités organisationnelles à la racine de l'annuaire, pour stocker les zones DNS, le routage du courrier électronique, la config DHCP, etc.

_Note/nomenclature: j'ai arbitrairement et unilatéralement décidé de bannir les majuscules des DN de l'annuaire. P.-A._

*Premier utilisateur*

Sous ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR, on crée un nouvel objet:

* classes inetOrgPerson -et shadowAccount- (les autres sont ajoutées automatiquement)

* RDN=cn (la clé)

* uid=jdupont

* cn=jdupont

* sn=Dupont

(clic-droit/nouvel attribut)

* givenName=Jean

(clic-droit/nouvel attribut)

* displayName=Jean Dupont

(clic-droit/nouvel attribut)

* userPassword: l'interface de DS permet de générer un hachage (équivalent de slappasswd en ligne de commande). On utilisera l'algorithme SSHA.

Cet objet est laissé intentionnellement minimaliste. Il sera possible d'ajouter ultérieurement d'autres attributs et classes, selon les besoins.

LDIF

<pre>

dn: cn=jdupont,ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

objectClass: top

cn: jdupont

sn: Dupont

uid: jdupont

displayName: Jean Dupont

givenName: Jean

userPassword:: e1A5Eb8...

</pre>

*Premier groupe*

Sous ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR, on crée un nouvel objet:

* classe posixGroup

* RDN=cn

* cn=admin

* gidNumber=99 (peu importe, pour l'instant on ne cherche pas a créer des utilisateurs unix)

Pour ajouter l'utilisateur au groupe, afficher l'entrée que l'on vient de créer (cn=admin,ou=groups,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR) et ajouter un nouvel attribut (clic-droit...) memberUid=jdupont.

LDIF

<pre>

dn: cn=admin,ou=groups,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR

objectClass: posixGroup

objectClass: top

cn: admin

gidNumber: 99

memberUid: jdupont

</pre>

*Test*

Il est maintenant possible de se connecter en tant que uid=jdupont,ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR, (fabs : j'ai utilisé cn=jdupont,ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR car ca ne marchait pas avec uid) avec le mot de passe saisi, et le contrôle d'accès est bien appliqué:

* on peut modifier ses propres données personnelles (nom, prénom, mdp, etc...) (nécessite de forcer le DN de base à cn=jdupont,ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR, dans la fenêtre de connexion d'ADS, onglet Options du navigateur).

* on ne voit pas le reste de l'annuaire

*Copie d'écran dans ADS*

!http://www.illyse.org/attachments/download/27/dirstudio-ldap-install4.PNG!