[Fedora-directory-devel] Fedora Directory and Samba4

[Andrew Bartlett]

On Mon, 2005-11-07 at 15:12 +0200, Mike Jackson wrote:
> Andrew Bartlett wrote:
> 
> > While Samba4 includes it's own LDAP server, we have made extensive
> > provision to back our data onto something like Fedora Directory, but I
> > want to work with fellow interested developers on the details:  What
> > would be reasonable for each end of the connection to do, particularly
> > as we try and map behaviours/schemas/expectations.
> 
> Hi Andrew!
> 
>   What on earth made you all decide to write your own LDAP server when 
> there are others available for free, which are already well tested and 
> feature filled, as well as having plugin architectures (both FDS and 
> OpenLDAP)? Just curious.

Samba has a long history of use of OpenLDAP as the standard backend
behind Samba3 (of course any LDAP server would work, but OpenLDAP is
what we documented, because it is free and included in most
distributions).  It caused us, and in particular our administrators a
lot of pain, because of the separate configuration required.  

In building Samba4 we looked at OpenLDAP (Fedora Directory was not Free
Software at the time we started Samba4), and determined that while
clearly possible, it would be very difficult to integrate into a single
cohesive whole.  (We know it is possible, because PADL's XAD is Samba3
+OpenLDAP+Proprietary bits, and it manages much of what Samba4's goals
are)

We have some simple requirements on samba4:
 - Portable:  Must, with a minimum of external libraries, build on a
wide variety of unix and even non-unix platforms
 - Simple:  Setup must be possible from the built-in web-based
administration, as well as a single, simple config file.
 - Fast:  Samba has always benefited from the speed of it's
shared-memory databases.
 - Integrated:  We needed consistent behaviour across the whole Samba4
suite of services.  This included authentication in particular.

As such, we are not dependent on the administrator correctly configuring
a backend directory on their platform correctly before we can even
start, and we can self-configure those services.  

More than all that however, we expected that we would have changes that
we required that went beyond established plugin architectures, and as
such could not afford to ship and maintain our own branch of OpenLDAP or
indeed FDS.

Tridge then wrote ldb, and things ran from there... 

>   FDS has support for several types of plugins (pre-bind, post-bind, 
> post-op, etc), and nearly all of the server's functionality is 
> implemented with them. I am guessing that if Samba4 has special needs 
> wrt behaviour from the LDAP server, then it's time to design and 
> implement a "Samba 4 Plugin" for FDS (same things can be done for 
> OpenLDAP, they are just called "overlays").

So, the way I would like to have things work is to have Samba4 handle
the details about authenticating users, perhaps much of the
cn=configuration subtree, and suchlike.  The backend LDAP server (such
as FDS) might then handle the actual user and server entries, possibly
not even in the same structure as Samba4 presents to windows clients.  

Somewhere in there we would probably need schema translation (I presume
an administrator choosing to run Samba4 against a backend LDAP would not
want to be using the AD schema), as well the implementation of
operational attributes etc.  (There are quite a few of these, which we
are just starting on now).

Another little detail that gets quite messy is NT ACLs on entries.  We
could evaluate these either in Samba4 (and act on the backend as a
privileged user) or we might need to put that into another plugin.

> Plugin Programmers Guide:
> 
> http://www.redhat.com/docs/manuals/dir-server/plugin/7.1/pluginTOC.html
> 
> 
>   I wrote an OpenLDAP -> FDS schema conversion tool and published it on 
> the FDS wiki.
> 
> http://www.directory.fedora.redhat.com/download/ol-schema-migrate.pl
> 
>   Feel free to include it in the examples/LDAP directory of Samba if you 
> like.

I'll take a look.

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: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20051108/7dacf8df/attachment.sig>