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
Attachment:
signature.asc
Description: This is a digitally signed message part
