Bug 1292 - ldap machine suffix configuration directive does not work
Summary: ldap machine suffix configuration directive does not work
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts (show other bugs)
Version: 3.0.2a
Hardware: All Linux
: P3 normal
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-25 21:49 UTC by Ross Becker
Modified: 2005-08-24 10:22 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ross Becker 2004-04-25 21:49:39 UTC
Specifying the "ldap machine suffix" for samba does not appear to work. Despite
specifying "ou=Computers", Samba searches for machine accounts in the
"ou=People" container, which is what was configured for user accounts.
Comment 1 Gerald (Jerry) Carter (dead mail address) 2004-05-14 06:31:28 UTC
know design bug.  Doubt it will be changed soon.  Set 
nss_ldap to search both ou=computers and ou=people 
(or maybe add a referral to in ou+computers to continue 
the search in ou=computers)

Comment 2 Levente Farkas 2004-05-14 08:01:24 UTC
for nss_ldap you don't have to set ou=computers! just in /etc/samba/smb.conf and
/etc/smbldap-tools/smbldap.conf (if you use idealix).
adding a referral can't help since after that all pdbedit command failed eg:
# pdbedit -Lv Guest
ldapsam_getsampwnam: Duplicate entries for this user [Guest] Failing. count=2
Username not found!
another interesting thing is the above. it seems from it, that pdbedit search in
"ldap suffix" rather then "ldap user suffix" which seems tom me another bug,
since man pdbedit says: "The  pdbedit program is used to manage the users
accounts" an not machine account.
so currently the only solution to use ou=People in both smb.conf and smbldap.conf.
Comment 3 Ross Becker 2004-05-14 13:11:01 UTC
If this is not going to change, how about updating the documentation?  I blew
several hours on this before setting up ethereal and witnessing the behaviour,
and  finding a post about this on the high-traffic samba list was more luck than
anything. 

I can work around this now that I know, but the fact that the official
documentation does not mention this problem, and the samba 3 books simply gloss
over it and never explain that you NEED to use the same container because
specifying different containers will not work is really unhelpful.
Comment 4 Erik Carlseen 2004-07-09 14:03:36 UTC
Could somebody post some specifics as to which lines in which configuration
files need to be changed, for those of use who aren't quite on the same
technical level as those in this discussion?

Also, I must agree with Ross that this should be mentioned prominently in the
documentation. Even though (from my limited understanding based on this thread)
it appears to be some other software that is misbehaving and causing the
problem, it is still a fairly major issue for quite a few people.

Regards,

Erik Carlseen
Comment 5 Stephen Warren 2004-10-31 16:04:34 UTC
There appears to be a work-around here:

http://marc.theaimsgroup.com/?l=samba&m=108439612826440&w=2

which I found linked to from here, after some very lucky googling on the search
terms "smbldap-useradd.pl twice"

http://docs.biostat.wustl.edu/smbldap-tools/html/smbldap-tools007.html

Alternatively, one can hack smbldap-useradd.pl. If you change it to add some
dummy sambaSamAccount information to the new computer LDAP entry right after
adding the posix information (code is already there - just uncomment it...) then
attempting to add your PC to your Samba domain will work the *second* time you
click OK on the network ID window (at least with Samba 3.0.8 and W2K SP4)

Note: I also spent a lot of time attempting to get this working, based on
directions in the Samba documentation *and* the smbldap tools setting things up
this way. A quick note in the docs indicating this current issue would be really
helpful...
Comment 6 Stephen Warren 2004-10-31 16:18:32 UTC
Actually, what I've ended up doing is:

Putting regular user accounts in:

ou=Users,dc=wwwdotorg,dc=org

and computers into:

ou=Computers,ou=Users,dc=wwwdotorg,dc=org

then, update nss_ldap's /etc/ldap.conf to search your Users ou with 'sub'
instead of 'one', so it also looks in Computers:

nss_base_passwd         ou=Users,dc=wwwdotorg,dc=org?sub
nss_base_shadow         ou=Users,dc=wwwdotorg,dc=org?sub
nss_base_group          ou=Groups,dc=wwwdotorg,dc=org?one

and then configure both samba and smbldap_tools for the separate Users/Computers
ou's, just like normal (except the Computers ou has a different path). Note that
smbldap-populate.pl won't create the Computers ou correctly - delete the one it
creates, and manually create it as a child of Users.
Comment 7 Kenneth Thayer 2004-11-08 09:14:42 UTC
I like your fix, but I changed it a little. I  left the ou=computers alone and 
just put an alias in users to point to the computers OU and changed the 
searching like you said.  This way if they ever fix it I just need to delete 
the alias.  

dn: ou=computers,ou=users,dc=wwwdotorg,dc=org
objectClass: alias
aliasedObjectName: ou=computers,dc=wwwdotorg,dc=org




