[Samba] Winxp / LDAP No account in domain

[Neil Marjoram]

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: pgienger at ae-solutions.com
> -- 
> 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