libsmbclient: Browsing and a URI spec?

Kevin Colby kevinc at grainsystems.com
Fri Jan 5 00:27:39 GMT 2001


"Christopher R. Hertel" wrote:
> 
> Mike's scenario is this:  In a large company, there are many NT Domains.
> Users configure their workstations to be associated with the local NT
> Domain.  However, there is one single authentication domain.  All users
> must login against the auth database in the central domain.  The central
> domain then provides trust relationships so that the servers in the
> user's domain can 'trust' the user's credentials.

Okay.

> My thinking is this.  The WORKGROUP parameter provides both the browsing
> domain (which many also call a workgroup) and the authentication domain.
> The default on almost all systems is that these are the same.
> 
> If you are in the somewhat odd situation that you must authenticate to a
> different NT domain, then you override the WORKGROUP parameter for
> *authentication only* by using the AUTH DOMAIN parameter.

This is fine.  I also agree that smbc.conf or something like it would
be useful, so long as smb.conf is also read.

What I'm still not sure of is, if in the above example, the machine in
question runs a Samba server in addition to being a client, when setting
up the server's smb.conf, would you specify that the server's "workgroup"
for the purposes of domain membership be the local domain or the central
domain?  In an smbc.conf, these parameters could both be there and be
named anything, but if you are inheriting smb.conf parameters, it would
not be wise to change their meaning from smb.conf to smbc.conf.  So, if
the server were joining the local domain, the parameters "workgroup" and
"auth domain" might make sense, but if the server joins the central
domain, better would be "workgroup" and "browse".  The definition of
"workgroup" in an smbc.conf should mirror its meaning when inherited
from smb.conf.

That's all.  Sorry if I've made a big deal about nothing.

	- Kevin Colby
	  kevinc at grainsystems.com




More information about the samba-technical mailing list