dkastens@uos.de wrote:
> Full_Name: Dirk Kastens
> Version: 2.4.40
> OS: RedHat SL 7.0
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2001:638:508:3d0:8d09:a681:a06e:29f0)
>
>
> This is a duplicate of bug #7993 that has been closed.
>
> Meanwhile I compiled openldap myself.
>
> At first, I compiled openldap-2.4.40. I configured ldap as a replica server. It
> connects with saslmech EXTERNAL to the master server.
> When I configure idassert-bind with saslmech EXTERNAL and try to change an
> entry, ldapmodify fails with
>
> ldap_modify: Other (e.g., implementation specific) error (80)
>
> slapd logs the message:
> ---------------------------
> send_ldap_result: referral="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de"
> >>> dnPrettyNormal:
> <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>
> <<< dnPrettyNormal:
> <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>,
> <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>
> conn=1000 op=1 ldap_chain_op:
> ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de"
> -> "ldap://ldap-master.rz.uni-osnabrueck.de"
> conn=1000 op=1 ldap_chain_op:
> ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de":
> URI="ldap://ldap-master.rz.uni-osnabrueck.de" found in cache
> =>ldap_back_getconn: conn=1000 op=1: lc=0x7faca820bc70 inserted refcnt=1
> rc=0
> Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?
> send_ldap_result: conn=1000 op=1 p=3
> send_ldap_result: err=80 matched="" text="misconfigured URI?"
> send_ldap_result: conn=1000 op=1 p=3
> send_ldap_result: err=80 matched="" text=""
> send_ldap_response: msgid=2 tag=103 err=80
> ---------------------------
>
> Then I compiled openldap-2.4.26 and used the same configuration. The modify with
> saslmech EXTERNAL succeeded:
>
> ---------------------------
> send_ldap_result: conn=1001 op=1 p=3
> send_ldap_result: err=10 matched="" text=""
> send_ldap_result: referral="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de"
> >>> dnPrettyNormal:
> <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>
> <<< dnPrettyNormal:
> <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>,
> <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>
> conn=1001 op=1 ldap_chain_op:
> ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de"
> -> "ldap://ldap-master.rz.uni-osnabrueck.de"
> conn=1001 op=1 ldap_chain_op:
> ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de":
> URI="ldap://ldap-master.rz.uni-osnabrueck.de" found in cache
> =>ldap_back_getconn: conn=1001 op=1: lc=0x7f4f201fe6f0 inserted refcnt=1
> rc=0
> send_ldap_result: conn=1001 op=1 p=3
> send_ldap_result: err=0 matched="" text=""
> send_ldap_response: msgid=2 tag=103 err=0
> ---------------------------
>
> With a quick look I found out, that the function ldap_back_dobind_int in
> server/slapd/back-ldap/bind.c differs. In 2.4.26 you have:
>
> ---------------------------
>   if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) {
>      if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY(
> &bindcred ) ) {
>      /* if we got here, it shouldn't return result */
>      rc = ldap_back_is_proxy_authz( op, rs,
>           LDAP_BACK_DONTSEND, &binddn, &bindcred );A A    assert( rc ==
> 1 );
>      }
>      rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn,
> &bindcred );
>        goto done;
>      }
> ---------------------------
>
> while in 2.4.40 there is:
>
> ---------------------------
> if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) {
>     if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) )
> {
>         /* if we got here, it shouldn't return result */
>              rc = ldap_back_is_proxy_authz( op, rs,
>                  LDAP_BACK_DONTSEND, &binddn,2&bindcred );
>              if ( rc != 1 ) {
>                 Debug( LDAP_DEBUG_ANY, "Error: ldap_back_is_proxy_authz "
>                 "returned %d, misconfigured URI?\n", rc, 0, 0 );
>                 rs->sr_err = LDAP_OTHER;
>                 rs->sr_text = "misconfigured URI?";
>                 LP_P_BACK_CONN_ISBOUND_CLEAR( lc );
>                 if ( sendok & LDAP_BACK_SENDERR ) {
>                     send_ldap_result( op, rs );
>                 }
>                 goto done;
>              }
>              rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn,
> &bindcred );
>             goto done;
>     }
> --------------------------
>
> This is where the error message comes from ("misconfigured URI?")

Looks like you've compiled without DEBUG enabled, otherwise your 2.4.26 
build would have died with an assert() failure there.

Send a complete config that reproduces the issue. Also give the complete 
command you used. So far this just looks like a misconfiguration to me.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Dirk Kastens wrote:
> Hi,
>
> I have attached my config directory.

For future reference - just use slapcat -n0.

The slapd config database internal format will not always be a directory 
tree, but slapcat will always do the right thing.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

hyc@symas.com wrote:
> Looks like you've compiled without DEBUG enabled, otherwise your 2.4.26
> build would have died with an assert() failure there.
>
> Send a complete config that reproduces the issue.

Repeating myself:

> Also give the complete
> command you used.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Hello,

just in case someone is still looking on this, I stumbled on the same
issue when upgrading openldap from an old version (2.4.2x) to 2.4.40.
Used first a debian package, then compiled it myself, same behaviour.

However, I managed to make it work by setting explicitly the
"override" flag in the chain-idassert-bind parameters ( I'm not sure
it's the right way to fix this "issue"):

chain-idassert-authzFrom "dn:*"
chain-idassert-bind   bindmethod=sasl
                      saslmech="EXTERNAL"
                      mode=self
                      flags=override,proxy-authz-critical
                      starttls=critical
                      tls_cacert=/etc/ldap/ssl/CA.pem
                      tls_key=/etc/ldap/ssl/private/key.pem
                      tls_cert=/etc/ldap/ssl/proxy.pem
                      tls_reqcert=demand


For those who like the cn=config syntax better:

olcDbIDAssertBind: mode=self
flags=flags=prescriptive,override,proxy-authz-critical bindmethod=sasl
timeout=0 network-timeout=0 saslmech=EXTERNAL keepalive=0:0:0
starttls=critical tls_cert="/opt/SNet/etc/ldap/ssl/proxy.pem"
tls_key="/opt/SNet/etc/ldap/ssl/private/key.pem"
tls_cacert="/opt/SNet/etc/ldap/ssl/CA.pem" tls_reqcert=demand


Note:
Previous to that, the flags were NOT set explicitly, so the following
default values were used:

olcDbIDAssertBind: mode=self
flags=prescriptive,proxy-authz-non-critical bindmethod=sasl timeout=0
network-timeout=0 saslmech=EXTERNAL keepalive=0:0:0 starttls=critical
tls_cert="/opt/SNet/etc/ldap/ssl/proxy.pem"
tls_key="/opt/SNet/etc/ldap/ssl/private/key.pem"
tls_cacert="/opt/SNet/etc/ldap/ssl/CA.pem" tls_reqcert=demand

Needs investigation.

I can't find the uploaded configuration or additionally requested data to try and reproduce the issue, but, judging by the last comment, the issue was caused by the fix of ITS#7403, included in 2.4.33. It seems to me this initially worked because of a bug, fixed with ITS#7403, so it is not a bug in itself.

Behavior change due to fix in ITS#7403