Acl ldap

Bonjour à tous !

Je gère tous mes utilisateurs avec LDAP.

Je souhaiterais construire les règles de lecture suivante :
[ul]

  1. Seul admin peut modifier les mots de passe,
  2. Les utilisateurs peuvent modifier leurs données personnelles,
  3. Les utilisateurs du groupe peuvent lire les entrées ayant un attribut ou=
  4. Les utilisateurs du groupe peuvent lire les entrées ayant un attribut ou=
    [/ul]

Une entrée peut avoir un attribut ou= et ou=. Un utilisateur peut être dans les deux groupes.

Voici donc mes ACL (ou plutôt le ldif correspondant) :

dn: olcDatabase={1}hdb,cn=config
changetype: modify
delete: olcAccess
-
add: olcAccess
olcAccess: to dn.base="" by * read
-
add: olcAccess
olcAccess: to attrs=userPassword by dn="cn=admin,dc=xxx,dc=yyy" write by anonymous auth by * none
-
add: olcAccess
olcAccess: to attrs=@attributspersos by self write by * break
-
add: olcAccess
olcAccess: to dn.subtree="ou=users,dc=xxx,dc=yyy" filter=(ou=grp1) by set="[cn=grp1,ou=groups,dc=xxx,dc=yyy]/memberUid&user/uid" read by * break
-
add: olcAccess
olcAccess: to dn.subtree="ou=users,dc=xxx,dc=yyy" filter=(ou=grp2) by set="[cn=grp2,ou=groups,dc=xxx,dc=yyy]/memberUid&user/uid" read by * break
-
add: olcAccess
olcAccess: to * by dn="cn=admin,dc=xxx,dc=yyy" write by * none

Mais cela ne marche pas ! L’authentification réussi, admin a bien tous les droits, mais malgré mon appartenance aux deux groupes, je ne vois aucune entrée !

Est-ce que vous voyez une erreur ?

Merci par avance !

Avant toute chose je connais seulement AD pour ce genre de manip.

Est ce que tu as l’équivalent de GPO sous Deb?

http://www.fatofthelan.com/articles/

https://wiki.samba.org/index.php/Samba_AD_DC_HOWTO#Group_Policy_Management_Console

edit: pour tout ce qui est authentication (kerberos et tutti quantti)

tu as ca http://www.adminsys.me/art-65.html

Merci pour ta réponse !

Je ne connais pas AD pour ma part. Cela dit, je ne suis pas non plus expert OpenLDAP…

Pour la gestion des droits par groupe, j’utilise la syntaxe set="[cn=,ou=groups,dc=xxx,dc=yyy]/memberUid&user/uid" qui permet de ne désigner que les entrées X tels que dans le groupe , il existe un attribut memberUid=X.uid.

Voir openldap.org/doc/admin24/access-control.html (section Group ACLs without DN syntax)

[quote=“Tulkas59”]Merci pour ta réponse !

Je ne connais pas AD pour ma part. Cela dit, je ne suis pas non plus expert OpenLDAP…

Pour la gestion des droits par groupe, j’utilise la syntaxe set="[cn=,ou=groups,dc=xxx,dc=yyy]/memberUid&user/uid" qui permet de ne désigner que les entrées X tels que dans le groupe , il existe un attribut memberUid=X.uid.

Voir openldap.org/doc/admin24/access-control.html (section Group ACLs without DN syntax)[/quote]

Le problème que j’ai est que je comprends ce que tu fais mais je ne sais faire ce type de manipulation que par le biais de la GUI d’AD. Ce que je te conseille est de t’amuser à faire des groupes dans une installation virtualisée de Deb où tu pourrais y ajouter des membres et à tester le resultat

C’est ce que je fais depuis un moment. Je découvre plein de petits trucs pratiques au passage :slightly_smiling: mais pas la solution à mon problème…

Quelqu’un a une idée ?

Encore merci pour votre aide !

Pour te remonter le moral j’ai vu hier soir un fil de 2011 qui était du même acabit que ton post…le mec attend tjs une réponse…

J’ai finalement trouvé la solution à mon problème !

Il manquait les droits en lecture au pseudo-attribut “entry” sur les entrées souhaitées !

Pour faire vite, voilà ce que dit la doc (linux.die.net/man/5/slapd.access, section Operation Requirements) :

Merci pour tout !

Salut et gg,

par contre te serait il possible de faire un post montrant, dans la mesure où cela ne pose pas de blème de securite, la topo et les droits de ton “annuaire” car cette problèmatique m’intéresse d’autant que je risque de développer un systeme semblable.

Je t’avoue avoir honte de moi car je n’ai pas pensé aux authorisations…sic

Pas de problème :

dn: olcDatabase={1}hdb,cn=config
changetype: modify
delete: olcAccess
-
add: olcAccess
olcAccess: to dn.base="" by * read
-
add: olcAccess
olcAccess: to attrs=userPassword by dn="cn=admin,dc=xxx,dc=yyy" write by anonymous auth by * none
-
#
# 1) Les gestionnaires peuvent modifier les attributs personnels des utilisateurs.
# 2) Un utilisateur peut modifier ses propres données.
#
add: olcAccess
olcAccess: to dn.subtree="ou=users,dc=xxx,dc=yyy" attrs=@class1,@class2,@class3 by group/organizationalRole/roleOccupant="cn=admin,dc=xxx,dc=yyy" write by self write by * break
-
#
# 1) Le groupe grp1 peut accéder aux entrées du groupe grp1.
# 2) Le groupe grp2 peut accéder aux entrées du groupe grp2.
# 3) admin et reader peuvent respectivement tout écrire et tout lire.
# 4) Les utilisateurs authentifiés peuvent faire des recherches dans la section users.
#
add: olcAccess
olcAccess: to dn.subtree="ou=users,dc=xxx,dc=yyy" filter=(ou=grp1) attrs=@class1,@class2,@class3,entry by set="[cn=grp1,ou=groups,dc=xxx,dc=yyy]/memberUid&user/uid" read by * break
-
add: olcAccess
olcAccess: to dn.subtree="ou=users,dc=xxx,dc=yyy" filter=(ou=grp2) attrs=@class1,@class2,@class3,entry by set="[cn=grp2,ou=groups,dc=xxx,dc=yyy]/memberUid&user/uid" read by * break
-
add: olcAccess
olcAccess: to * by dn="cn=admin,dc=xxx,dc=yyy" write by dn="cn=reader,dc=xxx,dc=yyy" read by self read by users break by * none
-
add: olcAccess
olcAccess: to dn.subtree="ou=users,dc=xxx,dc=yyy" by users search
#
# Un garde fou (inutile normalement) !
#
-
add: olcAccess
olcAccess: to * by * none

Bon courage !

Merci je regarderais ca a tete reposee