SAMLOGON UDP request

[Luke Kenneth Casson Leighton]

On Wed, 16 Dec 1998, Andrew Tridgell wrote:

> > andrew, jeremy, remember that i can never or at least rarely come up with
> > immediate reasons (within two days) it usually takes me two to three
> > weeks.  i still may know why something may not be a good idea, i just
> > can't justify it, the design is still partially subconscious.
> 
> I'd rather it become fully concious before you commit it! Then the
> commits might make more sense :)

true.  done.
 
> > that code is a subset of what is required.
> 
> no, it was just totally broken. It had no redeeming features at all.
> When adding code to Samba you should _not_ break existing setups
> except in extreme cases. This code broke lots of existing setups and
> didn't even work. 

i presume that you  
> > don't worry: NT registers FORIEGN_DOMAIN<00> and on this name it answers
> > *all* requests that are sent to FORIEGN_DOMAIN<00>.
> 
> 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)

> > therefore we don't need to "reply inappropriately", we actually need to go
> > carefully through all the other datagram code to make sure that we _do_
> > reply appropriately.
> 
> you misunderstand me. If we register the names locally then we will
> reply to all requests. The problem is that we will give the _wrong_
> reply in some cases. In several places we reply with our server name,
> but we wuld instead have to reply with the name of a different server.

it may not turn out to be as bad as all that... ah, just having a look at
the code: there is no identification or refusal of certain types of
datagram packets that will be expected from or to certain netbios names,
damn.

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

i think we may find that this will occur with other requests, too (except
that we can't check it from code alone).  and it's irrelevant because the
"automatic" system of nt 4.0, using inter-domain trust, uses another
mechanism.  it is i suspect that nt 3.1 and 3.5 use inter-domain trust to
register FORIEGN_DOMAIN<00> hence the notes inthe cifs documentatio about
it being possible to receive queries on DOMAIN<00> as well as <1c> and
<1b>.

 
> I'd also query if this is necessary at all. If clients fallback to
> doing WINS queries for these requests then it will work with the
> current code. If we can get away without putting trust relationship
> code in nmbd then we should do so. Our aim is not to totally emulate
> NT. Our aim is to provide useful services to users.

good point: what are the priorities and what gives maximum benefit, we
can't do everything.