...

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