Pinaillage

Pour le niveau de journalisation, mieux vaut utiliser des valeurs textuelles que numériques, c'est plus lisible. Et contrairement à ce que le commentaire laisse supposer, le choix n'est pas entre 0 (rien) et 255 (trop), il y a tout un éventail de possibilité. Loglevel stats, par exemple, est largement supportable par n'importe quel annuaire, et permet d'identifier les problèmes après qu'ils soient signalés.

Pour les ACLs, mieux vaut éviter d'entrelacer les déclaration par objet (sur quoi porte une règle) et par sujet (sur qui elle porte), pour éviter les erreurs. Par exemple, il est plus lisible de commencer par:

 # l'admin peut tout écrire
 access to dn.subtree="dc=localdomain"
 by dn.exact="cn=admin,dc=localdomain" write
 by * break
 # readonly peut tout lire
 access to dn.subtree="dc=localdomain"
 by dn.exact="cn=admin,dc=localdomain" read
 by * break

Plutôt que de gérer ces cas par des clauses supplémentaires dans la règle par défaut qui vient tout à la fin.

Par ailleurs, l'utilisateur déclaré par les directives rootdn et rootpw dans les fichiers de configuration ignore totalement les ACLs, il n'y a aucune nécessité d'en prévoir pour lui. Ou alors, de ne pas utiliser ces directives (rootdn n'est nécessaire que sur un esclave) pour plus de contrôle.

Enfin, je suis très sceptique sur la nécessité pour une application d'avoir accès en lecture à l'attribut userPassword. Les seuls cas que je connaisse concernent radius ou kerberos, dans des configuration particulières, dans lesquelles l'annuaire est utilisé comme solution de stockage de mots de passe, avec des syntaxes spécifiques, et jamais en réutilisant l'attribut mot de passe de l'annuaire lui-même. Toutes les autres applications se contentent d'une opération bind sur l'annuaire, avec l'identificant de l'utilisateur, pour laquelle seul la permission by anonymous auth est nécessaire.