ldb and OpenLDAP, *DON'T PANIC*

[Andrew Bartlett]

On Sat, 2005-05-21 at 21:38 +0200, Volker Lendecke wrote:
> On Sat, May 21, 2005 at 09:19:02PM +0200, Tony Earnshaw wrote:
> > LDAP must always come first, Samba's implementation of it second. If one
> 
> Ok, I think I have to adjust a bit here :-)
> 
> You have chosen Windows as a desktop operating system. Windows has its own
> notion about LDAP, in particular it has very special expectations what the DIT
> has to look like. That's what I mean with that you will probably end up with
> less features when running with an arbitrary tree. You can not expect Samba to
> fully convert any tree design into something that Windows expects from AD,
> there is simply too much variation possible in LDAP (as is probably the case
> with most of the OSI-based protocols... ;-) )

Indeed!

> This is what Andrew Bartlet meant with meta-directories: Some kind of
> translating replication might be necessary. 
> 
> What I meant: If you can live with the reduced functionality that the Samba 3
> based data model can offer, you will see a seamless Samba 4 backend. If you
> want more functionality than your data can provide, you will need to do
> something. Either dynamically translate/replicate, or convert your tree.

Indeed, it should indeed be possible to 'pear down' Samba4 to only
support the calls supported by NT4, and to have clients again think we
are NT4.  This should simplify the requirements on our data modal to the
extent that we can perform a crude translation to the Samba3 LDAP
schema.

However, I have a few worries about this approach:
 - We will not have a modal (other than NT4 itself) that we can match
interfaces to.  Samba3 already deviates from NT4, and Samba4 matches
Win2k3 when possible.  We know that exposing newer interfaces causes
clients to make assumptions about our capabilities, so we soon get into
a guessing game on 'which one?'.
 - NT4 support is end of life from Microsoft, so I would caution against
building new systems that rely on Microsoft not breaking NT4 servers.

On the upside, we might get away with just shutting off the LDAP and
Kerberos servers.  More investigation is needed.

Dealing with this the way Microsoft did - upgrading a local proprietary
database (like smbpasswd or tdbsam) to an AD-like representation is
comparatively easy.  Dealing with Samba3's pure flexibility in this area
will be a very, very different task.  

My personal view is that we should not block a release on dealing
correctly with the custom LDAP upgrade case, but that once we release,
and really understand what dynamics of our database backend, that we
then deal with both in-place Samba3 translation and some mapping of AD-
like structures onto a modified (but otherwise structurally intact)
organisational LDAP server.

Both of these present difficult computer science problems on their own,
and represent areas where we could use assistance of those who have
spent much more time dealing with this class of problem than I.  

These problems are also only a subset of the upgrade issues we will be
presented with: Samba4 currently only supports a subset of the smb.conf
options in use in Samba3.  Some of these options administrators will
hold near and dear to their heart, and we will have to decide which
still fit with the new Samba4, and what we do about the rest.

Samba3 isn't going away any time soon - this has been made very clear to
me.  We still haven't killed off all the sites running Samba 1.9, let
alone 2.2, so I expect Samba3 to have a long life ahead.

> Just an example: I can not imagine that we will ever support something like
> universal groups within the samba3 based model, nor do I see anybody pushing a
> sambaSamAccount-backed KDC into production. The latter one is not data model
> driven, but this would go far beyond what pdb_ldap was ever made for, and I
> simply don't see the anybody who would put enought energy into it.

Perhaps this is a bad example, as a sambaSamAccount based KDC does exist
(in Heimdal 0.7pre releases), but indeed this is not 'AD compatible' (it
is designed for POSIX clients) and that schema certainly cannot support
the things we require for AD compatibility.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20050522/7c0c3a9c/attachment.bin