[Issue 10019] New: dynlist's +memberOf attribute not searchable/fetchable with anonymous binds
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: bugs@openldap.org Reporter: msl@touk.pl 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=
https://bugs.openldap.org/show_bug.cgi?id=10019
--- Comment #1 from Howard Chu hyc@openldap.org --- The discrepancy between your app behavior and ldapsearch commandline behavior implies that you're not accurately describing what your app does. Also, if there is an ACL configuration issue, it's not helpful for you to omit the 13 other ACL rules in your config.
If you want anyone to actually have a chance of diagnosing your problem, you need to be able to provide a complete minimal configuration that demonstrates it. I suggest you start by using the configs used in the test suite itself.
https://bugs.openldap.org/show_bug.cgi?id=10019
--- Comment #2 from msl@touk.pl --- (In reply to Howard Chu from comment #1)
The discrepancy between your app behavior and ldapsearch commandline behavior implies that you're not accurately describing what your app does. Also, if there is an ACL configuration issue, it's not helpful for you to omit the 13 other ACL rules in your config.
If you want anyone to actually have a chance of diagnosing your problem, you need to be able to provide a complete minimal configuration that demonstrates it. I suggest you start by using the configs used in the test suite itself.
Sorry for somewhat confusing report, I should have split it into 2 separate ones as these are (were) somewhat distinct.
I did some more digging:
1) regarding anonymous bind access
I forgot to grant entryDN access. So that's on me (side-effect of switching do dynlist, as the memberof overlay of course didn't need that). After re-reading the man page it was indeed mentioned there.
2) regarding dynlist not triggering its functionality
This took me a bit more time to connect the dots - after shortcutting acls to '{0}to * by * manage' and enabling 'acl' logging - the issue turned out to be manageDSAit, after seeing that dynlist internal searches were not triggered. So updating the configs wherever we are using memberof fixed the issues.
Anyway perhaps there is a room for small improvement - wouldn't it be possible/better to have the static membership functionality always work - regardless of manageDSAit - as technically it's not needed for this part as no explicit URLs are actually involved ?
Other than that sorry for the noise.
https://bugs.openldap.org/show_bug.cgi?id=10019
--- Comment #3 from Ondřej Kuzník ondra@mistotebe.net --- In terms of manageDSAit, the policy is not to generate virtual attributes when that's set. One reason is so that replication clients do not receive them.
https://bugs.openldap.org/show_bug.cgi?id=10019
--- Comment #4 from msl@touk.pl --- (In reply to Ondřej Kuzník from comment #3)
In terms of manageDSAit, the policy is not to generate virtual attributes when that's set. One reason is so that replication clients do not receive them.
Ah, that makes sense. Thanks for clarification.
https://bugs.openldap.org/show_bug.cgi?id=10019
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
https://bugs.openldap.org/show_bug.cgi?id=10019
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
-
openldap-its＠openldap.org