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

[Jeremy Allison]

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
> parsers
> 
> 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?
> 
> (To be clear, we won't break stuff actually needed by FreeIPA, but
> individual codepaths might only be available to FreeIPA in some future
> release, or be only in selftest like the NTVFS file server, or be
> passed over the the FreeIPA side of the fence entirely).

Thanks for bringing this up Andrew. I would love to be
able to remove pdb_ldap and pdb_nds. They are legacy
connections from a time (NT-PDCs) that has long since
gone.

Even if we don't immediately remove the code, marking
them as deprecated should help put people on notice
that we don't have the resources to keep maintaining
these things forever.

So a big +1 from me.

Cheers,

	Jeremy.