• # ACL Ldap

    Posté par (site web personnel) . En réponse au message Besoin d'aide pour comprendre les permissions avec LDAP. Évalué à 2. Dernière modification le 26 août 2019 à 10:26.

    Pourquoi "cn=nslcd,ou=Services,dc=example,dc=org" ne peut-il pas lister les uid dans "ou=Person,dc=example,dc=org"?

    pour que nslcd soit "vu" comme "cn=nslcd,ou=Serv..." par le serveur ldap, il faut que la connexion du service à ldap soit authentifiée et non pas anonyme. Est-ce le cas ?

    Est-ce que cette configuration vous semble cohérente?

    Pourquoi limiter les accès aux attributs d'une branche, et non pas globalement ? ça simplifiera la mise en place des acls.

    Comment openldap interprète-t-il les listes de permissions (et, ou, règle la plus stricte ou la plus permissive?)

    Il s'arrête à la première acl correspondant au "to", ça veut dire que l'acl n°1 devrait être à la fin, l'acl n° 2 n'est jamais interprétée.

    Je n'ai pas ajouté les règles "access to dn.base="" by * read" ou "access to dn.base="cn=Subschema" by * read" car j'ignore à quoi ça sert, mais je les ai vues à plusieurs reprises dans des docs.

    Interroger la branche cn=Subschema permet d'obtenir la structure de l'arbre ldap sans connaissance préalable (l'équivalent d'un show databases / show tables en sql). C'est surtout utilisé par les clients graphiques. cf https://www.openldap.org/faq/data/cache/1366.html

    Au final, je verrais plutôt un truc comme ça:

    olcAccess: to attrs=userPassword,shadowLastChange
 by self write
 by anonymous auth
olcAccess: to attrs=uidNumber,cn,gecos,uid,objectClass,homeDirectory,gidNumber,loginShell
 by dn.exact="cn=nslcd,ou=Services,dc=example,dc=org" read
olcAccess: to attrs=uid
 by dn.exact="cn=postfix,ou=Services,dc=example,dc=org" read
olcAccess: to *
 by self read
 by * search

    Mes 2¢