OpenLDAP - Personalisation du schéma

Création d'un schéma personnalisé

Dans cet article, nous allons créer un schéma personnalisé. Nous utiliserons l'héritage pour simplifier le schéma, via le biais de définitions génériques. Le scénario utilisé permet de comprendre les différents composants et leurs intéractions, tout en se conformant aux best practices avec cependant quelques entorses, à des fins pédagogiques.

Nous allons partir d'un exemple simple: Une entreprise de fabrique de jouets possède 3 ateliers de fabrication, chacun fabricant des jouets différents (peluches, jouets en bois, etc.). Nous souhaitons référencer les produits fabriqués, les matières premières utilisées et les fournisseurs. Ce que nous souhaitons définir, ce sont les ateliers avec le(s) responsable(s) de production, les produits, avec pour chacun, les quantités en stock, les seuil minimum et maximum de stock, la/les couleurs du jouet, le prix unitaire. Les matières première permettent de référencer les matériaux, avec les stock disponible et les founisseurs, incluant les délai de livraison et les contacts.

Nous utiliserons l'héritage pour simplifier le schéma, via le biais de définitions génériques. Nous ajouterons également un peu de contraintes à ce schéma. Commençons par notre en-tête:

dn: cn=custom,cn=schema,cn=config
ObjectClass: top
ObjectClass: olcConfig
ObjectClass: olcSchemaConfig
cn: custom

Nous utiliserons la branche expérimentale pour nos OID. Définissons quelques alias pour rendre la suite plus compréhensible:

olcObjectIdentifier: CustomRoot 1.3.6.1.3
olcObjectIdentifier: Custom CustomRoot:1
olcObjectIdentifier: CustomAttributeType CustomRoot:1
olcObjectIdentifier: CustomObjectClass CustomRoot:2
olcObjectIdentifier: CustomAttributeTypeGen CustomAttributeType:1
olcObjectIdentifier: CustomAttributeTypeDef CustomAttributeType:2
olcObjectIdentifier: CustomObjectClassGen CustomObjectClass:1
olcObjectIdentifier: CustomObjectClassDef CustomObjectClass:2

On créé des définitions génériques:

