Forum Linux.général Besoin d'aide pour comprendre les permissions avec LDAP

Posté par . Licence CC by-sa.
1
24
août
2019

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 (page perso) . Évalué à 2 (+1/-0). Dernière modification le 26/08/19 à 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¢

    • [^] # Re: ACL Ldap

      Posté par . Évalué à 1 (+0/-0).

      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:

      dn: olcDatabase={1}mdb,cn=config
      changetype: modify
      add: olcAccess
      olcAccess: to attrs=userPassword,shadowLastChange
        by self write
        by anonymous auth
      olcAccess: to attrs=entry,objectClass,uid
        by dn.base="cn=nslcd,ou=Services,dc=example,dc=org" read
        by dn.base="cn=postfix,ou=Services,dc=example,dc=org" read
        by dn.base="cn=dovecot,ou=Services,dc=example,dc=org" read
      olcAccess: to attrs=uidNumber,cn,gecos,homeDirectory,gidNumber,loginShell
        by dn.base="cn=nslcd,ou=Services,dc=example,dc=fr" read
      olcAccess: to *
        by self read
        by * search
      

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.