[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
- From: hyc@symas.com
- Date: Wed, 2 Feb 2011 20:05:09 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/