olcAttributeTypes: ( CustomAttributeTypeGen:1 NAME 'custom-DNGeneric' DESC 'Generic DN based attributes' EQUALITY distinguishedNameMatch SYNTAX OMsDN)
olcAttributeTypes: ( CustomAttributeTypeGen:2 NAME 'custom-ia5Generic' DESC 'Generic IA5 String' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX OMsIA5String)
olcAttributeTypes: ( CustomAttributeTypeGen:3 NAME 'custom-utf8Generic' DESC 'Generic Directory String' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch ORDERING caseIgnoreOrderingMatch SYNTAX OMsDirectoryString)
olcAttributeTypes: ( CustomAttributeTypeGen:4 NAME 'custom-BoolGeneric' DESC 'Generic Boolean attribute' EQUALITY booleanMatch SYNTAX OMsBoolean SINGLE-VALUE)
olcAttributeTypes: ( CustomAttributeTypeGen:5 NAME 'custom-numGeneric' DESC 'Generic numeric attribute' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX OMsInteger{16} )
olcObjectClasses: ( CustomObjectClassGen:1 NAME 'custom-StructuralGeneric' SUP custom-top DESC 'Generic structural object' STRUCTURAL MAY ( displayName $ description )

et enfin nos définitions, on commence par définir notre classe abstraite:

olcObjectClasses: ( CustomObjectClassDef:1 NAME 'custom-top' DESC 'top of our custom superclass chain' ABSTRACT MUST objectClass MAY ( description $ custom-comment ) )

Les définitions d'attributs:

olcAttributeTypes: ( CustomAttributeTypeDef:1 NAME 'custom-RefId' DESC 'Reference Identifier' SUP custom-numGeneric SINGLE-VALUE )
olcAttributeTypes: ( CustomAttributeTypeDef:2 NAME 'custom-comment' DESC 'Any comment about this object' SUP custom-utf8Generic )
olcAttributeTypes: ( CustomAttributeTypeDef:3 NAME 'custom-color' DESC 'toy s color' SUP custom-numGeneric )
olcAttributeTypes: ( CustomAttributeTypeDef:4 NAME 'custom-stock' DESC 'number in stock' SUP custom-numGeneric SINGLE-VALUE )
olcAttributeTypes: ( CustomAttributeTypeDef:5 NAME 'custom-stockMax' DESC 'Unit max in stock' SUP custom-numGeneric SINGLE-VALUE )
olcAttributeTypes: ( CustomAttributeTypeDef:6 NAME 'custom-stockMin' DESC 'Unit min in stock' SUP custom-numGeneric SINGLE-VALUE )
olcAttributeTypes: ( CustomAttributeTypeDef:7 NAME 'custom-age' DESC 'age of use' SUP custom-ia5Generic )
olcAttributeTypes: ( CustomAttributeTypeDef:8 NAME 'custom-Unit' DESC 'Unit basis' SUP custom-utf8Generic SINGLE-VALUE )
olcAttributeTypes: ( CustomAttributeTypeDef:9 NAME 'custom-Delay' DESC 'procurement lead time' SUP custom-utf8Generic SINGLE-VALUE )
olcAttributeTypes: ( CustomAttributeTypeDef:10 NAME 'custom-ppu' DESC 'Price per Unit' SUP custom-numGeneric SINGLE-VALUE )
olcAttributeTypes: ( CustomAttributeTypeDef:11 NAME 'custom-availability' DESC 'Availability of the reference' SUP custom-BoolGeneric )
olcAttributeTypes: ( CustomAttributeTypeDef:12 NAME 'custom-foreman' DESC 'chief workshop' SUP custom-DNGeneric SINGLE-VALUE )
olcAttributeTypes: ( CustomAttributeTypeDef:13 NAME 'custom-contact' DESC 'Supplier contact' SUP custom-utf8Generic )

les définitions de classes d'objet:

olcObjectClasses: ( CustomObjectClassDef:1 NAME 'custom-top' DESC 'top of our custom superclass chain' ABSTRACT MUST objectClass MAY ( description $ custom-comment ) )
olcObjectClasses: ( CustomObjectClassGen:1 NAME 'custom-StructuralGeneric' SUP custom-top DESC 'Generic structural object' STRUCTURAL MAY ( displayName $ description ) )
olcObjectClasses: ( CustomObjectClassDef:2 NAME 'custom-RefObj' DESC 'Enforce a reference' SUP custom-StructuralGeneric MUST custom-RefId )
olcObjectClasses: ( CustomObjectClassDef:3 NAME 'custom-Product' DESC 'Product définition' SUP custom-RefObj MUST custom-availability )
olcObjectClasses: ( CustomObjectClassDef:4 NAME 'custom-RawMaterials' SUP custom-RefObj )
olcObjectClasses: ( CustomObjectClassDef:5 NAME 'custom-Workshop' SUP custom-StructuralGeneric MUST custom-foreman )
olcObjectClasses: ( CustomObjectClassDef:6 NAME 'custom-Supplier' SUP custom-StructuralGeneric MUST custom-contact)
olcObjectClasses: ( CustomObjectClassDef:7 NAME 'custom-SecondaryData' SUP custom-top AUXILIARY MAY ( custom-color $ custom-stock $ custom-stockMax $ custom-stockMin $ custom-age $ custom-Unit $ custom-Delay $ custom-ppu ) )

Voilà pour la définition des objects. Maintenant il nous faut un peu de contraintes. Ajoutons quelques règles de contenu:

olcDitContentRules: ( CustomObjectClassDef:3 NAME 'dcr-Product' DESC 'custom-Product may only be members of the custom-SecondaryData aux class' AUX 1.3.6.1.3.1.2.2.7 NOT ( 1.3.6.1.3.1.1.2.9 $ 1.3.6.1.3.1.1.2.10) )
olcDitContentRules: ( CustomObjectClassDef:4 NAME 'dcr-RawMaterials' DESC 'custom-RawMaterials may only be members of the custom-SecondaryData aux class' AUX 1.3.6.1.3.1.2.2.7 MUST 1.3.6.1.3.1.1.2.4 MAY ( 1.3.6.1.3.1.1.2.9 $ 1.3.6.1.3.1.1.2.5 $ 1.3.6.1.3.1.1.2.6 ) NOT 1.3.6.1.3.1.1.2.8 )
olcDitContentRules: ( CustomObjectClassDef:5 NAME 'dcr-Workshop' DESC 'custom-Workshop may only be members of the custom-SecondaryData aux class' AUX 1.3.6.1.3.1.2.2.7 MUST 1.3.6.1.3.1.1.2.9 NOT ( 1.3.6.1.3.1.1.2.3 $ 1.3.6.1.3.1.1.2.4 $ 1.3.6.1.3.1.1.2.5 $ 1.3.6.1.3.1.1.2.6 $ 1.3.6.1.3.1.1.2.7 $ 1.3.6.1.3.1.1.2.8 ) )
olcDitContentRules: ( CustomObjectClassDef:6 NAME 'dcr-Supplier' DESC 'custom-Supplier may only be members of the custom-SecondaryData aux class' AUX 1.3.6.1.3.1.2.2.7 MAY 1.3.6.1.3.1.1.2.9 NOT ( 1.3.6.1.3.1.1.2.3 $ 1.3.6.1.3.1.1.2.4 $ 1.3.6.1.3.1.1.2.5 $ 1.3.6.1.3.1.1.2.6 $ 1.3.6.1.3.1.1.2.7 $ 1.3.6.1.3.1.1.2.8 ) )

OpenLdap ne gère pas les règles de structure, mais permet de les gérer similairement via les ACL étendues (pensez à ajouter olcAddContentAcl à votre base):

Pour cela, définissons l'arborescence suivance:

dc=uuub,dc=fr

  \_ o=Enterprise

      \_ cn=<workshop>

          \_ cn=<product>

Ce que nous souhaitons, c'est que chaque atelier soit géré par son responsable, et que ce dernier puisse créer et gérer les jouets qui y sont fabriqués, sous cet atelier.

olcAccess: to dn.baseobject="o=Enterprise,dc=uubu,dc=fr" attrs="children" by group/groupOfMembers/member="cn=Admins,dc=uubu,dc=fr" write by users read by * none break
olcAccess: to dn.onelevel="o=Enterprise,dc=uubu,dc=fr" filter="(objectClass=custom-Workshop)" attrs="entry,@custom-Workshop,@custom-SecondaryData" by group/groupOfMembers/member="cn=Admins,dc=uubu,dc=fr" write by users read by * none break
olcAccess: to dn.regex="^(cn=[^,]+),o=Enterprise,dc=uubu,dc=fr$" filter="(objectClass=custom-Workshop)" attrs=entry,@custom-Workshop,@custom-SecondaryData by set="this/custom-foreman & user" write by users read by * none break
olcAccess: to dn.regex="^(cn=[^,]+),o=Enterprise,dc=uubu,dc=fr$" filter="(objectClass=custom-Workshop)" attrs="children" by set="this/custom-foreman & user" write by * read break
olcAccess: to dn.regex="^cn=([^,]+),(cn=[^,]+,o=Enterprise,dc=uubu,dc=fr)$" filter="(objectClass=custom-Product)" attrs="entry,@custom-Product,@custom-SecondaryData" by group/custom-Workshop/custom-foreman.expand="$2" write by users read by * none
 

Attention à l'utilisation des expressions régulières gourmandes en ressources, et les sets encore considérés comme expérimentaux. Je vais m'arrêter là, les autres règles de structure sont calqués sur celles-ci et ne devraient pas poser de problème.

Comme vous pouvez le remarquer, les règles de structure sont beaucoup plus souple que les acl, mais sont moins précises. Ainsi, là où une règle de structure est définis pour tout le DIT, des acls différentes peuvent être définis pour différentes sous-arborescence. Autre avantage des acls: on gère également les droits dans la foulée, mais ce n'est pas sans une complexité accrue.

Voilà, pour cette article. Je vais consacrer un article dédié aux ACLs et à la délégation.

OpenLDAP - le Schéma

Définition d'un schéma de base pour OpenLDAP

Dans cet article, je vais faire une présentation sommaire du schéma embarqué, et des différents schémas standards utiles afin de se familiariser avec le schéma LDAP.

Intéressons nous d'abord au schéma embarqué:

OpenLDAP contient tout d'abord les définitions d'attributs et de classes d'objet destinées à sa propre configuration. Préfixés avec 'olc', ils servent à la configuration globale, au schéma, modules et bases de données.

Les autres définitions d'attributs présentes sont nécessaires au fonctionnement interne de l'annuaire, dont un certain nombre d'attributs opérationnels. On trouve logiquement la rfc4512, le userPassword de la rfc4519, et quelques autres définitions issues d'autres standards. On peut retrouver ces définitions dans les sources d'OpenLdap: les attributs de configuration du serveur dans servers/slapd/bconfig.c, les attributs dynamique dans servers/slapd/schema_prep et les autres attributs dans servers/slapd/schema_init.c.

À noter la présence de la classe top, mère de tous les autres.

Ici, nous allons définir un schéma, basé sur les standards, rfc par rfc. Les définitions étant contraintes par les dépendances, je les décris dans l'ordre d'importation.

rfc4512

Comme indiqué plus haut, ce schéma est inclus entièrement dans le schéma embarqué, puisqu'il décrit tous les objets de base, objectClass, attributeTypes, alias, dITContentRules, etc.

rfc4519

cn, description, distinguishedName, name, seeAlso, uid, usedPassword sont déjà embarqués. Cette rfc définis un schéma pour les applications utilisateurs, il y est définis les classes d'objet person, organizationalPerson, organizationalRole, organizationalUnit, residentialPerson, uidObject, organization, dcObject, groupOfNames, groupOfUniqueNames et quelques autres.

dcObject et organization sont intéressants puisqu'ils peuvent être utilisés dans la racine d'un contexte de nommage. dcObject ne possède qu'un attribut: dc

olcAttributetypes: ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

olcObjectClasses: ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc )

