Multiple WINS Servers Enhancement

[Elrond]

On Fri, Jul 07, 2000 at 08:56:30AM +1000, Christopher R. Hertel wrote:
> On Jul 7,  7:46am, Chris Young wrote:
[...]
> 
> Going back to my original anal retentiveness, I'm questioning the use of the
> term "necessary".  In addition to WINS there is local broadcast and the LMHosts
> file.  Granted, neither of these does the full job.  I'm simply stating that
> the system can work without WINS.  ...it's just not pretty...

Just an interesting example:

network a: domain ntdom
	nt server (ntpdc)
		pdc of ntdom
		uses central wins
	nt workstation (ntwks1)
		member of ntdom
		uses wins
	nt workstation (ntwks2)
		member of ntdom
		doesn't use wins
	nt terminal server (ntts)
		member of ntdom
		doesn't use wins
network b: domain sambadom
	tng samber server (sambapdc)
		uses wins

These networks are connected via routed IP.

ntpdc trusts sambapdc.

Now the interesting facts:

ntpdc	shows sambadom on Logon-screen	uses wins
ntwks1	shows sambadom on Logon-screen	uses wins
ntwks2	shows sambadom on Logon-screen  doesn't use wins
ntts	doesn't show sambadom		doesn't use wins

I could even login directly at ntwks1 as sambadom\user, so
the trust seems to work.

I've even tried to add entries for sambadom and sambapdc to
lmhosts on ntts, but that didn't seem to help.

I didn't yet get to set a wins server and reboot ntts, so I
don't know, wether that would help.


[...]
> > Well, look like some other must agree with me that at least having this
> option
> > is a good idea (since it is in HEAD).  We're all not going to agree on these
> > issues, so if you don't like it, don't use it.  That's why they are called
> > 'options'. :)
> 
> It works for small, overlapping name spaces but it failes to scale and it has
> security implications.  To use it, the admin needs to have a keen understanding
> of both the DNS and the workings of NBT.
> 
> Example:  You have two DNS domains:  gruntwork.corporate.com and
> slavepit.corporate.com.  You might want machines in these two domains to be
> able to share files via CIFS.  Take two machines, one in each subdomain.  Call
> them A and B for lack of creativity.
> 
> These register in WINS as 'A' and 'B'.  Their DNS names are
> a.gruntwork.corporate.com and b.slavepit.corporate.com... except that they're
> also in WINS.  What's the DNS domain for the WINS server?  How will a lookup
> interpret this?  If names listed in the WINS server are assigned to slavepit,
> the machine A has two conflicting DNS names.  This will cause trouble with
> reverse map lookups, which are sometimes used to verify connection
> authenticity.

I think, you mix up nss and dns a little.

nss is just the local service on some unix boxes, that
allows you to modify the way, name-services are used.
DNS is just one naming-service, that _can_ be used by nss.

A proper way to use the module would be for example to
first search /etc/hosts, then DNS, then WINS.

This will just allow for nice things, like
"ping netbiosname".

About conflicts: I don't know, if the nss-module in head
allows you to do reverse-lookups, and if it does so, I
don't know, which DNS-domain it appends, but I would guess,
it doesn't append one.

But on the other side, conflicts are handled in nss by
order. If you have /etc/hosts before DNS, you can have
conflicting entries in /etc/hosts, they just take
precedence over DNS. and if you have WINS last, everything
else has precedence, but you get a nice fallback.

Well, and a good sysadmin should know, that name based
authentication isn't realy secure.

> If the WINS database can be entirely contained within a DNS domain, and can be
> managed as authoritative for that domain (that is, name conflicts between DNS
> entries and WINS entries can be resolved per stated policy) then this can be
> made to work.  The better solution is to use DynamicDNS (*with* DNSSec) to
> correctly register the names in the DNS.

As I already stated, the above stuff doesn't have to do
anything with DNS. You can even use it without any
DNS-server (for example: small company, they just use
/etc/hosts and nss_wins and don't need _any_ DNS)

> The other problem, of course, is that it's easy to pollute a WINS database with
> unauthorized entries.  I've seen this in the wild.  The cool thing is that you
> can spoof the source address on the IP packets and, since you've got a trojan
> in the WINS database, NetBIOS replies still go where you want them to go.  Neat
> trick.
[...]

Can you elaborate on that?
I can only see this working with UDP, because otherwise the
TCP-reply is made by IP and not by name...

Okay... You can combine this with sequence-number guessing,
but I don't remember any core-NT-services, that do
authentication by name.

Hmm... You can use the ip-spoofing to unregister the name
"in the name of" the original owner and then register your
own machine with the name, if you then find a
name-authenticated service, you got it. 

But all the same goes for DNS, it's just a little harder.


    Elrond