SAMLOGON UDP request

[Luke Kenneth Casson Leighton]

> > 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.

... or to answer the getbackuplistreq with not with our own lmb or dmb
name but with the trusted dc's lmb or dmb names.
 
> 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.

very true, this whole situation, as far back as the SAMQUERY, is to help
B-node clients, that's why they sent a broadcast mailslot query to
FORIEGN_DOMAIN<00> in the first place.

[hack, hack]
 
> > 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?

i think that this is solved by avoiding the issue by answering the
getbackuplistreq with the foriegn domains' lmbs and its dmb.  if we know
who they are.

> 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.

ah, but with that the problem was solved by cross-referencing the called
netbios name against the workgroup for which that netbios name was
responsible.

> 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

tell that to the AS/400 development team.

> inter-domain trust into the mix with the possibility of becoming the
> LMB for a foreign domain is just asking for trouble.

very much agreed, solution to this, should we adopt it, is mentioned
twice.