organization est plus complet:

olcObjectClasses: ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )

rfc4524

Ce standard définis des éléments utiles pour les comptes machines, la gestion de documents, et une autre classe qui peut être utilisé pour notre contexte de nommage: domain, qui définis une entrée représentant un domaine DNS.

olcObjectClasses: ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL MUST dc MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $   preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $   internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $   physicalDeliveryOfficeName $ st $ l $ description $ o $ associatedName ) )

Point intérressant de cette classe, elle rassemble les attributs de dcObjet et organization et est plus orientée grandes entreprises.

rfc3112

Ce standard n'est pas pris en charge par OpenLDAP. Il définis en effet authPassword, non géré par le serveur. Cependant, pour que posixAccount soit conforme à la rfc2307, cet attribut doit être définis. Vu que la règle de correspondance n'est pas définie dans OpenLDAP, nous ne pouvons le définir comme tel. À la place, définissons le comme userPassword, et désactivons le:

olcAttributeTypes: ( 1.3.6.1.4.1.4203.1.3.4 NAME 'authPassword' DESC 'password authentication information' OBSOLETE EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
olcObjectClasses: ( 1.3.6.1.4.1.4203.1.4.7 NAME 'authPasswordObject' DESC 'authentication password mix in class' OBSOLETE AUXILIARY MAY authPassword )

rfc2307bis02

le schéma de mappage unix NIS. uidNumber et gidNumber sont déjà dans de schéma embarqué. Ce schéma est utilisé pour que les utilisateurs puissent s'authentifier sur les machines avec un compte dans l'annuaire.

rfc2589

Les extensions pour les services d'annuaire dynamique. Ces définitions sont présente dans le schéma embarqué et gérés par l'overlay dds

rfc3671

Les définitions pour les attributs collectifs. collectiveAttributeSubentries et collectiveExclusions ne peuvent pas être définis, mais ils sont pris en charge par l'overlay.

rfc4130

entryUUID est déjà présent dans le schéma embarqué.

olcAttributeTypes: ( 1.3.6.1.1.16.4 NAME 'entryUUID' DESC 'UUID of the entry' EQUALITY UUIDMatch ORDERING UUIDOrderingMatch SYNTAX 1.3.6.1.1.16.1 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )

rfc5020

entryDN est déjà présent dans le schéma embarqué

olcAttributeTypes: ( 1.3.6.1.1.20 NAME 'entryDN' DESC 'DN of the entry' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )

rfc4523

Le schéma des certificats x.509. À noter que OpenLDAP ne gère pas encore le règles certificatePairExactMatch et algorithmIdentifierMatch, donc les définitions de crossCertificatePair ec supportedAlgorithms doivent être dérivées de l'ancienne rfc2256.

rfc2798

inetOrgPerson est une classe structurelle contenant des attributs utiles pour les comptes utilisateurs. A noter que audio et photo sont définis dans l'ancienne rfc1274.

À ce stade, vous avez toutes les définitions de base pour travailler. Il y a quelques autres schémas standard, mais moins utilisés. Dans le prochain article, je donnerai un exemple de design de schéma personnalisé.

Note: Tous les schémas décris dans cet article sont disponibles dans documents/schémas-ldap/<rfcXXXX.ldif>

OpenLDAP - Configuration de base

Description des étapes de configuration initiales

Dans cet article, je décris une configuration initiale d'OpenLDAP. La configuration sera proche du minimum requis pour démarrer le serveur. J'écrirai d'autres articles dédiés à des configurations plus avançées.

OpenLDAP est un serveur modulaire basé sur le protocole LDAP (Lightweight Directory Access Protocol) lui-même dérivé des annuaires DAP X.500 qui ne sont plus utilisés. LDAP est donc un annuaire DAP léger, puisque c'est à l'origine une version simplifiée du protocole. Au fil des ans, il a intégré de nombreuses fonctionnalités X.500 et même plus de nos jours. La version 3 du protocole a apporté de nombreuses améliorations, notamment en terme de sécurité, internationalisation, et l'ajout des opérations étendues.

Un annuaire LDAP peut se définir comme une base d'objets hiérarchisée et optimisée pour la lecture.

Définitions

Avant d'aller plus loin, un petit refresh sur les définitions clés importantes pour la suite.

DIB Directory Information Base
DUA Directory User Agent
DSA Directory System Agent
DSE DSA-Specific Entry
DIT Directory Information Tree
RDN Relative Distinguished Name
AVA Attribute Value Assertions
RootDSE La racine d'un DIT est un DSE et ne fait partie d'aucun contexte de nommage (ou d'un subtree). Il fournis des informations sur le serveur lui-même ou spécifiques à d'autres serveurs.
Naming Context La plus grande collection d'entrées, commençant à une entrée maître, et incluant tous ses subordonnés et leur subordonnés, jusqu’aux entrées qui sont maître sur d’autres serveurs.
Backend Moteur de base de données
Frontend Le DSA, gère les échanges avec les DUA
Overlay Modules optionnels agissant comme un hook juste en dessous du frontend.

Configuration

Les directives de configuration d'OpenLDAP sont hiérarchisées. Ainsi, les directives de configuration globale sont tout en haut de cette hiérarchie.

Directives de configuration globale

la configuration global se trouve dans cn=config, il contient tous les paramètres propre au serveur. La classe objet olcGlobal embarquée permet de définir le jeu de fonctionnalités à autoriser, les rêgles d'authentification et d'autorisation, les paramètres de connexion et timeout, les index initiaux, les paramètres de sécurité, etc.

voici un exemple de configuration, n'incluant que quelques options pour rester le plus simple possible.

dn: cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
structuralObjectClass: olcGlobal

olcGlobal, contient les options de configuration global au serveur.

Avant d'aller plus loin, il est intérressant de démarrer le serveur. Celà permet, entre autre, de visualiser le schéma embarqué, qu'il est intérressant de connaître et sera utile dans l'article consacré au schéma LDAP.

Directives de configuration du frontend et des bases

frontend est spécial et contient des directives de base de données communes à toutes les autres. Il est toujours x-ordered à -1.

dn: olcDatabase={-1}frontend,cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
structuralObjectClass: olcDatabaseConfig

config est également spécial et contient des directives communes. A noter qu'il contient un compte qui a tous les droits sur la configuration. Il est toujours x-ordered à 0.

dn: olcDatabase={0}config,cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to *  by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcRootPW:: e1NTSEF9eHdZMjRxM09sUkFvVmwxVWt6bXU2TXBPTWdDVWRiS2o=
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
structuralObjectClass: olcDatabaseConfig

Directives de configuration de backend

Les backends sont très simples à déclarer:

dn: olcBackend=mdb,cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcBackendConfig
olcBackend: mdb
structuralObjectClass: olcBackendConfig

olcBackendConfig n'a qu'un attribut: olcBackend

Directives de configuration de schéma

cn=schema.ldif contient le schéma embarqué et est créé automatiquement. Les entrées sous cn=schema sont des directives olcSchemaConfig qui permettent de définir les OID, syntaxes, types d'attributs, classes d'objet, etc. Je vais consacrer un article sur les shémas, je n'en discute donc pas ici.

Directives de configuration de bases de données

La déclaration d'une base de données se fait avec olcDatabase:

dn: olcDatabase=mdb,cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: Mdb
olcDbDirectory: /var/lib/data/
olcAccess: to * by dn="cn=admin,dc=uubu,dc=fr" write by * read
olcSuffix: dc=uubu,dc=fr
olcRootDN: cn=admin,dc=uubu,dc=fr
olcRootPW:: e1NTSEF9eHdZMjRxM09sUkFvVmwxVWt6bXU2TXBPTWdDVWRiS2o=
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq

Ici les directives olcDatabaseConfig sont facilement compréhensibles, le répertoire où placer les fichiers de la base, le suffixe, compte et mot de passe admin, et une ACL. Les directives spécifiques à LMDB sont destinés à définir les index et la fréquence de vidage de tampons.

Directives de configuration des modules

les modules se déclarent dans des sous-entrées cn=module. Voici un exemple de déclaration d'un backend lmdb:

dn: cn=module,cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: back_mdb
structuralObjectClass: olcModuleList

olcModuleList définis 2 attributs, olcModulePath, et olcModuleLoad qui est un attribut multi-valué, et spécifie le ou les modules à charger. À noter que si OpenLdap est compilé avec les module statiquement, ces objets sont inutiles et génèreront une erreur si vous tentez de les importer.

Pour plus de clareté, il est préférable de définir plusieurs entrées module, au moins un pour les backend et un pour les overlay, voir un par module à charger s'il y'en a peu.

Aller un peu plus loin

Configurer Monitor

Le backend monitor permet de récupérer des informations sur le serveur. La base de données est maintenue automatiquement par slapd.

dn: olcDatabase={2}Monitor,cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcDatabaseConfig
objectClass: olcMonitorConfig
olcDatabase: {2}monitor
olcAccess: {0}to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,dc=uubu,dc=fr" read by * none

Ajouter des overlay

Pour ajouter un overlay, nous allons déclarer le module unique et le configurer pour dc=uubu,dc=fr:

dn: cn=module,cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: unique
structuralObjectClass: olcModuleList

olcUniqueConfig devient disponible, nous pouvons le paramétrer:

dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcUniqueConfig
olcOverlay: unique
olcUniqueURI: ldap:///?cn?sub?(objectClass=inetOrgPerson)

Démarrer le serveur

Avant de démarrer le serveur, il y'a quelques étapes importantes:

- créer un utilisateur:groupe dédié (ex: openldap:openldap)

- le fichier olcArgsFile, le répertoire de configuration et les répertoires contenant les bases de données doivent tous être possédés par cet utilisateur:groupe

L'import des directives de configuration est importante, en suivant cet ordre:

- cn=config

- cn=schema, olcModule et olcBackend

- olcDatabase

- olcOverlay puis vos données

Commandes utiles

Quelques commandes utiles dans cet article:

Ajouter vos fichiers de configuration:

slapadd -F /etc/ldap/slapd.d/ -bcn=config -l ./path/to/my/file.ldif

visualiser la configuration:

slapcat -bcn=config

pour cibler le schéma:

slapcat -bcn=schema,cn=config

démarrer le serveur:

/usr/sbin/slapd -F /etc/ldap/slapd.d -h ldap:///:389 -u openldap -g openldap