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 05:35:30 UTC 2020

On ti, 16 kesä 2020, Jeremy Allison wrote:
> On Tue, Jun 16, 2020 at 12:53:50PM +0300, Alexander Bokovoy via samba-technical wrote:
> > On ti, 16 kesä 2020, Andrew Bartlett wrote:
> > > On Tue, 2020-06-16 at 11:26 +0300, Alexander Bokovoy wrote:
> > > > What is required from FreeIPA side is a set of operations to provide
> > > > implementation of PASSDB interfaces that deal with searches:
> > > >  - search users
> > > >  - search groups
> > > >  - search aliases
> > > 
> > > Can you do that on the FreeIPA side?  pdb_ipa isn't in the Samba tree,
> > > could you handle the maintenance of the code it depends on?
> > > 
> > > Presumably you have plenty of other ldap client stuff on the FreeIPA
> > > side of the fence you could plug into?
> > 
> > So basically you are saying that you don't care how FreeIPA would handle
> > integration to Samba PASSDB, neither you care about PASSDB being
> > testable and used. Is that right?
> No, I don't think anyone wants that :-). Alexander,
> why don't you clarify exactly what you need, and
> what you're using in Samba passdb ? That way we
> won't accidentally break anything.

ipasam implements all but few passdb calls. I need to complete some of
group/group type lookups and then it would be more complete.

The problem I see is not FreeIPA usage of those but rather lack of
testing in autobuild for the code paths that lead to the PASSDB calls.

For example, tdbsam has no support for group lookups, no trusted domains
support, and that means any related RPC calls will not get tested
upstream even though they are used in environments like FreeIPA.

It is on my side to add those tests and I am working on them. Since the
whole set is simply missing, it is not an easy job and requires time.

> > As far as I understand, same feature and support is available in QNAP
> > devices.
> > 
> > I personally don't think it makes sense to deprecate pdb_ldap now.
> Fair enough. But also as I said I didn't know you needed it :-).
> It is *very* old and crufty code though - maybe you could
> put some resources into helping maintain/update/refactor
> it to modern coding practices so it doesn't look so abandoned :-).

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.

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.

Andrew raised valid questions about ASN.1 handling that were part of a
recent CVE fixes in Samba AD. It doesn't though apply here because that
work is being done for us by OpenLDAP in the case of smbldap API.
CVE-2020-10704 is also a server-side LDAP implementation issue, not
affecting client side use in smbldap.

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.

I think adding a test environment that imitates a typical pdb_ldap usage
can also help with libldb testing coverage.

> > Instead, I hope to look into improving its test coverage now that we
> > have a good way to create test environments and use them in CI.
> 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. 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.

/ Alexander Bokovoy

More information about the samba-technical mailing list