Discussion :

[Tulkas59]

Bonjour à tous !

Je gère tous mes utilisateurs avec LDAP.

Je souhaiterais construire les règles de lecture suivante :
1) Seul admin peut modifier les mots de passe,
2) Les utilisateurs peuvent modifier leurs données personnelles,
3) Les utilisateurs du groupe <grp1> peuvent lire les entrées ayant un attribut ou=<grp1>
4) Les utilisateurs du groupe <grp2> peuvent lire les entrées ayant un attribut ou=<grp2>

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
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 * by self read 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 !

[Tulkas59]

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 (http://linux.die.net/man/5/slapd.access, section Operation Requirements) :

The search operation, requires search (=s) privileges on the entry pseudo-attribute of the searchBase (NOTE: this was introduced with OpenLDAP 2.4). Then, for each entry, it requires search (=s) privileges on the attributes that are defined in the filter. The resulting entries are finally tested for read (=r) privileges on the pseudo-attribute entry (for read access to the entry itself) and for read (=r) access on each value of each attribute that is requested. Also, for each referral object used in generating continuation references, the operation requires read (=r) access on the pseudo-attribute entry (for read access to the referral object itself), as well as read (=r) access to the attribute holding the referral information (generally the ref attribute).

Merci pour tout !