Backend documentation?

[Yoann Gini]

Le 14 avr. 2013 à 05:45, Andrew Bartlett <abartlet at samba.org> a écrit :

> On Sat, 2013-04-13 at 13:35 +0200, Yoann Gini wrote:
>> Le 13 avr. 2013 à 13:06, Andrew Bartlett <abartlet at samba.org> a écrit :
>> 
>>> On Sat, 2013-04-13 at 10:45 +0200, Yoann Gini wrote:
> 
>> In the samba architecture, do you have a service layer to adapt
>> authentication request to database model? Or is it directly from the
>> Samba core to the backend?
> 
> This exists, but only for the operations we needed to abstract to be a
> member server, where we don't hold the password hash.  For operations
> implemented on the DC, we haven't abstracted that.  Because we always
> have the hash in this case, there hasn't been a compelling reason.  (The
> exception here would be the Read Only Domain Controller in AD, but
> that's AD and so a totally different stack). 

OK I understand it better, and indeed, a Read Only Domain Controller in AD is exactly what I looking for.

>> even if you have done a really impressive work on it, but at the end,
>> you have done a open source AD controller when samba3 was an open
>> source AD adapter, here is the glitch.
> 
> I should clarify some terms, Samba before version 4.0 is not an AD
> server, instead it provides what we call a 'classic' domain, with NT4
> like capability (but more modern crypto).  The AD DC has never been able
> to successfully use anther backend. 

OK, indeed they have a difference.

>> A really big improvement to Samba4 for the future will be to just fit
>> in a existing open environment, not like today where we need to move
>> all service on Samba4 control…
> 
> I've addressed why it isn't possible to use a different backend in depth
> here:
> 
> https://wiki.samba.org/index.php/Samba4/FAQ

I’ve already read it and understand why those choices has been made in your roadmap. But it not fit to all kind of requirement, especially when the requirement is: fit in the existing environment.

> In the same way, you could ask why your MacOS X server stack cannot use
> a different backend.  What has changed is that now you have two
> different tightly-bound stacks that cannot use an alternate data store. 

In fact, OS X Server stack is highly configurable and the whole system can be totally integrated in AD or any LDAP based system out of the box, it just a question of mapping, The DS backend is able to read any LDAP to retrieve what they need based on a XML config file (who can be stored on the LDAP also), even better, if we miss some attributes in the existing schema, the client can recompose it with other fields, we static values or can use a second LDAP in the same time to store augmented data. And if you want, you can even write your own backend to the DS client to connect OS X and OS X Server to anything you want, that what Novell has done for ePlanet for example.

But it’s mean they have an other directory server running somewhere. That not solve the « keep it simple » problem.

Nevertheless, thanks a lot for your time on this subject!