multiple nmbds domains workgroups

[Luke Kenneth Casson Leighton]

> > IIRC from talks with Andrew, there are some protocol limitation
> > to implementing this.  I'll let him or Chris (or Jeremy)
> > comment on this specifics as they are escaping my mind right now.
 
you could ask me, i would have provided you with an answer
just as well.

> yes, there are protocol limitations. The problem is that there are
> parts of the protocol where the client asks a question that has a
> workgroup specific answer but the client gives no indication as to
> what workgroup they are interested in. The NetServerEnum RAP call
> comes to mind. In that call client may choose whether to supply a
> workgroup, and if it isn't supplied then the server is supposed to use
> its workgroup. So which workgroup would you use?

the solution is to use the called netbios name to be associated
with the workgroup.

when you have a one-to-one mapping between netbios names
and workgroups the problem you outline as a protocol
limitation goes away.

> That's why when Luke implemented multiple workgroup support in Samba
> several years ago we didn't integrate it - we didn't have a solution
> to this problem and the consequences were that machines leaked between
> workgroups (so you could eventually end up with all machines showing
> up in all workgroups). This happens because NetServerEnum is used for
> browse synchronisation within workgroups.
 
that problem was solved as part of the multiple workgroup
solution.

as were several others [e.g. it had a more advanced version
of chris' hierarchical WINS server mechanism

> I don't think this is the only part of the protocol where you have
> this type of problem. It's pretty much an inevitable result of having
> a complex protocol combined with Microsoft not implementing
> multiple-workgroup support. 

one computer, one user...

... actually, the people who did NT 3.1 - of whom there were
only seven people, initially [took them 4.5 years to write
NT 3.1] - did an extremely good, well-thought-out job.

for example, the SAMR pipe implementation allows enumeration
of multiple Domain databases - but only two are provided (WORKGROUPNAME
and the hard-coded, ever-present BUILTIN domain)

where it all started to go horribly wrong is attempts to maintain
backwards-compatibility with Windows 3.1, then '95, hence
horrible things like spoolss and winreg.


> Programmers get lazy and don't bother
> adding a workgroup field to a call then you are stuck with that
> decison.
 
by having a server - like VisionFS's SMB server - register
itself under several (unlimited number of, i believe) different
NetBIOS names, in fact there is an option to allow it to create
them dynamically! [servername001, servername002 etc] - all of
those problems go away, in a NetBIOS environment.

this is why i was so annoyed with microsoft when they came
up with CIFS/TCP because they failed to provide the equivalent
of the NetBIOS called name.  oh, and adding *SMBSERVER, too.

under these circumstances, andrew's comments are correct
[but there are still "legacy" workarounds that can be actioned.]
paul described that the solution was to register on multiple
ip addresses, instead, and thence the solution becomes
to use "socket address" etc. like wot has been done
several times, already, see samba archives from at least
two years back, someone posted multiple example smb.confs.

of course, microsoft, having a dynamic dns + dhcp communication
came across the embarrasing situation where a server would
go down, get a different dhcp ip address on its way up and
clients would use the cached ip address... [they should have
damn well listened in the first place].

now, they _may_ have solved this one by adding the hostname
(equivalent to calling and called) into the CAP_EXTENDED_SECURITY
blobs, since, but i don't know for sure, but it would be
stupid of them not to have, for quite obvious security,
data corruption and integrity reasons [e.g. crash a host,
take over its dhcp ip address and do pass-through 
to receive all further SMB requests]

summary: the multiworkgroup code was perfectly capable of 
providing domain /browser management under multiple netbios
names and therefore managing multiple domains.

microsoft screwed this up with cifs/tcp [which fortunately is
optional] but since may have fixed it, and they screwed it up
in a way that _doesn't_
affect NBT, but you *DO* have to deny any connections to
*SMBSERVER, if you want a single nmbd/smbd daemon to be
able to do multiple workgroups/domains.

luke

it also may be worthwhile investigating NT5's domain /
browse management to see if ms learned their lesson yet.