[Samba] LDAP issues
Alex Moen
alexm at ndtel.com
Sat Jan 28 10:49:16 MST 2012
>>>> I didn't go too deeply on your issue, but it seems to me that
>>>> since you have:
>>>>
>>>> ldap user suffix = ou=People
>>>>
>>>> You cannot simply have:
>>>>
>>>>> dn: uid=testuser at mydomain.com,ou=mydomain,o=ndtc
>>>>
>>>> But should have instead:
>>>>
>>>> dn: uid=testuser at mydomain.com,ou=People,ou=mydomain,o=ndtc
>>>>
>>>> Am I wrong?
>>>>
>>>
>>> Nope. You're right. I have removed the "ou=People" line. Still
>>> no joy.
>>>
>>
>> I suppose that you cannot simply remove it. You have to tell Samba
>> where the user's container resides.
>> Judging from your LDIF, your users seem to reside directly on
>> ou=mydomain? Maybe you should look at the whole ldap arrangement...
>> The structure just doesn't seem right...
>
> I hear you, but this existing structure is in production, and has
> been for several years. It isn't really going to change now,
> without really causing a whole lot of trouble.
>
> New information: I finally got the username to be recognized. I
> have added "username map = /etc/samba/usermap.txt" in smb.conf, and
> added the entry "alexm at mydomain.com = alexm" in usermap.txt.
> Eureka! The logs show that "Get_Pwnam_internals did find user [alexm at mydomain.com
> ]!".
>
> Now, I just have to figure out how to make the groups work... I have
> about 50 groups that I need to process. When I try to add a new
> group using the smbldap-tool smbldap-addgroup, I get an error
> stating "failed to add entry: Attribute is not allowed : cn at /usr/
> share/perl5/vendor_perl/smbldap_tools.pm line 789.". For some
> reason, it does not like the cn that is trying to be added to the
> dn: ou=Groups,ou=ndtel,o=ndtc, objectClass: organizationalUnit, ou:
> Groups organizational unit. Now, an OU is not allowed to have a cn,
> that's part of an organizational role or organizational person. So,
> I'll have to do some troubleshooting to find out what they intended,
> and make their scripts work properly. The docs aren't very up-to-
> date, so I'm fighting that a little.
>
> Thanks for all the help so far, everyone...
To follow up and finalize, this is now SOLVED.
First of all, I am using the IDEALX scripts (renamed now to smbldap-
tools, but the IDEALX names sticks for backwards compatibility,
apparently; they're located at http://sourceforge.net/projects/smbldap-tools/)
. The ldap server I am using is an OpenLDAP-based server made by
Mirapoint. Now, the scripts have a couple of changes that need to be
done in order for them to work with, at least, this incarnation of
OpenLDAP. Here are the diffs, if anyone wants them:
diff /usr/share/perl5/vendor_perl/smbldap_tools.pm.org /usr/share/
perl5/vendor_perl/smbldap_tools.pm
783c783
< objectClass => [ 'top', 'posixGroup' ],
---
> objectClass => [ 'top', 'organizationalRole',
'posixGroup' ],
diff /opt/IDEALX/sbin/smbldap-populate.org /opt/IDEALX/sbin/smbldap-
populate
312c312
< objectClass => [qw(top posixGroup sambaGroupMapping)],
---
> objectClass => [qw(top organizationalRole posixGroup
sambaGroupMapping)],
324c324
< objectClass => [qw(top posixGroup sambaGroupMapping)],
---
> objectClass => [qw(top organizationalRole posixGroup
sambaGroupMapping)],
335c335
< objectClass => [qw(top posixGroup sambaGroupMapping)],
---
> objectClass => [qw(top organizationalRole posixGroup
sambaGroupMapping)],
346c346
< objectClass => [qw(top posixGroup sambaGroupMapping)],
---
> objectClass => [qw(top organizationalRole posixGroup
sambaGroupMapping)],
357c357
< objectClass => [qw(top posixGroup sambaGroupMapping)],
---
> objectClass => [qw(top organizationalRole posixGroup
sambaGroupMapping)],
402c402
< objectClass => [qw(top posixGroup sambaGroupMapping)],
---
> objectClass => [qw(top organizationalRole posixGroup
sambaGroupMapping)],
424c424
< objectClass => [qw(top posixGroup sambaGroupMapping)],
---
> objectClass => [qw(top organizationalRole posixGroup
sambaGroupMapping)],
435c435
< objectClass => [qw(top posixGroup sambaGroupMapping)],
---
> objectClass => [qw(top organizationalRole posixGroup
sambaGroupMapping)],
446c446
< objectClass => [qw(top posixGroup sambaGroupMapping)],
---
> objectClass => [qw(top organizationalRole posixGroup
sambaGroupMapping)],
As you can see, I had to add the organizationalRole ou to each group
instance. That's because, in at least the Mirapoint implementation of
OpenLDAP, the posixGroup schema does not allow a cn value... Or,
maybe I added it when I set the server up (it was about 3 years ago,
and I haven't had to touch it since), the posixGroup schema I used was
old/broken/incomplete/outdated, take your pick. Regardless of the
cause, rather than change the posixGroup schema on the server, I took
the easier (for me!) route of "fixing" the scripts to work with my
ldap server.
OK, once that was done, all the smbldap group commands worked. I was
able to add the groups that my user needed. Then, it was just a
matter of changing (syncing? updating? creating?) the samba user
password, and everything was working.
So, the combination of using a usermap (email_address =
windows_username, for instance, alexm at mydomain.com = alexm) and
getting all the background data required for samba into the ldap
directory did it. The usermap is what saved my hide.
Thanks all for the help contributed to this problem and my
education... I appreciate it!
Alex
More information about the samba
mailing list