Backend documentation?

[Andrew Bartlett]

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. 

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

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

> > Another approach which could be very interesting would be to use the
> > Heimdal code in Samba 4.0 to directly read the passwords from the MIT
> > KDC databases. 
> > 
> > However, frankly, these cavet's on fork() make a number of us wonder
> > about if Samba is long-term viable on OSX:
> > https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/fork.2.html
> > 
> > Other Samba users have successfully completed (via the MIT KDC key
> > store) a migration from OpenDirectory to Samba 4.0 as an AD DC. 
> 
> That’s not a acceptable way to go for me and my clients. We use OS X
> Server and OpenDirectory as a directory service because it’s lowcost,
> really easy to use and robust, created on really simple standard and
> powerful. It don’t have to be so complex like the AD DC. And my client
> are manly OS X based. For example, the one for who I look here is a
> small business with 200 Macs and 2 TS server. Go on the AD complexity
> for only 2 TS server isn’t a good way to go…

The reason to 'go the AD complexity' is that without it, you have an
increasingly poor upgrade path for windows clients (NT4 support is
long-gone, but by special arrangement we have Samba classic domain
support maintained in Windows, but you have to set registry keys), and
no ability to manage those clients with GPOs.  

The classic domain codebase is still a fully supported part of Samba
4.0, but the protocols it uses are getting quite old at this point, and
Windows stopped using them between current clients and servers over a
decade ago. 

Given this, I would suggest you have a good look at what your long term
migration plans are, just so you don't spent a great effort creating a
solution that can't last, and so you take a serious look at what Samba
4.0 could do for you (and what it can't, given it would trade the Mac
platforms native server for an AD server).  The vast majority of our
deployments are surprised by how easy Samba 4.0 is to set up and use as
an AD DC. 

Andrew Bartlett

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