Backend documentation?

[Andrew Bartlett]

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:
> >> Hello Andrew, hello Scott,
> >> 
> >> Thanks for your answer.
> >> 
> >> Le 13 avr. 2013 à 00:27, Andrew Bartlett <abartlet at samba.org> a écrit :
> >> 
> >>> It should be possible to just forward-port the code Apple used with
> >>> Samba 3.0 (which they published per the GPL) and use that in later
> >>> versions.  The APIs involved haven't changed drastically in later
> >>> versions, but it will require work. 
> >> 
> >> I’ve already look the Apple source code for their Samba version, and
> >> it use the local directory service to run. So, the problem with that
> >> solution is we need to install it on a OS X, in place of SMBX, this is
> >> not a really update proof solution.
> >> 
> >> That's why I look to make a UNIX box on a side to make an adapter to
> >> translate AD to OD.
> > 
> > That's a very interesting approach. 
> 
> Thank you ^^
> 
> That’s what I need to keep things simple.
> 
> >>> Of course, you are free to re-implement this as well.  My understanding
> >>> is that OpenDirectory 'just' looks like a normal pdb_ldap (so wouldn't
> >>> require major changes), and the auth module could be rewritten based on
> >>> auth_winbind for example. 
> >> 
> >> Thanks a lot for the indication about pdb_ldap and auth_winbind, that’s what I looking for. I will study that.
> >> 
> >> A step forward, how do you register backend extension in Samba? On
> >> CentOS I’ve seen that backend for idmap are simple .so file on the
> >> disk. It’s the same for pdb and auth?
> > 
> > Yes.  Then set 'auth methods' to use it. 
> 
> OK
> 
> >>> The issue is things like password changes, which required an intensive
> >>> patch to the code, which like Apple's other changes, never got submitted
> >>> upstream.  
> >> 
> >> It depends of the Samba architecture. At a time in Samba, you should
> >> got the new password in clear text to be able to hash it in different
> >> ways? So it should be possible some how to forward it to the Apple
> >> PasswordService.
> > 
> > The issue is this:  To change passwords you need the old password hash
> > to verify the new password.  You need a way to get that old password
> > hash out of the PasswordService.  My understanding is that this is
> > intentionally difficult (part of the design, to try and keep all the
> > crypto inside that box). 
> > 
> > The same applies for being able to accept domain logins.  The auth
> > plugin code doesn't handle either of these cases, it just assumes passdb
> > provides read access to the hashes. 
> > 
> > Only then can we read the plaintext password.  At that point our passdb
> > backend can submit the plaintext passwords to the LDAP server using the
> > password change/set exop.  If the PasswordService will accept it, a
> > patched pdb_ldap could instead set it there.
> 
> Uh… Effectively, I can’t get the password hash out of the password service.
> 
> What I can do is use it as a blackbox password management service, I
> can authenticate at its as a user by requesting challenge and send
> back the answer, I can even ask for a replay authentication if the
> challenge has been created in other place for some kind of
> authentication schema (webdav for example) but I can’t retrieve the
> hash.

Then you won't (I've seen your second mail, but I want to answer this
question to clarify for others the limits of the modal) be able to do
anything more than be a 'member server' in the CIFS authentication
modal. 

> 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). 

> That’s why I can’t use Samba4 (and I’m pretty sure that’s are the same
> reason that lead Apple to move on their own SMB implementation…), 

No, Apple rewrote their own SMB server because they have been working to
remove GPL components from all parts of their OS stack.  They
specifically never incorporated any GPLv3 version of Samba, and so were
left on an old an increasingly old and unsupported version. 

> 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. 

> 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

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. 

> But that’s an other talks (and it will be a pleasure to talk about
> it).

I hope I've given you some clarity here. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org