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

[John H Terpstra]

On Wed, 10 Mar 2004, Graham Leggett wrote:

> Adam Williams wrote:
>
> > 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...
>
> This is largely because the distinctions are not clear. It should not be
> necessary for a Samba installation to take days, as this one has, even
> by an experienced Unix administrator, as I am. I have had significant
> experience with LDAP, but not with Samba and LDAP together, and I am
> still struggling.

We feel your learning curve pain with you. How can we solve this? What
specifically should be done to eliminate the pain? Who should do this and
how?

You may want to take this discussion to Samba-Technical. Better still,
come along to the SambaXP Conference in Germany:
	(see: http://www.sambaxp.org)
Bring it up there and get access to a forum that can material affect a
solution to this problem.

>
> > No, it is pretty clearly stated that Samba relies on the NSS layer to be
> > working correctly
>
> I am sure it's clearly stated - somewhere. I didn't see it in the docs I
> was reading though.
>
> >>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.
>
> Which brings me back to "too much rope". Yes, about 1% of admins are
> going to want a complex system, and might want to have setups where the
> Samba attributes and the posix attributes are read by different users,
> but 99% of cases will be where there is a "system" user of some kind
> that can query the directory. I see no need for the posix subsystem and
> the samba subsystem to use separate LDAP accounts.
>
> What Samba should do by default is read LDAP parameters from ldap.conf,
> with the option to override the parameters if the admin so chooses, thus
> making Samba easy and straightforward for the admin to use out the box.

You are assuming that Samba only needs to work with OpenLDAP. You are also
assuming that ALL OpenLDAP configurations use the same directory
structure. Too many assumptions. How can we implement a universal
solution? What must we do to arrive at nirvana?

>
> > 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.
>
> And you are assuming they are different. Why should the system be any
> more complex than it needs to be?

That is an administrator decision that Samba can not impose.

>
> The pam_ldap stuff is really simple. It defines a DN to bind to to
> perform "everyday" user based read only searches, as well as a DN to
> bind to when doing potential admin work requiring write access, such as
> changing passwords or adding users. Defining different DNs to the above
> for Samba to do almost identical tasks is just making the job harder
> than it needs to be.

Again, your assumption is that Samba only needs to work with OpenLDAP.
Samba has to work with many LDAP servers. This adds considerable
complexity.

>
> > Your not obligated to use smbldap-tools,  but I won't argue with you on
> > that one.  I'm not a big fan.
>
> Are there alternatives?

Yes. Discussed in the Samba-3 by Example book - which will be released to
open source as soon as I get the OK to do so.

>
> >>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#.
>
> There are many things I "can" do with Samba, the majority of which are
> simply not worth doing - I could just deploy a Windows machine and
> achieve the task at hand in one tenth of the time, and just put up with
> the instability of the platform. The unnecessary complexity of the
> typical Samba installation negates most of the advantages of Samba's
> stability, because problems introduced by complexity are experienced as
> stability problems, and we're back to square one.

And every constraint we put into Samba results in feedback that we just
lost another user site because we have tightened the noose. This is open
source software. We try NOT to limit the usability of Samba.

>
> Samba's usability is a big issue - An admin cannot be expected to take
> days of research, hours and hours of reading manuals, and the obligatory
> trips to Google to achieve what a Windows admin can do in a few clicks
> of a mouse.

Then suggest a better solution please. After 1 year of writing, exploring,
discussing with Windows and UNIX admins I have received more feedback than
I can deal with at once. Here is my dilema: I started to update the HOWTO
that was shipped with Samba-2.2. I thought I would spend 1-2 weeks
updating it - it took 7 months full time.

Out of the HOWTO update came a request (almost a demand) that chapter 2 of
the book should be mirrored at the end of envery chapter. There are 18
pages in chapter 2. There are 40 chapters in the book. 40 x 18 = 700+
pages, ergo - another book. I had to get the HOWTO completed. So I decided
to help Samba users by writing a book that provides clear descriptive
example solutions that are fully documented. The result of that book is
the "Samba-3 by Example" book.

Out of the review process for the "Samba-3 by Example" book has come
incessant requests (demand) for better documentation on OpenLDAP. A book
called "OpenLDAP by Example" is presently being written.

You know, sometimes I just wonder, "Is this all worth the pain?"
Of course, I answer "Yes!", but pardon my doubting it a little. :)

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