[Samba] LDAP issues

[Alex Moen]

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