[Samba] Samba and LDAP backend - howto docs problems?

[John Schmerold]

A diagram would be nice.  Are you aware of any?  I'm one of the newbees
that has spent untold hours reading Official Samba-3 cover to cover,
reading howtos & sample configurations without getting an operational
LDAP system to show for my efforts.  I finally got a Qmail / Courier /
Squirrelmail / LDAP system up & running, but that's another story...

It should be clear to all of us that LDAP is an area of great interest
and dissatisfaction with regard to the SAMBA project.  For proof, count
the number of Samba List server messages that deal with LDAP. Just for
fun, I ran following Google search: http://tinyurl.com/3yfbk
Over 1000 messages were found.  I couldn't find another topic with same
number of hits.

"Samba-3 by Example" better be good!

Adam Williams wrote:

>>>This is completely correct. It took me 6 weeks to document, test, and
>>>validate Chapter 6 of "Samba-3 by Example" - and it took 50 or so pages to
>>>sufficiently describe the steps that must be followed.
>>>While entirely essential, documentation that is logical, comprehensive and
>>>comprehendable is not a trivial process.
>>
>>From my experience over the last few days trying to get Samba 
>>installed, I don't think the documentation is at fault - there are some 
>>basic design flaws in Samba that you only see if you come to Samba with 
>>new eyes, ie you haven't configured Samba + LDAP before.
> 
> 
> I've been configuring Samba and LDAP services for years;  my
> interpretation of the travails of many newer users is that they don't
> grasp the divisions between the relevant subsystems: LDAP, NSS, SAMBA,
> etc...
> 
> 
>>1) Duplicated configuration
>>Samba's LDAP configuration exists in the smb.conf file. pam_ldap / 
>>nss_ldap's configuration exists in the ldap.conf file.
>>As these are two separate config files, what this tells me as a new user 
>>of Samba, is that Samba's LDAP handling is completely independant of 
>>nss_ldap's LDAP handling.
> 
> 
> No, it is pretty clearly stated that Samba relies on the NSS layer to be
> working correctly - hence the need for an /etc/passwd entry, or a
> posixAccount in LDAP, or a NIS entry, {insert wherever UID Number comes
> from}, etc...  This is why there is a winbind NSS module.
> 
> Maybe what we need is a good diagram.
> 
> 
>>I learn however that this is _not_ so - if nss_ldap is not configured 
>>correctly, Samba + LDAP won't work. 
> 
> 
> Neither will much of anything else.
> 
> 
>>Which leads me on to ask: Why does 
>>Samba not read the LDAP configuration from ldap.conf by default, instead 
>>of asking for the same information a second time?
> 
> 
> Because the filters, bases, etc... that Samba uses may be neccesarily
> different than the ones NSS uses.  NSS may be able to see content that
> Samba can not.
> 
> 
>>This is also a security issue - the root DN password for the LDAP server 
>>is stored twice. It is also a usability issue - six months from now is 
>>my replacement going to know that the LDAP password needs to be set in 
>>two places? Of course not.
> 
> 
> Your ASSUMING that the passwords are the same.  I expect they are not in
> most large installations, and should not be in any installation.  NSS
> needs to read, but never write, particular information.  Samba needs to
> accesses different information and should not have access to data it
> doesn't need, and certainly shouldn't have write access to data it
> doesn't need to modify.  Niether NSS nor Samba should be using the
> manager dn.
> 
> 
>>Then comes smbldap-tools. This package is written in perl, which has all 
>>sorts of magic string handling available, to extract the info it needs 
>>from either ldap.conf or smb.conf. But instead - it has it's own config 
>>file, with it's own definition of the LDAP server contact details, and a 
>>_third_ copy of the LDAP root DN password. At this point, security is 
>>out the window, as is any hope that I will remember how the password is 
>>changed six months down the line.
> 
> 
> Your not obligated to use smbldap-tools,  but I won't argue with you on
> that one.  I'm not a big fan.
> 
> 
>>2) Too Much Rope
>>When users / groups / etc are added to Samba via the normal Windows 
>>...
>>To have to learn perl before you can configure something as mainstream 
>>as Samba means that something has been designed wrong.
> 
> 
> You can write your own scripts in anything you like.  We are currently
> writing a set of modules/scripts in C#.
> 
> 
>>Note: I am not pointing these things out so as to knock developers of a 
>>piece of software that once it's configured correctly, works great. I am 
>>pointing these things out because as a developer, it is hard to 
>>anticipate the approach that will be taken by a new user of the 
>>software, as opposed to an experienced user of the software.
> 
> 
> 
>