[Samba] Winxp / LDAP No account in domain

Neil Marjoram n.marjoram at adastral.ucl.ac.uk
Tue Aug 17 09:48:35 GMT 2004


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



More information about the samba mailing list