> Scott Koranda wrote:
> >Hello,
> >
> >As part of an evaluation and testing phase, on a Debian
> >Squeeze system using version 2.4.23 of OpenLDAP I successfully
> >configured and used the slapd-meta backend. The configuration
> >looked like this:
> >
> >database meta
> >suffix "dc=test,dc=myorg,dc=org"
> >
> >uri "ldapi:///o=external,dc=test,dc=myorg,dc=org"
> >
> >acl-authcDN uid=foswiki,ou=system,o=external,dc=test,dc=myorg,dc=org
> >acl-passwd passwd
> >idassert-bind bindmethod=simple
> >
binddn="uid=foswiki,ou=system,o=external,dc=test,dc=myorg,dc=org"
> > credentials="passwd"
> > mode=self
> >
> >uri "ldapi:///o=internal,dc=test,dc=myorg,dc=org"
> >
> >acl-authcDN uid=foswiki,ou=system,o=external,dc=test,dc=myorg,dc=org
> >acl-passwd passwd
> >idassert-bind bindmethod=simple
> >
binddn="uid=foswiki,ou=system,o=external,dc=test,dc=myorg,dc=org"
> > credentials="passwd"
> > mode=self
> >
> >To prepare for a production deployment I then compiled
> >OpenLDAP 2.4.33 using this set of configure options:
> >
> >./configure --prefix=/opt/openldap-2.4.33 --enable-slapd
> >--enable-cleartext --enable-rewrite --enable-bdb --enable-hdb
> >--enable-ldap --enable-meta --enable-rwm
> >
> >I attempted to use the same configuration for the slapd-meta
> >backend. My queries to slapd no longer returned anything and I
> >saw this in the debug ouput:
> >
> >50c15573 conn=1000 op=1 meta_search_dobind_init[0] mc=0x22c2da0: non-empty dn
with empty cred; binding anonymously
> >50c15573 conn=1000 op=1 meta_search_dobind_init[1] mc=0x22c2da0: non-empty dn
with empty cred; binding anonymously
> >
> >I interpret this to mean that the slapd-meta backend is
> >deciding it does not have a credential to use and is binding
> >anonymously to the proxied services.
> >
> >How should I change my configuration above so that the most
> >recent version of OpenLDAP will be able to bind to the proxied
> >services in the way that happened with version 2.4.23?
> >
> >Note that I installed versions between 2.4.23 and 2.4.33
> >(bisection) and found that the change from 2.4.25 to 2.4.26
> >causes the configuration above to go from "working" to "not
> >working". Versions 2.4.26 and above that I tested result in
> >the "non-empty dn with empty cred" in the debug output.
>
> The only relevant change to back-meta from 2.4.25 to .26 is for
> ITS#6909. Perhaps you can retest your config with that patch
> reverted and see how it goes.
>
I read ITS#6909 but I do not see the actual patch that was
applied. A patch was provided by the initial reporter but it
looks like a different solution was implemented.
So I compared the file server/slapd/back-meta/search.c from
versions 2.4.25 and 2.4.33 and edited 2.4.33 so that now the
only difference between it and the 2.4.25 version is
604,606c605,606
< rc = ldap_back_map_attrs( &mt->mt_rwmap.rwm_at,
< op->ors_attrs, BACKLDAP_MAP,
&mapped_attrs,
< op->o_tmpmemctx );
---
> rc = ldap_back_map_attrs( op, &mt->mt_rwmap.rwm_at,
> op->ors_attrs, BACKLDAP_MAP,
> &mapped_attrs );
I cannot easily revert that change since it looks like the definition
of the function ldap_back_map_attrs() changed.
I recompiled 2.4.33 with this edited version of search.c and
tested but unfortunately I still see the "non-empty dn with
empty cred" message in the debug ouput and it appears that the
meta backend is still attempting to bind anonymously.
I added some extra debug statements to
servers/slapd/back-meta/search.c and found that when this if()
statement evaluates to true
if ( op->o_conn != NULL &&
!op->o_do_not_cache &&
( BER_BVISNULL( &msc->msc_bound_ndn ) ||
BER_BVISEMPTY( &msc->msc_bound_ndn ) ||
( mt->mt_idassert_flags & LDAP_BACK_AUTH_OVERRIDE) ) )
then the line
rc = meta_back_proxy_authz_cred( mc, candidate, op, rs, LDAP_BACK_DONTSEND, &binddn,
&cred, &method );
is executed and only when that function returns is the
cred.bv_val not NULL and set to the value I have put in my
configuration file for the password to use.
Debugging shows that not all invocations of the function
meta_search_dobind_init()
result in that if() statement evaluating to true and so that
meta_back_proxy_authz_cred() is not always called. When it is
not called then cred.bv_val is NULL and so right after the
retry:;
the evaluation of
BER_BVISEMPTY ( &cred )
is true and inside that branch cred is
set to slap_empty_bv and hence the anonymous bind attempt by
back-meta.
Just to try something I added an identical call to
meta_back_proxy_authz_cred() right after the
retry:;
and that "solves" my problem. I am sure that is not a proper
fix...
Does this appear to be a bug? If so, shall I file an issue
myself and if so what information would be most helpful?
Thanks,
Scott