deprecate pdb_ldap and "NT4-like" domains in Samba 4.13 to allow removal for Samba 4.14 in March 2021?
cs at samba.org
Wed Jun 17 16:48:20 UTC 2020
On Tue, Jun 16, 2020 at 12:04:19PM +1200, Andrew Bartlett via samba-technical wrote:
> With all the recent talk about ldap stacks, I wondered if we could
> discuss deprecating and eventually removing pdb_ldap?
> The reason is that pdb_ldap is primary user of smbldap. smbldap is in
> turn yet another of our ldap stacks (I have found four so far), in the
> sense that while it uses OpenLDAP under the hood, it replicates with
> libads, ldb and tldap the 'get AD-thing out of an LDAP reply' part.
> I've huffed and puffed about so much over the past little while that
> sometimes it isn't clear what I'm really most frustrated by, but it
> comes down to:
> - number of LDAP ASN.1 parsers
> and in particular
> - number of incompatible stacks (structures and helpers) above those
> For example, these functions all do the same concept:
> - smbldap_get_single_attribute
> - tldap_talloc_single_attribute
> - ads_pull_string
> - ldb_msg_find_attr_as_string
> We likewise have the client-side handling for paged searches in:
> - ldb (paged_searches module)
> - libads/ldap.c
> - lib/smbldap.c
> - tldap
> Of the two, I (perhaps strangely) actually care most about the upper
> 'helper' layer, because it is in this that we encode Samba and AD style
> LDAP on top of LDAP. If you look around the functions I list there you
> see so much borrowed, but never made common between them.
> The extensive smbldap layer, largely in duplicate with the others, is
> provided for pdb_ldap (and the pdb_nds for Netware, remember that?),
> net sam (for pdb_ldap installations), idmap_ldap and idmap_rfc2307.
> While it would hit a significant number of large and legacy sites that
> still have not made the move the AD, but I wondered if we could
> deprecate pdb_ldap?
> pdb_ldap has never been automatically tested, and is primarily in
> support of NT4-like domains (which we should deprecate at the same
> time, for consistency).
> Merge work is hard, particularly when the users are untested. Removing
> smbldap would reduce by one the number of LDAP stacks, and allow us to
> focus on finding a common way forward for ldb, tldap and libads without
> needing to accommodate smbldap as well (presuming that the idmap
> modules can be migrated).
> What do folks think, can we move on from these features in 2021?
From what i see, this is still being used. The main usecase i see with
users is having a stand-alone file server with all the backend data
(including the Samba/SMB specific objects and attributes) stored on a
LDAP server. One of the reasons is probably to not depend on Active
If we decide to move away from this code, i would vote for a long
deprecation period, so that we can get the message out and users can
More information about the samba-technical