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

[John H Terpstra]

On Wed, 10 Mar 2004, Graham Leggett wrote:

> John H Terpstra 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.
>
> 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.

Samba works with OpenLDAP, Sun iPlanet (Identity Server), IBM Tivoli
Directory server, CA's product, Novell eDirectory, etc. So precisely how
do you suggest we integrate all of these plus Samba so there is no
duplication _AND_ so that the resulting code can be maintained?

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

In my opinion, Samba has to remain independant of ALL system tools.

>
> I learn however that this is _not_ so - if nss_ldap is not configured
> correctly, Samba + LDAP won't work. 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?

You need to look MUST deeper than you have so far! Think through the
requirements of:

	A PDC
	A BDC
	A Domain Member Server

Ask youself:
	Do I EVER need to use local user accounts?
	Do I EVER need to use only Domain user accounts?
	Do I EVER need to permit access to users that come from a
		foreign Domain?
	Do I EVER contemplate having local users, Domain users AND
		foreign Domain users?

	How should local users be resolved?
		- Should NIS based accounts work?

You will quickly see that this demands use of NSS.

Next consider: How should authentication be implemented?
		- For UNIX/Linux users
		- For Samba access
		- For remote Windows user access via Samba

Soon you will see that PAM is only part of an essential answer.

Given that Samba is Open Source software, who has responisbility to affect
perfect integration? How will all the projects get integrated security and
authentication support?

Just remember:
	- The Samba-Team is not a massive corporation
	- We do not control any other project we may depend on

So precisely HOW can we solve all these difficulties? I can not provide a
better answer, other than the need for Open Source and Commercial open
public software standards - something I am already working towards
privately.

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

Sure it is! But I'd like to hear a proposal for a solution here. The only
viable answer I can come up with at this time is DOCUMENTATION and
training. I am involved in both of these. How can you help us to move this
forward?

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

I am very thankful to Jerome Tournier and the rest of the Idealx team for
making this valuable set of tools available. Make suggestions - Jerome is
very open to better answers and better solutions.

>
> 2) Too Much Rope
>
> When users / groups / etc are added to Samba via the normal Windows
> based admin tools, Samba allows the user to specify a script to do the
> job. This as a virtually infinitely flexible solution.

Yes sir! The beauty and the beast of Open Source. I could not have put it
better!

> But the average (99% of cases) system administrator does not need an
> infinitely flexible system, but rather a system that will get the job
> done with as little fuss as possible, and in as standard a way as
> possible, so that third party LDAP database editing tools need not be
> modified for this particular system's quirks.
>
> Too much rope here is a huge hinderance - as smbldap-tools does not seem
> to be laid out the same way as the Samba HOWTO suggests things should be
> laid out (as far as I can tell anyway), I must now go into code and edit
> it - which means I must brush up on my perl skills again to see what is
> going on.

The HOWTO is a document that aims to expound HOW the tools can be used.
The Samba-3 by Example book aims to provide working solutions. It is
unrealistic to attempt to do both in one book. Even as it is, the HOWTO is
too big. The major improvement I have planned for the HOWTO is improved
indexing - in time this will happen. As to content - please contribute.

>
> To have to learn perl before you can configure something as mainstream
> as Samba means that something has been designed wrong.
>
> 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.

To each his/her own.

- John T.
-- 
John H Terpstra
Email: jht at samba.org