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: [email protected],ou=mydomain,o=ndtc
But should have instead:
dn: [email protected],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 "[email protected] = alexm" in usermap.txt.
Eureka! The logs show that "Get_Pwnam_internals did find user [[email protected]
]!".
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, [email protected] = 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
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
