Avoiding further (LDAP) stack proliferation in Samba

[Andrew Bartlett]

On Thu, 2020-05-21 at 14:43 -0700, Christof Schmitt via samba-technical 
wrote:
> On Wed, May 20, 2020 at 07:19:59PM -0700, Jeremy Allison wrote:
> > 
> > That sounds like a sensible plan to me, but having said
> > that I'm not going to be the one doing the work :-).
> > 
> > As we as a community have decided tevent_req is "The Way"
> > then helping our older stacks integrate better with it
> > is certainly a good way to make progress IMHO (and I'm
> > as guilty as anyone as the author of the horrible hack inside smbd
> > to do async opens which sidesteps tevent_req in order
> > to reduce code changes).
> 
> So i am trying to understand where this leaves us. The driver behind
> Swen's patchset is to move away from libads with the end goal of
> being
> able to better control the domain controller selection.
> 
> Now there is tldap and ldb as possible ldap libraries. Do we need to
> look at the integration of those components first, before adding the
> ldap library usage in winbindd?

Yes.  I think so.  I know this sucks - being told to stop on a fairly
simple change because we should do a much larger thing, but I'm really
passionate to avoid having three full stacks. 

> The goal of having one ldap client stack is worthwhile. From what i
> can
> see, tldap implements the async tevent model, with the exception of
> the
> gensec part. Also the async calls are currently not used.
> 
> I have not looked in ldb much, on a quick look, it seems to use the
> openldap library again. Would it make sense to have ldb use tldap as
> backend and eventually move away from openldap?

While there is a historical OpenLDAP backend in LDB (a legacy from a
time when being a semi-independent project was critical, possibly still
used by sssd) Samba uses lib/ldb-samba/ldb_ildap.c for all ldap*://
URLs, which is based on libcli/ldap.  This one brings in the full suite
of GENSEC, Kerberos etc.

I'm not opposed to the concept that libcli/ldap and tldap are merged in
some way and see particular opportunity for tldap to use the LDB
structures (which would reduce further the code in ldb_ildap). 

For another approach, if the initial issues are around timing handling
in the OpenLDAP libs under libads, significant advantage could come
from rebasing libads on LDB.  libads is a sync API (and stuck at that
for now) so the LDB sync API would be a good match.  Doing so would
make things like our 'tls *' parameters work consistently for all our
outbound TLS connections, which would be a big win. 

I realise this is not what you were hoping, but perhaps we can find a
way forward here.

Andrew Bartlett
-- 
Andrew Bartlett                       https://samba.org/~abartlet/
Authentication Developer, Samba Team  https://samba.org
Samba Developer, Catalyst IT          
https://catalyst.net.nz/services/samba