[Samba] samba failed to authenticate to openLDAP

Craig White craigwhite at azapple.com
Fri Mar 4 06:30:35 GMT 2005


On Thu, 2005-03-03 at 16:58 -0800, Steve Zeng wrote:
> Paul and Craig,
> 
> I finally got it working. The reason it failed before is the way I built 
> the LDAP DIT. I also found a problem in smbldap-populate script which I 
> will describe below.
> 
> Here were what I did:
> 
> 1) run configure.pl
> 
> 2) edit smbldap-populate and change the following line:
> 
> my ($organisation,$ext) = ($config{suffix} =~ m/dc=(.*),dc=(.*)$/);
> 
> to:
> my ($organisation,$ext) = ($config{suffix} =~ m/dc=(.*)$/);
> 
> The reason is I only have a single name for my domain, i.e. "dc=mfelc". 
> but the perl script will suppose we have exactly two names, for example, 
> dc=idealx, dc=org. It also won't work if you have three names in your 
> domain. (dc=mydept, dc=mycompany, dc=com)
> 
> 3) run smbldap-populate
>     it works perfectly to build the DIT
> 
> 4) use smbldap-migrate-unix-accounts to migrate NIS accounts
> 
> 5) use smbldap-migrate-unix-groups to migrate NIS group
> 
> this time when I use smbclient with a NIS account, the log will show 
> wrong password. So I run smbpasswd to give this account a new samba 
> password and run smbclient again. it works.
> 
> There are two problems here:
> 
> 1) how to migrate NIS hosts into LDAP?
> 
> 2) I checked the LDAP attributes and found three password fieds:
> 
> SambaLMPassword
> SambaNTPassword
> userPassword
> 
> How can I sync them so that I don't have to keep two or more password 
> for one user account?
----
Sorry - I don't see the IDEALX scripts as much of anything but an
attempt to provide a turnkey solution to use LDAP as samba user backend
and thus, integration with other methodologies is where it breaks.

There are other packages such as LAM - Webmin - which are more than
capable of integrating passwords for SHADOW/POSIX and SAMBA stuff to
give the appearance of single sign on and you can probably hack the
IDEALX stuff into your own scripts for creating/deleting users.

There are also a lot of migration scripts included with openldap-server
package from redhat but not part of source tree of openldap which can
migrate all of the various stuff like netgroups/services/protocols/nis
but of course, this would be something you would have to reconcile with
your already existing DIT

The reason that a base would normally have two parts would be to follow
the convention of 'dc' - domain component and the typical internet
domain components that exist would be DOMAIN.TLD

i.e. example.com => dc=example,dc=com
     azapple.com => dc=azapple,dc=com

plus, the concept is to permit referrals that extend ldap beyond your
borders if you choose and others to make referrals to your DSA if you
choose. Then of course, there is the ability to integrate other things
such as DNS and hosts into your DSA which may make more sense with the
domain components as your base.

My understanding that the dc structure was a more recent adaptation and
the earlier versions of ldap and x.500 considered more of a
company.geographic structure...

AzApple             => o=azapple,c=us
Example Corporation => o=examplecorp,c=us

The base requirement being that the base of your DSA must be an object
permitted by your ldap server or you won't get anything to add
successfully.

and I am not the most knowledgable about these things and I'm quite
certain that someone can articulate these things with more precision
(Paul most likely can) but the bottom line is that it is your DSA and
you can do as you please and who is to say that it is a bad design
except you. There are times though, when you try to use specific tools
to accomplish a task and you may find yourself swimming against the
current and clearly, you have found one of those already. Thus, your
suggestions for making it work are good for others that likewise want to
break the normal conventions.

I would suggest that you consider the first 250 hours or so as
experimentation period and don't be afraid to dump your db, do some
find/replace type editing to the ldif files that you've been using and
keep restructuring until things make sense. Of course, you can slapcat
many different versions of your DSA to give you the flexibility you
need.

Craig



More information about the samba mailing list