Bonjour,
J'essaie de déployer mon petit serveur perso avec quelques services (ssh, git, mails, etc…) et j'ai essayé de passer la base d'utilisateurs sur ldap (l'utilisation du pluriel est largement exagérée mais je fais ça à titre éducatif).
J'ai une organisation qui recense les utilisateurs (ou=People, cn=example, cn=org) et une autre (ou=Services, cn=example, cn=org) pour les services comme postfix ou nslcd pour l'authentification pam.
Plusieurs documentations suggèrent d'ajouter la règle suivante:
olcAccess: {0}to dn.subtree="ou=People,dc=example,dc=org" attrs=userPassword,shadowLastChange
by self write
by anonymous auth
olcAccess: {1}to *
by * read
Mais je trouve ça extrêmement permissif, un autre utilisateur peut même lire les mots de passes (hachés) de n'importe qui.
J'ai essayé de réduire les droits, les utilisateurs ne lisent que leurs infos perso et les services accèdent à tout le monde mais seulement pour les attributs nécessaires:
olcAccess: {0}to dn.subtree="ou=People,dc=example,dc=org" attrs=userPassword,shadowLastChange
by self write
by anonymous auth
olcAccess: {1}to *
by self read
by * search
olcAccess: {2}to dn.subtree="ou=Person,dc=example,dc=org" attrs=uidNumber,cn,gecos,uid,objectClass,homeDirectory,gidNumber,loginShell
by dn.exact="cn=nslcd,ou=Services,dc=example,dc=org" read
olcAccess: {3}to dn.subtree="ou=Person,dc=example,dc=org" attrs=uid
by dn.exact="cn=postfix,ou=Services,dc=example,dc=org" read
Mais là, bien que l'authentification auprès du LDAP et les commandes telles que ldapsearch fonctionnent pour les utilisateurs, les services ne marchent pas et nslcd n'arrive même pas à lister les utilisateurs.
Donc pour récapituler mes questions:
- Pourquoi "cn=nslcd,ou=Services,dc=example,dc=org" ne peut-il pas lister les uid dans "ou=Person,dc=example,dc=org"?
- Est-ce que cette configuration vous semble cohérente?
- Comment openldap interprète-t-il les listes de permissions (et, ou, règle la plus stricte ou la plus permissive?)
- 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.
# ACL Ldap
Posté par ranDom (site web personnel) . Évalué à 2. Dernière modification le 26 août 2019 à 10:26.
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 ?
Pourquoi limiter les accès aux attributs d'une branche, et non pas globalement ? ça simplifiera la mise en place des acls.
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.
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:
Mes 2¢
[^] # Re: ACL Ldap
Posté par nlgranger . Évalué à 1.
Merci beaucoup pour ces explications. Elle m'ont permis d'avancer.
L'authentification fonctionne et pour l'instant je passe simplement les identifiants et mots de passe via les arguments -D et -w des commandes ldap*.
Si j'ai bien compris, l'important est de donner l'accès en recherche à tout et l'accès en lecture à objectClass, entry et aux attributs souhaités
J'ai désormais la configuration suivante:
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.