https://bugs.openldap.org/show_bug.cgi?id=10019
Issue ID: 10019
Summary: dynlist's +memberOf attribute not searchable/fetchable
with anonymous binds
Product: OpenLDAP
Version: 2.5.13
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Hi,
This is and issue we discovered (as a side effect of testing) after switching
from memberof overlay to dynlist with our confluence directory setup - which
previously worked fine, but not anymore.
Side effect of testing - as judging from the logs it seems that confluence is
doing normal binds (which is even stranger as non-anonymous bind ldapsearch
from commandline works correctly).
Anyway, consider the following setup:
groupOfURLs labeledURI uniqueMember+memberOf@groupOfUniqueNames
We only use static groups, so the following group with one of members:
DN: cn=TouK,ou=TouK,ou=Group,dc=touk,dc=pl
objectClass: groupOfUniqueNames
...
uniqueMember: cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl
Correlates to:
DN: cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl
...
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
The initial ACLs are set as follows:
{0}to * by dn=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by
* break
{1}to dn.subtree=ou=People,dc=touk,dc=pl
attrs=entry,entryUUID,memberOf,@toukAnonAccess by anonymous =scr by * break
{2}to dn.subtree=ou=Group,dc=touk,dc=pl
attrs=entry,@groupOfUniqueNames,@groupOfNames by anonymous =scr by * break
... later ACLs handling specific accesses and stuff, terminated with:
{14}to * by users =scr
Now if we do search doing non-anonymous binds, everything works correctly:
ldapsearch -x -H ldaps://ldap.touk.pl -D "cn=Michał
Sołtys,ou=Touki,ou=People,dc=touk,dc=pl" -s sub -b
'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no -y ./pass -LLL -v
'(uid=ast)' memberOf entryUUID
ldap_initialize( ldaps://ldap.touk.pl:636/??base )
filter: (uid=ast)
requesting: memberOf entryUUID
dn: cn=Adam Stus,ou=Touki,ou=People,dc=touk,dc=pl
entryUUID: 6c1adf48-a800-103a-8044-3100241d53c2
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
But if we do an anonymous search - with ACLs as above explicitly allowing
access to all relevant parts as in rule {1}, memberOf is not returned (it can't
be used in filtering either):
ldapsearch -x -H ldaps://ldap.touk.pl -s sub -b
'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no -LLL -v '(uid=ast)'
memberOf entryUUID
ldap_initialize( ldaps://ldap.touk.pl:636/??base )
filter: (uid=ast)
requesting: memberOf entryUUID
dn: cn=Adam Stus,ou=Touki,ou=People,dc=touk,dc=pl
entryUUID: 6c1adf48-a800-103a-8044-3100241d53c2
This - unless I missed something - looks like a bug.
As mentioned above - our local confluence install is using dedicated user, but
for some reason it is also unable filter using memberOf (though surprisingly it
does work from command line for non-anonymous bind). Relevant parts of the
slapd.log of such query:
Mar 6 19:21:24 lipa1 slapd[1206591]: conn=1009 op=0 BIND
dn="cn=confluence,ou=Apps,dc=touk,dc=pl" method=128
Mar 6 19:21:24 lipa1 slapd[1206591]: conn=1009 op=0 BIND
dn="cn=confluence,ou=Apps,dc=touk,dc=pl" mech=SIMPLE bind_ssf=0 ssf=256
Mar 6 19:21:24 lipa1 slapd[1206591]: conn=1009 op=0 RESULT tag=97 err=0
qtime=0.000016 etime=0.000230 text=
... other operations
Mar 6 19:26:58 lipa1 slapd[1206591]: conn=1009 op=28 SRCH
base="ou=Touki,ou=People,dc=touk,dc=pl" scope=2 deref=3
filter="(&(toukAccountActive=TRUE)(memberOf=cn=finanse,ou=touk,ou=group,dc=touk,dc=pl))"
Mar 6 19:26:58 lipa1 slapd[1206591]: conn=1009 op=28 SRCH attr=1.1
Mar 6 19:26:58 lipa1 slapd[1206591]: conn=1009 op=28 SEARCH RESULT tag=101
err=0 qtime=0.000019 etime=0.000541 nentries=0 text=
See (nentries=0) above - but identical search performed from command line,
e.g.:
ldapsearch -x -H ldaps://ldap.touk.pl -D "cn=confluence,ou=Apps,dc=touk,dc=pl"
-y ./b -a always -s sub -b 'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no
-LLL -v
'(&(toukAccountActive=TRUE)(memberOf=cn=finanse,ou=touk,ou=group,dc=touk,dc=pl))'
1.1
correctly returns 6 people:
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=0 BIND
dn="cn=confluence,ou=Apps,dc=touk,dc=pl" method=128
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=0 BIND
dn="cn=confluence,ou=Apps,dc=touk,dc=pl" mech=SIMPLE bind_ssf=0 ssf=256
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=0 RESULT tag=97 err=0
qtime=0.000025 etime=0.000269 text=
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=1 SRCH
base="ou=Touki,ou=People,dc=touk,dc=pl" scope=2 deref=3
filter="(&(toukAccountActive=TRUE)(memberOf=cn=finanse,ou=touk,ou=group,dc=touk,dc=pl))"
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=1 SRCH attr=1.1
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=2 UNBIND
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=1 SEARCH RESULT tag=101
err=0 qtime=0.000019 etime=0.002765 nentries=6 text=
--
You are receiving this mail because:
You are on the CC list for the issue.
