[email protected] wrote: > [email protected] 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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
