Andrew Tridgell tridge at
Thu Dec 17 01:25:54 GMT 1998

> > ok, so if you do "nmblookup -S" on a NT box with a trust relationship
> > then it shows registered domain names for the other domains? (not just
> > subconcious feelings here, have you actually seen this?)
> double-checking this, no it doesn't.  setting up a manual browser link
> (Start | Settings | Control Panel | Network | Setvices | Computer Browser
> | Properties | Add - use this screen to add and remove other domains that
> wil be made available to the Browser service)

interesting! This means the foreign domain isn't totally equivalent
(netbios-wise) to the primary domain. This smells of a nasty hack.

> ok, from memory two or so years ago, , get backuplist is one that wil come
> in on DOMAIN<00> and therefore will come in on FORIEGN_DOMAIN<00>, yes?

but we'll only get a "get backup list" (which is unicast, from memory)
if we answer a broadcast 1D query for that domain or register it with
WINS. Either way, we would need to be the LMB for that domain.

Also, in a WINS environment it will never be necessary as the client
will always be able to find a registered MB for the domain. It's only
B-node clients that might need help.

> if we answer on this one with the name of our server, it makes no
> difference: we will receive a NetServerEnum2 call and we will respond with
>  non-authoritative browser list.

and if they send us a NetServerEnum without a domain part in the
query? Older clients do this. We can't just ignore the request but
what do we answer? This is the same problem we hit with your (rather
imaginative!) multi-workgroup support code.

Basically I think that this whole thing opens up a large can of
worms. Requiring that people wanting cross-subnet inter-domain trust
relationships use WINS is a much simpler (and certainly more robust)
solution. Cross subnet browsing is dodgy at best without WINS. Adding
inter-domain trust into the mix with the possibility of becoming the
LMB for a foreign domain is just asking for trouble.

More information about the samba-technical mailing list