ldap_set_option() of LDAP_OPT_X_TLS_REQUIRE_CERT

[Todd Lyons <tlyons@ivenue.com>]

Hello, I'm a developer on the Exim MTA and I have some questions about
differing behavior I am seeing across different systems.  I would like
some suggestions about the best way to handle each issue.

First, I have not gotten "a ton of complaints." One person contacted
me with the issues I am describing below.  I do not know his server or
client versions, other than his workstation is Debian Squeeze.  I'll
just refer to him as "the guy".

Second, my test server is running openldap 2.3.34, my workstation on
which I am running my test builds of Exim is using openldap 2.4.28
client libs.

Issues:
1. When multiple servers are specified, our ldap code just did an
unbind to all servers defined when it was finished. The guy contacted
me with the problem that the unbind call hangs when one of the ldap
servers was unavailable for whatever reason.  On *my* system, the
blind unbind worked properly no matter if the bind succeeded.

I modified the ldap code so that it only unbinds if the original bind
succeeded.  That seems the proper/correct way to handle it in all
cases, so this issue really is already solved.  I'm just wondering if
there are any gotchas I might be missing by doing it this way.

2. A few months ago I helped (a different) someone troubleshoot a
really strange problem where setting the LDAP_OPT_X_TLS_REQUIRE_CERT
option in our code did not have any impact on his machine.  Our code
set that option per connection. It turns out that, for him, setting
that option per connection did not affect the TLS require cert option
that the bind used.  He found some comment somewhere advising that
NULL for the ldap handle sets the option globally in the ldap client.
We tried it and it solved the problem for him.  I saw identical
behavior on my system (NULL worked, ldap handle did not) so we assumed
that the code had never really worked properly.  I then changed our
ldap code to use NULL instead of the ldap handle when setting the TLS
require cert option.

The guy (with the current problem) runs a system that worked just fine
previously, but using the new code (NULL instead of ldap handle when
setting TLS require cert option) does not affect the TLS require
certificate setting when his bind is attempted.  After much testing
and debugging, I had him merely change that one line back to using the
ldap handle in ldap_set_option() and it then worked properly for him.

So I have two systems (mine and his) which behave differently after
the ldap_set_option() on LDAP_OPT_X_TLS_REQUIRE_CERT.  In a fit of
psychotic testing, I decided on my system to just blindly set it both
globally and per connection.  It worked, and produced no errors.  That
surprised me, I expected one or the other to complain.

My potential code looks like the following (apologize if Gmail wraps),
can you explain any pitfalls of doing it this way?  Should the two be
#ifdef guarded by client lib version checks or something?

    /* Use NULL ldap handle b/c is global in some client libs */
    rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert_option);
    if (rc)
      {
      DEBUG(D_lookup)
        debug_printf("Unable to set TLS require cert_option(%d) globally: %s\n",
          cert_option, ldap_err2string(rc));
      }
    /* Use current ldap handle b/c is per-connection in others */
    rc = ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert_option);
    if (rc)
      {
      DEBUG(D_lookup)
        debug_printf("Unable to set TLS require cert_option(%d) on LDAP server "
                     "%s%s: %s\n",
          cert_option, host, porttext, ldap_err2string(rc));
      }

Any comments or suggestions are appreciated.

...Todd
-- 
The total budget at all receivers for solving senders' problems is $0.
 If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine