Journal LDAP, un peu de technique.

Sommaire

• Une histoire de schéma.
  • Des attributs…
  • …et des objets
• Configuration de slapd.
  • Écriture d'un fichier slapd.conf
• Peupler une base LDAP
  • Premiers objets.
  • Ajout d'objets plus concrets, modifications.
• De la doc, encore de la doc.

Dans mon journal d'hier, je parlais de LDAP d'un point de vue utilités. Je propose ici de se plonger un peu plus dans le côté technique.

Comme référence, j'utilise l'installation et la configuration du paquet slapd sous debian, nul doute que cela marchera à d'autres endroits sur d'autres OS. Installez donc slapd, et ldap-tools.

Une histoire de schéma.

Avant de se plonger dans une partie configuration du serveur LDAP proprement dit, nous allons revenir sur ces histoires de schéma LDAP. Chez moi, les schémas par défaut se trouvent dans /etc/ldap/schema. Ils ne sont pas « préchargés » automatiquement, la configuration prise en compte se trouve dans /etc/ldap/slapd.d, mais ils permettent de comprendre un peu ce qu'il se passe.

Des attributs…

Bon, ce titre fait un peu cliffhanger de derrière les fagots… Passons. Une base LDAP sert à stocker des objets, inscrits dans des nœuds, ayant parent et enfants. Les propriétés d'un objet dépendent de celui-ci. Ici, avant de nous intéresser à l'objet proprement dit, on va se pencher sur les attributs. (on peut ce référer à cette page web pour plus d'informations)

Dans l'ancien format des bases LDAP, pour les schémas, les attributs se représentaient de la façon suivante :

attributetype ( 1.3.6.1.1.1.1.2 NAME 'gecos'
    DESC 'The GECOS field; the common name'
    EQUALITY caseIgnoreIA5Match
    SUBSTR caseIgnoreIA5SubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

Vous croiserez cet attribut dans /etc/ldap/schema/nis.schema.

• attributetype signifie qu'on déclare un attribut, tout ce qui suit se trouve entre parenthèses.
• La suite de numéros bizarres est un OID, un identifiant unique, qui permet de représenter votre attribut. Une des spécificités de LDAP est de proposer de le voir comme un arbre mondial, la racine de votre base serait donc virtuellement un des enfants d'un arbre LDAP imaginaire qui serait la propriété des gourous de LDAP. L'identifiant en question permettrait de dire "cet attribut est l'attribut numéro 2 du schéma nis".
• NAME 'nom' définit le nom de l'attribut, on s'y réfère ainsi par la suite. Il est préférable pour la lisibilité de se limiter aux caractères ASCII.
• DESC 'description' est une description de l'attribut. Dans la mesure du possible, on se limite aux caractères ASCII.
• EQUALITY compMethod définit une méthode de comparaison pour l'égalité, c'est une contrainte implicite pour dire que notre attribut est un entier, ou une chaîne de caractère ou autre chose…
• SUBSTR compMethod propose la même chose que EQUALITY, mais pour un sous-ensemble de l'attribut (chercher "coucou" dans la phrase "coucou, comment vas-tu ?" par exemple).
• SYNTAX PLEIN.DE.CHIFFRES définit une contrainte sur la variable. La suite de chiffre est un OID qui pointe vers un type d'attribut précis. Par exemple, si vous utilisez SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{123}, vous définissez une chaîne de caractère quasi-ASCII de longueur maximale 123 caractères. Si vous essayez de définir un attribut avec cette syntaxe et de balancer un "é" dedans, LDAP vous inondera de son amour et de sa croyance en vos capacités de leader religieux.
• SINGLE-VALUE signifie que l'attribut est monovalué. Autrement dit, un objet ne peut avoir deux gecos. Il n'en a au plus qu'un.

Référez-vous au lien que je vous ai fourni pour plus d'informations.

Pourquoi vous parler de l'ancienne syntaxe si elle n'est justement plus d'actualité ? Parce que la nouvelle syntaxe correspond aux schémas définis directement dans la base LDAP de configuration, qu'elle diffère peu de l'ancienne, et que lorsqu'on crée sa base LDAP, et qu'on la configure pour la première fois, créer un schéma dans un fichier puis le faire incorporer dans la base via la commande slaptest est bien plus agréable et facile.

La nouvelle syntaxe est une syntaxe compatible avec ldif, voici le même attribut dans cette syntaxe.

olcAttributeTypes: ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; the common name' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

C'est très proche de l'ancienne syntaxe, mais compatible avec ldif. Regardez nis.ldif en comparaison avec nis.schema.

…et des objets

Une fois qu'on a nos attributs, on souhaite créer des objets. Toujours dans nis, regardez en bas du fichier.

objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount'
    DESC 'Abstraction of an account with POSIX attributes'
    SUP top AUXILIARY
    MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
    MAY ( userPassword $ loginShell $ gecos $ description ) )

Et en nouvelle syntaxe :

olcObjectClasses: ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' DESC 'Abstraction of an account with POSIX attributes' SUP top AUXILIARY MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) )

• objectclass signifie qu'on déclare un objet.
• L'OID est également unique, comme pour les attributs
• NAME définit toujours un nom, si possible avec des caractères ASCII exclusivement
• DESC décrit l'objet
• SUP définit un objet parent (celui qu'on définit hérite de ses propriétés)
• La déclaration AUXILIARY est plus compliquée. Ici, on peut écrire STRUCTURAL, AUXILIARY ou ABSTRACT. Lorsqu'on crée un nœud et lui donne des informations, parmi les attributs objectClass, qui vont définir quels autres attributs un objet peut avoir, il doit y avoir un (et un seul) objectClass pointant vers un élément STRUCTURAL, et autant que l'on souhaite vers des éléments AUXILIARY, ou ABSTRACT. Un élément ne peut hériter que d'un élément du même type, ou d'un ABSTRACT. Donc un élément AUXILIARY ne peut pas hériter d'un STRUCTURAL, et réciproquement. Les éléments STRUCTURAL représentent des objets concrets. Ici, posixAccount est AUXILIARY : un objet ne pourra pas être juste un posixAccount.
• MUST ( attributs séparés par des $ ) indique la liste des attributs qu'un objet doit posséder en au moins un exemplaire.
• MAY ( attributs séparés par des $ ) indique les attributs supplémentaires qu'un objet peut posséder.

Voilà pour les schémas, une fois ceci compris, imaginons qu'en plus des éléments dans nis, on ait défini un schéma personnel avec cet objectClass :

olcObjectClasses: ( 1.2.3.1.2.3.1.2.3.10 NAME 'userAccount' DESC 'Implementation of a user account' SUP top STRUCTURAL MUST ( fname $ name ) MAY ( mail $ town ) )

Avec mail, town, name et fname des attributs définissant email, ville, nom et prénom.

Un compte d'utilisateur pourrait alors être l'objet avec les attributs :

dn: uid=peb,ou=users,dc=localdomain
objectClass: userAccount
objectClass: posixAccount
cn: PEB
fname: PE
gidNumber: 100
homeDirectory: /home/peb
loginShell: /bin/zsh
mail: peb@yopmail.com
name: B
uid: peb
uidNumber: 2573
userPassword: {SSHA}Sdduv35Y4x/49FeFmrroxXXlrpgff

La syntaxe ici est celle de LDIF. On y reviendra, mais vous savez désormais à quoi ressemblent les objets dans une base LDAP.

Configuration de slapd.

Ça va vous sembler extrême, mais la première chose à faire après avoir installé slapd est cette série de commandes.

# /etc/init.d/slapd stop
# rm -rf /etc/ldap/slapd.d/*
# rm -rf /var/lib/ldap/[^D]*

On va démarrer avec un environnement propre, et faire une configuration nous-même. Il est possible que la configuration initiale vous ait convenu, mais l'objectif est de comprendre ce qu'il se passe.

Écriture d'un fichier slapd.conf

Je vous propose ici de construire notre fichier /etc/ldap/slapd.conf, je vais partir sur un exemple simple, mais n'hésitez pas à l'aide de la documentation à rendre le votre plus complet, et adapté à vos envies.

#######################################################################
# Directives globales:

# Définition des schémas et objectClasses
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/dyngroup.schema
include         /etc/ldap/schema/perso.schema

Ici, on commence par inclure les schémas prééexistants qui peuvent servir, et notre schéma personnel.

# Emplacement du pidfile
pidfile         /var/run/slapd/slapd.pid

# Arguments passés au serveur
argsfile        /var/run/slapd/slapd.args

# Niveau de journalisation
loglevel        0

Ensuite, quelques configurations basiques, pour les besoins du logiciel. loglevel 0 signifie qu'on le loggue rien dans syslog. Regardez loglevel dans la manpage de slapd.conf pour plus d'infos. Un bon niveau de logging quand on fait du débug est 255, mais attention, c'est extrêmement verbeux, et un serveur limité en ressources se fait souvent overloader par ce niveau de logging. (testé et désapprouvé sur un domu)

# Stockage des modules
modulepath      /usr/lib/ldap
moduleload      back_bdb

On définit ici le répertoire des modules, et on charge back_bdb, qui fournit le type de base LDAP "Berkley DB", que j'aime bien.

# Limitation du nombre de réponses
sizelimit       1000000000

Limite du nombre d'objets que la base peut simultanément retourner.

# Méthode pour crypter les mots de passe
password-hash   {SSHA}

###############################################################
# Directives de configuration pour le backend bdb
backend         bdb

Ici, on précise type de backend pour lequel les options à venir s'appliquent. Comme il n'y a pas d'autre option, je ne suis pas convaincu que ça soit utile.

#######################################################################
# Configuration de la base de données principale
database        bdb

Ici, on déclare une nouvelle base de données, de type Berkley DB, tout ce qui suivra jusqu'à une autre déclaration générale concerne cette base. Certaines directives sont spécifiques au backend, comme on peut le voir ici.

# Racine
suffix          "dc=localdomain"

Nom du nœud racine.

# Répertoire de stockage de la base de données
directory       "/var/lib/ldap"

(Backend-dependant) Il peut être plus adapté lorsqu'on souhaite créer plusieurs bases de données de les mettre dans des répertoires distincts, il faut pour cela que le backend le permette.

# Options d'indexation pour la base de données
index           entryUUID,entryCSN eq
index           objectClass,uid,uidNumber eq
index           cn,sn eq,approx,sub
index           mail,town eq
index           name,fname eq,approx,sub

(Backend-dependant) Les index ont à peu près les mêmes utilités que pour une base SQL par exemple : diminuer le temps de processing pendant les recherches. Les index sont créés à l'ajout d'un objet dans la base ldap, ou à la modification des attributs sur lesquels ils sont placés.

# Sauvegarde des timestamps de modifications des objets
lastmod         on

# LDAP a besoin de la déclaration du rootdn
rootdn "cn=admin,dc=localdomain"
rootpw "{SSHA}HASH"

Ici, on définit l'administrateur de la base, avec pour mot de passe un hash. Pour générer un ssha à partir d'un mot de passe, utilisez la commande slappasswd, et collez sa sortie à la place de "{SSHA}HASH".

# L'attribut userPassword doit pouvoir être écrit uniquement par
# soi-même, l'admin, les replicas. Dovecot peut le lire, et on peut
# s'authentifier avec anonymement

access to attrs=userPassword
       by dn.regex="cn=dovecot,dc=localdomain" read
       by anonymous auth
       by self write
       by * none

# Permettre l'accès à la base pour des trucs comme 
# "supportedSASLMechanisms", pour éviter des problèmes
# possibles si les méthodes SASL ne sont pas connues.
access to dn.base="" by * read

# Pour postfix
access to dn.regex="^uid=[0-9]+,ou=users,dc=localdomain$$" attrs=mail,alias,uid,mail,entry,objectClass
       by dn.regex="cn=postfix,dc=localdomain" read
       by * break

# Pour dovecot
access to dn.regex="^uid=[0-9]+,ou=users,dc=localdomain$$" attrs=uid,homeDirectory,uidNumber,gidNumber,userPassword,objectClass,entry
       by dn.regex="cn=dovecot,dc=localdomain" read
       by * break

# Informations accessibles à tous
access to dn.regex="^uid=[0-9]+,ou=users,dc=localdomain$$" attrs=uid,homeDirectory,uidNumber,gidNumber,gecos,objectClass,entry
       by anonymous read
       by * break

access to dn="ou=users,dc=localdomain"
       by anonymous search
       by * break

access to dn.subtree="ou=Group,dc=linkki,dc=crans,dc=org"
       by anonymous read
       by * break

# L'admin et readonly peuvent tout lire 
# can read everything.
access to *
       by dn.regex="cn=admin,dc=localdomain" write
       by sockname.regex="ldapi" read
       by dn.regex="cn=readonly,dc=localdomain" read
       by self read
       by * none

Ici, on configure les acl. Ils ne sont pas dépendants du backend, comme c'est un des points les plus techniques de LDAP, j'en reparlerai dans un journal séparé, après avoir pu faire mon lot de tests.

Vous noterez que ça parle de dovecot et postfix, l'idée est de montrer un cas où on va créer des utilisateurs administratifs de LDAP pour dovecot et postfix à des fins d'interfaçage.

Voilà, la configuration est finie, votre fichier slapd.conf est prêt.

Il ne reste qu'à exécuter la commande

# sudo -u openldap slaptest -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d

Il est possible que slaptest vous sorte une erreur, due au fait que id2entry.bdb n'existe pas, c'est normal, puisqu'on avait fait le ménage, mais la configuration est bien faite. Faites

# /etc/init.d/slapd start

Votre base LDAP tourne (et id2entry a été créé), mais… est vide.

Peupler une base LDAP

On y est, on va ici apprendre à ajouter des données, donc à créer des petits fichiers au format LDIF, puis à utiliser ldapadd, voire ldapmodify. Une fois cela fait, on arrêtera ici pour cette initiation. Un journal parlera des ACL, et un autre de la modification à chaud du schéma, des configs, et la réplication.

Premiers objets.

Il faut créer le nœud racine, et nous allons en plus créer deux nœuds, ou=groups, et ou=users. Lorsqu'on souhaite ajouter des objets, la syntaxe ldif est très simple, il suffit de donner l'ensemble des informations concernant les divers objets, séparés par des lignes vides. Avant chaque :, on a le nom d'attribut, et après, une espace puis la valeur de l'attribut.

dn: dc=localdomain
objectClass: top
objectClass: dcObject
objectClass: organization
dc: localdomain
o: localdomain

dn: ou=users,dc=localdomain
objectClass: top
objectClass: organizationalUnit
ou: users

dn: ou=groups,dc=localdomain
objectClass: top
objectClass: organizationalUnit
ou: groups

On enregistre ces lignes dans un fichier /tmp/begin.ldif, puis on effectue la commande

$ ldapadd -H ldap://127.0.0.1 -D "cn=admin,dc=localdomain" -W -f /tmp/begin.ldif

• -H permet d'indiquer l'hôte à contacter.
• -D permet de préciser l'utilisateur avec lequel on effectue l'opération
• -W signifie qu'on entre le mot de passe de l'utilisateur en command line
• -f permet de préciser un fichier (sinon, on utilise l'entrée standard)

Tapez le mot de passe de votre admin ("Plop", chez moi), et le tour est joué.

Ajout d'objets plus concrets, modifications.

Vous devriez, via ldapadd, et un fichier, pouvoir créer un utilisateur voisin de celui que j'avais proposé ci-dessus.

dn: uid=peb,ou=users,dc=localdomain
objectClass: userAccount
objectClass: posixAccount
cn: PEB
fname: PEB
gidNumber: 100
homeDirectory: /ghome/peb
loginShell: /sbin/zsh
mail: peb@yopmail.com
name: B
uid: peb
uidNumber: 2573
userPassword: {SSHA}Sdduv35Y4x/49FeFmrroxXXlrpgff

Malheureusement, comme vous l'avez sûrement constaté, je suis très mauvais pour copier/coller, et des erreurs de scénario se sont glissées dans l'utilisateur. Apprenons maintenant à les corriger.

La syntaxe change quelque peu, puisqu'on va devoir utiliser ldapmodify : il faut préciser le dn de l'objet à modifier, puis le type de changement à lui apporter. Pour une zoologie des types de changements, se rendre ici. Ensuite, il faut préciser les attributs que l'on modifie. On sépare les modifications par des lignes contenant juste un tiret d'union.

dn: uid=peb,ou=users,dc=localdomain
changetype: modify
replace: prenom
prenom: PE
-
delete: homeDirectory
homeDirectory: /ghome/peb
-
add: homeDirectory
homeDirectory: /home/peb
-
delete: loginShell
-
add: loginShell
loginShell: /bin/zsh

• add ajoute un ou plusieurs attributs de même type.
• delete en efface un ou plusieurs s'ils sont spécifiés (cf homeDirectory), tous si on se contente d'annoncer un delete: loginShell, par exemple.
• Pour remplacer un attribut par un autre, on peut l'effacer, et en ajouter un nouveau, ou alors utiliser replace, qui remplace tous les attributs par la même valeur.

Les trois méthodes possibles pour faire des corrections ont été utilisées ci-dessus. On sauvegarde ce LDIF dans /tmp/modif.ldif, et on appelle alors la commande

$ ldapmodify -H ldap://127.0.0.1 -D "cn=admin,dc=localdomain" -W -f /tmp/modif.ldif

On donne le mot de passe, et le tour est joué.

Pour effacer des entrées, on peut utiliser ldapdelete, ou ldapmodify avec le changetype delete.

De la doc, encore de la doc.

• Zytrax, toujours aussi complet
• OpenLdap, toujours gérants du projet openldap
• Google, et vos amis.

Bonne lecture. :o)