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