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.
Je ne vois pas ce qui te permet d'affirmer que je situe le logging de 0 à 255, c'est faux, et je précise que les informations sont dans la manpage de slapd.conf.
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.
Bof, à l'usage, quelle que soit la forme des ACL, elle ne m'a jamais posé de problème, et sont difficilement sujetes à erreurs.
Cela étant, c'est toujours un bon conseil pour qui commence...
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.
Là dessus, je ne répondrai pas directement, c'est une question d'idéologie, je préfère, dans la mesure du faisable, que les ACL rappellent explicitement les droits du superutilisateur plutôt que de laisser cette information tacitement admise. C'est plus intelligible.
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.
Cette permission n'existe que depuis récemment, mon exemple décrit un ACL qui remonte à 2006 je crois. Par ailleurs, je crois que dovecot ne sa(va)it pas se binder directement en tant que l'utilisateur pour vérifier son mot de passe, je n'exclus pas de ne pas être à jour sur la question, mais du coup, l'acl dovecot semble utile...
[^] # Re: Pinaillage
Posté par PEB . En réponse au journal LDAP, un peu de technique.. Évalué à 1.
Je ne vois pas ce qui te permet d'affirmer que je situe le logging de 0 à 255, c'est faux, et je précise que les informations sont dans la manpage de slapd.conf.
Bof, à l'usage, quelle que soit la forme des ACL, elle ne m'a jamais posé de problème, et sont difficilement sujetes à erreurs.
Cela étant, c'est toujours un bon conseil pour qui commence...
Là dessus, je ne répondrai pas directement, c'est une question d'idéologie, je préfère, dans la mesure du faisable, que les ACL rappellent explicitement les droits du superutilisateur plutôt que de laisser cette information tacitement admise. C'est plus intelligible.
Cette permission n'existe que depuis récemment, mon exemple décrit un ACL qui remonte à 2006 je crois. Par ailleurs, je crois que dovecot ne sa(va)it pas se binder directement en tant que l'utilisateur pour vérifier son mot de passe, je n'exclus pas de ne pas être à jour sur la question, mais du coup, l'acl dovecot semble utile...