Avoiding further (LDAP) stack proliferation in Samba

Uri Simchoni uri at samba.org
Thu May 21 05:17:17 UTC 2020

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

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

More information about the samba-technical mailing list