Le contenu de cette arborescence est aussi stocké sous forme de fichiers, dans le répertoire `/etc/ldap/slapd.d/` et ceux-ci sont chargés au démarrage de OpenLDAP.
À savoir : lorsqu'on modifie à chaud la configuration, OpenLDAP met alors immédiatement à jour le contenu du fichier correspondant dans `/etc/ldap/slapd.d/` !
Une autre possibilité est de stopper **slapd**, de modifier les fichiers LDIF dans _/etc/ldap/slapd.d/_ et de le redémarrer.
Attention, cela risque de générer des warnings à propos de checksums sur les fichiers. Pour contourner cela, il faut ré-éditer les entrées à chaud pour que les dumps soient regénérés avec les bons checksums...
adding new entry "cn={4}amavis,cn=schema,cn=config"
~~~
Note : Si besoin, on peut bien sûr convertir plusieurs schémas d'un coup via un fichier _/tmp/convert-to-ldap.conf_ du type :
~~~
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/collective.schema
[...]
include /etc/ldap/schema/monschema2.schema
~~~
### Gestion des ACL
Les ACL s'ajoutent via des règles du type :
~~~
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=com" write by peername.ip="127.0.0.1" read by * none
~~~
/!\ en cas de réplication, bien penser à inclure l'utilisateur de réplication pour les attrs=userPassword,shadowLastChange sous peine
de ne pas avoir de synchronisation des mots de passe !!!
Pour ne pas avoir un annuaire lisible publiquement mais accessible depuis l'extérieur, on peut forcer l'authentification en remplaçant "by peername.ip="127.0.0.1" read" par :
~~~
by users read by anonymous auth
~~~
### Réplication (master->slave)
*Sur le master :*
* Ajouter le module syncprov (dans l'objet cn=module{0},cn=config) :
Suite à cette mise en place, si en tentant de se connecter au serveur apparaît l'erreur `ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)`, il se peut que ça soit dû au certificat non reconnu. Pour désactiver la vérification du certificat, sur le client, ajouter cette ligne dans _/etc/ldap/ldap.conf_ :
Les données brutes d'OpenLDAP sont stockées au format "Berkeley Database" dans `/var/lib/ldap/`.
Un certain nombre de paramètres peuvent être ajustés via le fichier `DB_CONFIG`.
Une fonctionnalité est notamment la rétention de fichiers de logs permettant de rejouer les modifications.
Ces logs sont dans stockés dans `/var/lib/ldap/log.000*` mais attention, on ne peut pas tous les effacer.
Le plus simple est de lancer la commande `db_archive -d` régulièrement pour purger les anciens fichiers qui ne sont pluys utilisés et éviter que l'espace disque explose.
Cet outil permet de naviguer dans un annuaire LDAP et de modifier les éléments à la manière d'un shell et d'un système de fichier.
Il utilise les fichiers de configuration `$HOME/.shelldap.rc`, `/usr/local/etc/shelldap.conf` et `/etc/shelldap.conf`. Exemple :
```
binddn: uid=<login>,ou=<foo>,dc=example,dc=com
cacheage: 300
server: <host>
timeout: 10
promptpass: 1
```
Note: pour l'édition, il ne tient pas compte de `$SELECTED_EDITOR` (généralement dans `$HOME/.selected-editor`) mais plutôt de `$EDITOR`. Vous pouvez donc mettre `export EDITOR="/usr/bin/vim.basic"` dansvotre ficher `$HOME/.profile`
Vérifiez que l'utilisation _openldap_ a bien accès aux clés privés et certificats définis dans sa configuration (vous pouvez utiliser `sudo -u openldap /bin/bash` pour vous en assurer).
Le répertoire `/etc/ldap/slapd.d/cn=config/` à du être modifié (à ne pas faire lorsque **slapd** tourne), il vous faudra regenérer le checksum manuellement.
La limite par défaut lors d'un ldapseach est de 500. On peut l'augmenter en modifiant l'attribut olcSizeLimit, avec par exemple `ldapvi -Y EXTERNAL -h ldapi:// -b cn=config`.
### no equality matching rule
En cas d'erreur du type :
~~~
ldap_modify: Inappropriate matching (18)
additional info: modify/delete: foo_attribute: no equality matching rule
Si ce n'est pas possible d'ajouter une règle EQUALITY dansle schéma LDAP (par exemple pour les SYNTAX binary comme jpegPhoto), n'utilisez pas ldapmodify (LDAP_MOD_REPLACE) mais plutôt suppression (et recréation si besoin) :
> additional info: modify/delete: foo_attribute: no such value
~~~
Vérifier que votre attribut n'a pas des caractères spéciaux (saut de ligne, etc.), vous pouvez notamment d'abord remplacer votre ligne avec une valeur "test" pour voir si cela fonctionne.
Les erreurs SSL/TLS ne sont pas très explicites avec OpenLDAP, si vous en avez une, vérifiez d'abord que vos clés/certificats sont bien corrects avec des bons droits pour y accéder.
Les commandes qui génèrent des formats LDIF comme `slapcat` limite leur ligne à 76 caractères et provoquent donc des sauts de lignes qui peuvnet être embêtant (par exemple quand on doit faire un remplacement dans un DN par exemple). Voici une astuce pour supprimer ce saut de ligne, sachant que cela ne pose pas de problème pour la réinjection :
### Erreur : rootdn is always granted unlimited privileges
Pour certaines vieilles configurations avec `/etc/ldap/slapd.conf` :
*`rootdn` est sur le super-user de la base de données.
* Il est inutile de lui donner des accès car il les a déjà.
* Si on lui donne des droits dans les ACL (directives "access") cela génère l'avertissement ci-dessus. Ce n'est pas un avertissement de sécurité mais de redondance.
Il suffit de supprimer ou commenter les lignes `by` donnant des accès à rootdn dans les blocs `access` pour supprimer les warnings.
Attention, le terme `rootdn` n'est pas explicitement mentionné dans les blocs `access`, recherchez plutôt son uid (vous pouvez le trouver dans la direction de définition du `rootdn`).
"Never add the rootdn to the by clauses. ACLs are not even processed for operations performed with rootdn identity (otherwise there would be no reason to define a rootdn at all)."