Backend documentation?

[Yoann Gini]

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.

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?

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

I know it’s not a solution who can run for a long time, it’s a first step to fix a problem a take time to think about something more serious.

The problem with Samba 4 is simple, it’s a AD, a open source one, but it’s a full AD who need to many control on raw data. It can be useful for a company who run only Windows clients and who want open source server but that’s not the case of my clients. They want easy to use directory service with GUI admin tool and I want simple and fast to deploy setup.

With the unboxing included, I can setup a OS X Server with whole services (LDAP, Kerberos, DNS, CalDAV, CardDAV, Wiki, MDM, etc.) in one hour… And if I need to go done though the system to tweak some things, it’s simple, well document and well used software. 

That’s not the case today with Samba4, the system is to young, don’t have good GUI tool like we have on OS X Server and Samba4 need to control to many thing to be put in control of non power admin sys. OS X Server in small business are manage day to day by people who aren’t system administrator.

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

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…

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