(In reply to comment #6)
> Actually, what I've ended up doing is:
> Putting regular user accounts in:
> ou=Users,dc=wwwdotorg,dc=org
> and computers into:
> ou=Computers,ou=Users,dc=wwwdotorg,dc=org
> then, update nss_ldap's /etc/ldap.conf to search your Users ou with 'sub'
> instead of 'one', so it also looks in Computers:
> nss_base_passwd         ou=Users,dc=wwwdotorg,dc=org?sub
> nss_base_shadow         ou=Users,dc=wwwdotorg,dc=org?sub
> nss_base_group          ou=Groups,dc=wwwdotorg,dc=org?one
> and then configure both samba and smbldap_tools for the separate 
Users/Computers
> ou's, just like normal (except the Computers ou has a different path). Note 
that
> smbldap-populate.pl won't create the Computers ou correctly - delete the one 
it
> creates, and manually create it as a child of Users.

Comment 8 Levente Farkas 2005-01-06 05:29:41 UTC
(In reply to comment #7)
> I like your fix, but I changed it a little. I  left the ou=computers alone and 
> just put an alias in users to point to the computers OU and changed the 
> searching like you said.  This way if they ever fix it I just need to delete 
> the alias.  
> 
> dn: ou=computers,ou=users,dc=wwwdotorg,dc=org
> objectClass: alias
> aliasedObjectName: ou=computers,dc=wwwdotorg,dc=org

this is not working on openldap-2.2.x:-(
adding new entry "ou=Computers,ou=People,dc=mkk,dc=hu"
ldap_add: Naming violation (64)
        additional info: naming attribute 'ou' is not present in entry
Comment 9 Kenneth Thayer 2005-01-17 14:51:20 UTC
(In reply to comment #8)
> this is not working on openldap-2.2.x:-(
> adding new entry "ou=Computers,ou=People,dc=mkk,dc=hu"
> ldap_add: Naming violation (64)
>         additional info: naming attribute 'ou' is not present in entry

Did you create Your OU (Organizational Units) before.... The error is it cant 
find the OU to put it in.
Comment 10 Levente Farkas 2005-01-18 04:13:44 UTC
here is a bit longer output:
---------------------------
adding new entry "ou=People,dc=mkk,dc=hu"
adding new entry "ou=Groups,dc=mkk,dc=hu"
adding new entry "ou=Computers,dc=mkk,dc=hu"
adding new entry "ou=Idmap,dc=mkk,dc=hu"
adding new entry "cn=NextFreeUnixId,dc=mkk,dc=hu"
adding new entry "uid=Administrator,ou=People,dc=mkk,dc=hu"
adding new entry "uid=Guest,ou=People,dc=mkk,dc=hu"
adding new entry "cn=Domain Admins,ou=Groups,dc=mkk,dc=hu"
adding new entry "cn=Domain Users,ou=Groups,dc=mkk,dc=hu"
adding new entry "cn=Domain Guests,ou=Groups,dc=mkk,dc=hu"
adding new entry "cn=Domain Computers,ou=Groups,dc=mkk,dc=hu"
adding new entry "cn=Print Operators,ou=Groups,dc=mkk,dc=hu"
adding new entry "cn=Backup Operators,ou=Groups,dc=mkk,dc=hu"
adding new entry "cn=Replicators,ou=Groups,dc=mkk,dc=hu"
adding new entry "ou=Computers,ou=People,dc=mkk,dc=hu"
ldap_add: Naming violation (64)
        additional info: naming attribute 'ou' is not present in entry
---------------------------
the problem is that this entry:
---------------------------
dn: ou=Computers,ou=People,dc=mkk,dc=hu
objectClass: alias
aliasedObjectName: ou=Computers,dc=mkk,dc=hu
---------------------------
has no
ou: Computers
line, but if you try to do so, tha comes another error, that ou attribute is not
allowed (since there is no objectcalss which contains it:-(((
has anybody try it with openldap 2.2.x?
Comment 11 Gerald (Jerry) Carter (dead mail address) 2005-02-09 06:16:03 UTC
This is fixed in 3.0.11 thanks to guenther.
Comment 12 Levente Farkas 2005-02-09 06:52:26 UTC
it's a good question what this bug about? if it's about ldap machine suffix,
than it's fixed (imho it was never broken). if it's about nss_ldap and that you
should have to use 
nss_base_passwd         dc=mkk,dc=hu?sub
nss_base_shadow         dc=mkk,dc=hu?sub
in stead of
nss_base_passwd         ou=People,dc=mkk,dc=hu?one
nss_base_shadow         ou=People,dc=mkk,dc=hu?one
then this bug is not fixed and should have to be open. or should i open another
bugzilla for this?
Comment 13 Gerald (Jerry) Carter (dead mail address) 2005-02-09 07:18:54 UTC
no bug wirt to nss_ldap.  Just use

nss_base_passwd         ou=People,dc=mkk,dc=hu?one
nss_base_passwd         ou=Computers,dc=mkk,dc=hu?one

no need to open any more bug reports about this.
Comment 14 Levente Farkas 2005-02-09 07:40:06 UTC
THANK YOU!
i already try this before, but it've not been working. not it's working!:-)))
Comment 15 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:22:01 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.