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

[Graham Leggett]

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.

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

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

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.

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

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

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.

Regards,
Graham
--