[Samba] Samba and LDAP backend - howto docs problems?
minfrin at sharp.fm
Wed Mar 10 17:33:46 GMT 2004
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,
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
> 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.
More information about the samba