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

[Adam Williams]

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