A diagram would be nice. Are you aware of any? I'm one of the newbees that has spent untold hours reading Official Samba-3 cover to cover, reading howtos & sample configurations without getting an operational LDAP system to show for my efforts. I finally got a Qmail / Courier / Squirrelmail / LDAP system up & running, but that's another story...
It should be clear to all of us that LDAP is an area of great interest and dissatisfaction with regard to the SAMBA project. For proof, count the number of Samba List server messages that deal with LDAP. Just for fun, I ran following Google search: http://tinyurl.com/3yfbk Over 1000 messages were found. I couldn't find another topic with same number of hits.
"Samba-3 by Example" better be good!
Adam Williams 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.
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.
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
