Last note, The obvious next step was to remove all suffix parameters from smb.conf, and set the ldap.conf accordingly. The LDAP log now shows everything with a search base of dc=adastral... which is what I expect, however the error has not been fixed.
Thanks, Neil. On Tue, 2004-08-17 at 10:48, Neil Marjoram wrote: > Couple of other notes to my email this morning. > > I changed the aldeburgh$ entry to give it a shell and directory, I can > now su - aldeburgh$, the LDAP log shows a search base of ou=People as I > expected. So concluded that /etc/ldap.conf is OK. > > smbclient -L server -U username > > The LDAP log for this also shows a search base of ou=People, which I > expected from smb.conf ldap user suffix = ou=People > > I gave the machine account a password and, > > smbclient -L server -U aldeburgh$ > > session setup failed: NT_STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT > > Which I expected, but the LDAP log shows a search base of dc=adastral... > which I didn't expect. Which to me suggests that samba has not picked up > "ldap machine suffix = ou=People". smbclient must distinguish between > user accounts and machine accounts by the $? So it follows that it > should use the "ldap machine suffix" parameter, but it doesn't, or > can't. If Samba needs the "ldap user suffix" and "ldap machine suffix" > to be the same as it now is in my case and it doesn't use for what ever > reason the "ldap machine suffix" then it doesn't work because now they > are different (machine suffix picks up a default or dc=adastral from > ldap suffix = ?). smbclient can still see the aldeburgh$ user(machine) > in the LDAP database and is able to use the entry as it reports that it > is a workstation trust account. > > Did anyone understand that ? In one line I think my install of samba is > not reading or using the ldap machine suffix setting. > > Samba version : samba-3.0.5-2 > OS : Redhat 9 > > Thanks, > > Neil. > > > On Mon, 2004-08-16 at 17:24, Paul Gienger wrote: > > Andrew Reilly wrote: > > > > >>Maybe so, but this also incurs the extra overhead of searching the > > >>entire DIT for account information. While it is true that you can most > > >>likely tune your directory server to guard against performacnce issues, > > >>widening your search scope is a Bad Thing (TM), especially if you store > > >>much else than posix account information. > > >> > > >> > > > > > >Would be interested if you have any metrics regarding > > >load differences on LDAP directories for the two types > > >of searches. Particularly if they also include the > > >size of the directory and the number of searches per > > >second. > > > > > > > > Nope I sure don't, but that still doesn't make it a good idea. In our > > setup at present, I'm pretty sure that our servers are way overmatched > > (too much horsepower) for what they are doing, and our DIT isn't > > anywhere big enough to cause painful searches. I can see where it would > > very easily get out of hand with a growing environment that is designed > > badly from the start and then you just can't find a way to migrate it > > back to sanity without major pain. Or a sloppy admin could put a uid in > > a bad location and really start to make things messy. For these reasons > > it is preferrable to do it right the first time, as painful as it may > > seem on the front end. > > > > I'm going to be testing (in the next couple days hopefully) a method of > > aliasing the People and Computers OUs into one to see if that works > > better than overly broadening the base search. Since we'll have a few > > things that check against the users tree, we don't like having the > > computer accounts in there either, but it would be easy enough to script > > out that if the last char is $ it should be excluded from any search. > > > > >Haven't done any hard performance testing myself, but we > > >have not noticed a marked performance difference between > > >the two configurations to date. We reasoned that this > > >change only needs to be done for unix servers running > > >samba, rather than all unix servers on the network. As a > > >result a small sub set of searches are larger, but the > > >majority of servers work with a reduced number of objects > > >in the People OU and we have negated the possibility of > > >those accounts being used for nefarious purposes on the > > >vast majority of our unix server that do not use samba > > >but do use NSS LDAP. > > > > > >cheers, > > >andrew > > > > > > > > > > -- > > Paul Gienger Office: 701-281-1884 > > Applied Engineering Inc. > > Information Systems Consultant Fax: 701-281-1322 > > URL: www.ae-solutions.com mailto: [EMAIL PROTECTED] > -- > Neil Marjoram. > Systems Manager > University College London > Adastral Park Campus > Martlesham Heath > Ipswich > Suffolk > IP5 3RL > > 01473 663711 -- Neil Marjoram. Systems Manager University College London Adastral Park Campus Martlesham Heath Ipswich Suffolk IP5 3RL 01473 663711 -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
