deprecate pdb_ldap and "NT4-like" domains in Samba 4.13 to allow removal for Samba 4.14 in March 2021?

Alexander Bokovoy ab at
Wed Jun 17 19:23:36 UTC 2020

On ke, 17 kesä 2020, Jeremy Allison wrote:
> > I am not sure what is 'crufty' about this code. It actually works and
> > works surprisingly well. Sure, we might change smbldap to be based on
> > something else but what does it actually give us in reality? I am
> > genuinely asking because to me it would look like a lot of churn for
> > relatively small gain, if any.
> Well what I mean when I say 'crufty' is that it isn't being
> refactored/updated in line with other parts of Samba.
> The goal (my goal at least) is to reduce the number of
> different ldap client stacks in use in Samba. The less code
> we have to support internally the better.

In that case, both libldb and tldap are things we support internally.
smbldap is a rather thin wrapper over OpenLDAP libraries. It provides
an abstraction that is needed anyway. It sure assumes use of OpenLDAP in
some of the API (LDAPMessage, LDAPMod and similar structures) but that's all it
has, the rest is useful to consumers.

For example, Current PDB API expects paged searches (see SAMR OpenDomain /
EnumDomainUsers / EnumDomainGroups). libldb hides handling
of paged searches in a paged_searches module, some additional work would
be needed to allow communicating a starting point for the search offset
and a requested window size. It means direct 1:1 conversion is not

With tldap it is much better, the API is more or less equivalent of what
is already assumed, just better with asyncronous way of processing the
requests. And there is helpers API that can be reused to implement
things existing in smbldap.

That could be a plan for refactoring. I need to understand how to plug
in keytab-based authentication into tldap_gensec_bind() but since that
uses cli_credentials structure, it must be possible already.

> > I had somewhere an unfinished tree with some of smbldap refactoring but
> > I couldn't find it anymore. One of bigger refactoring was to move to use
> > tevent-based approach but it was not really needed for PASSDB because
> > this API is synchronous and doesn't care whether operations underneath
> > are asynchronous themselves.
> Sure - that's right. This is very similar to the libsmb client work,
> async tevent API's introduced underneath which drop seamlessly into the sync
> calls using a private event context wrapped with tevent_req_poll()
> calls to wait for completion.
> It doesn't help the sync operations at all, but basing everything
> on async calls underneath causes everything to go through one code
> path for testing, and the exposed async calls mean we have the flexibility
> to do non-blocking things later (even if we don't yet know what
> they will be :-).
> Synchronous-only API's are a dead-end IMHO :-).

I agree with that approach.

> > My attempt to see if I can use libldb for the same purpose led to
> > immediate crashes because libldb code is not capable to run against LDAP
> > servers with a schema that doesn't include (in DSE) attributes expected
> > by libldb. It makes it useless for the purpose of pdb_ldap and ipasam
> > PASSDB modules, for example. The crashes need to be fixed but it shows
> > there is very little testing of libldb against real world LDAP servers.
> That needs fixing. Can you log a bug for that explaining
> how to reproduce ?

I demonstrated it in my first response in the thread already, full with
a gdb session output showing the stacktrace and where the problem is. I
didn't file a bug, though, due to a lot of activity at the $DAYJOB.

> > I think adding a test environment that imitates a typical pdb_ldap usage
> > can also help with libldb testing coverage.
> 100% agree.
> > > Well that's good to know. But if Synology and QNAP need
> > > this also, then if would be good to hear from them directly
> > > on what their usage requirements are.
> > 
> > This can be said about almost all our users embedding Samba components
> > into their products. We hardly hear from most of NAS vendors on public
> > mailing lists, yet there is a lot of effort to maintain stable and
> > predictable API around file server operations.
> Actually we do hear quite a bit from the vendors using Samba,
> but many of them don't use the public lists for that. Most of
> their concerns are around the fileserver internals or winbind
> use - I've never heard any questions or comments raised around
> the passdb modules.

There could be multiple reasons for that. Perhaps, the code just
works and does not cause any problem for them, so no need to communicate
back. Given that it is definitely in use by products on the marked for
quite few years, I don't think it is because nobody uses them. ;)

> > I find this a bit
> > amuzing: there is a need to be fair at a treatment of various code paths
> > and yet somehow there is simply a rejection of that.
> I don't think that's completely fair - now I know
> you need this stuff there's no fear it will get removed,
> I now know who to bug when I need things looked at :-).


/ Alexander Bokovoy

More information about the samba-technical mailing list