Avoiding further (LDAP) stack proliferation in Samba

[Uri Simchoni]

Does LDB (as client) have the full AD integration (Kerberos, sasl
wrapping)? IIRC Only libads had that and then in 2015 the mentioned
winbindd change added that to tldap.

Protocol-wise, ldb coveres more than tldap (vlv control to name one
example).

On 5/21/20 2:47 AM, Andrew Bartlett via samba-technical wrote:
> G'Day Sswen and Christian,
> 
> As this is a more 'meta' question, I wanted to write to the broader
> mailing list in regard to: 
> https://gitlab.com/samba-team/samba/-/merge_requests/1351#note_346327256
> which is following on from Jermey's comment: https://gitlab.com/samba-team/samba/-/merge_requests/1258#note_320352109
> 
> I'm really sorry this discussion has come up on what might, in other
> circumstances been a great demonstration of showing the broader design
> that started the tldap changes.
> 
> Jermey asked earlier to see the broader designs and given the broader
> implications I think it is appropriate to have that raised on the list
> here.  
> 
> Explaining our plans in public before we have code is not something we
> do well in Samba - we fear (and this mail shows that is a genuine fear)
> that others will jump in and suggest things.  Much easier to have the
> code finished and put any questions to bed with: well, this is written
> and works!
> 
> However, I quite strongly feel that we should not further proliferate
> the new or substantial new use of tldap in Samba without:
>  - offsetting work to reduce, not increase the number of LDAP protocol
> stacks
> and
>  - substantial sharing of structures, ASN.1 parsing and other utility
> code
> 
> My preference, as these are all sync or local callback based calls is
> that you implement this with LDB.  LDB is a mature, extensively used
> LDAP client library (not just the directory store for the AD DC).  
> 
> The routines you would need are ldb_search() and ldb_request().  The
> timeout can be easily set on each request and I can assist with further
> guidance if need be.
> 
> It might be that LDB as a whole is not suitable.  If so then I would
> ask you instead implement other offsetting measures between all our
> LDAP client libs.
> 
> We have seen in many other areas of Samba the incredible cost of code
> duplication.  The efforts needed to merge the s3 and s4 RPC stacks has
> been monumental.  The gap between the s3 and s4 loadparm systems
> continues to create headaches that make it significantly harder than it
> should be to just select and use the best of Samba's library code!
> 
> We have also seen this done well, where the new better API is
> introduced on the basis that it also provide an emulation for and often
> eventual elimination of the old API.  As examples:
>  - Andreas introduced a new set of macros (PULL_LE_U32 et al) for
> reading and writing integers, and the old macros (SIVALX et al) use
> those.  The NDR callers have already been converted.
>  - The python3 comparability API was introduced for the py2/py3
> transition and is now almost totally removed.
>  - gensec wrapped the old source3 authentication code first as a 'no
> change' and then slowly the parts under it were merged.
>  - the datagram messaging system is now common, underpinning both
> messaging APIs.
> 
> You might ask why I didn't make this comment in 2015 when the idmap_ad
> code was written, and why that prior art isn't a good enough guide?
> 
> I'll just say that the history of LDB in the Samba Team has been
> fraught, and it would not have been wise of me to make a criticism to
> those involved, at that time.
> 
> But I must raise this now, before we end up with three fully-fledged
> LDAP client stacks in Samba!
> 
> Andrew Bartlett
>