hyc@symas.com wrote:

masarati@aero.polimi.it wrote:

...

...

...

...

The way I read this, it seems to imply that if acl-bind is not set, the identity specified by idassert-bind will be used -- which is clearly not happening here. Am I misreading this, or do you think the wording should be changed here?

As far as I remember, the above is (or was) true in some cases (which I do not remember); in any case, the above statement is in contradiction with Howard's statement. Either the behavior stated above should be generalized (if desirable, in order to avoid the need to configure things twice when the same identity is going to be used), or the two should be decoupled everywhere in the code.

The current code in ldap_back_prepare_conn:

...

...

...

>

#ifdef HAVE_TLS if ( LDAP_BACK_CONN_ISPRIV( lc ) ) { sb =&li->li_acl;

   } else if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) {
       sb =&li->li_idassert.si_bc;

   } else {
       sb =&li->li_tls;
   }

   if ( sb->sb_tls_do_init ) {
       bindconf_tls_set( sb, ld );
   } else if ( sb->sb_tls_ctx ) {
       ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx );
   }

   /* if required by the bindconf configuration, force TLS */
   if ( ( sb ==&li->li_acl || sb ==&li->li_idassert.si_bc )&&
       sb->sb_tls_ctx )
   {
       flags |= LDAP_BACK_F_USE_TLS;
   }

<<<<

It seems the initial if/else belongs outside the #ifdef, first of all. Not sure how to handle the fallback to li->li_tls.

Uh, no, that's fine: sb is only used to decide whether and how to start TLS, as far as I understand, so the #ifdef is fine. li_tls is only about configuring TLS for regular connections, which could be different from that of li_acl and li_idassert (and in any case one may want to configure TLS without configuring li_acl nor li_idassert.

OK. The error I saw before was that TLS was started without the CA cert being configured, and that's because at this point, li->li_acl was used but only li->li_idassert had any TLS configuration. I've patched this now to also use li->li_idassert if li_acl was not configured.

...

Later, in ldap_back_getconn(), there's some code that either uses li_acl or li_idassert; however, in ldap_back_dobind_int(), private connections only use li_acl for private connections when SASL is configured. Probably here we should use either li_acl or li_idassert if defined.

Yeah, that sounds right. OK, will look into this.

Corresponding changes made, but the entire body of code here needs some review. There's quite a bit of duplication of effort, compared to slap_client_connect(). Can we strip most of this out? Why does the privileged connection code not use the sb_authzID on the SASL bind, it always uses NULL instead? There are a lot more parameters supported by the bindconf mechanism, which the config parser will accept here (e.g. related to timeouts) that will not get used because slap_client_connect() is not being used.