HOWTO add static entries to WINS?

Sat Mar 3 18:44:20 GMT 2001

> On Fri, Mar 02, 2001 at 11:59:44AM -0600, Christopher R. Hertel wrote:
> > If I understand this thread correctly, what you want to do is to 'lock' the
> > mapping between a set of names and a set of IPs so that only the given IP
> > can register and use the given name.
> 
> Well to be more specific on the motivation: There are several independent
> subnets spread across our university campus, which need access to one (and
> only one!) specific central Samba server (the university's central print
> server).
> 
> One way to deal with it seems to be the "remote announce" parameter. Other
> than us not being able to set this up properly (still under investigation),
> the preloading of our (local!) WINS server seems to be the cleanest
> solution.

Remote Announce is a Browsing feature.  If the print server's name is not
already in the NBNS (WINS) database then adding it to the browse list
won't really help. 

> Asking the central print server to register against our (local!) WINS is not
> an option as every other department would like them to register against their
> WINS, too. And we do not want to have a common WINS, as the departments have
> nothing in common other than that print server (just imagine physics and
> history departments ...).

I work at a University as well, so I understand that problem...

So... What you are suggesting in the above is that the central print
server be registered with multiple NBNS servers.  My first comment on 
that is that it breaks the model established by RFC1001/1002.  I think, 
though, that it is do-able without causing a lot of trouble.

There are two ways to go about it.  The first is to create a static entry
in *every* NBNS database on your campus.  That could be problematic since
the NBNS servers are all run by different departments.  The other way is 
to have the print server register itself with every NBNS on campus.  That 
means finding each NBNS and sending the registration request to each.

Creating a static entry on every NBNS would also require touching every
NBNS you have out there.  Even if we can adapt Samba to accept static
entries, you might still have problems with Microsoft's NBNS, aka. WINS. 
I don't think that static entry will help.

> So, to cut a long story short, reasons for having static WINS entries include:
> - Safety locks, as you mention

Yes, but once again *every* NBNS(WINS) server would have to have those 
static entries in order for this to work.

> - having a server appear on multiple WINS servers (like "remote announce" does
>   for broadcasts)

Remote announce does this for browsing, not "broadcasts" per. se.  I think
what you are looking for would be multi-NBNS registration.  Unfortunately,
multi-NBNS registration breaks the NBT namespace management model very badly.

> - having the decision on the WINS server side than on the announcing client
>   side (which might also be considered as a disadvantage)
> 
> > This might be done by pre-loading the WINS database with those mappings, as
> > you are doing, assuming that all clients are in either P or H mode (both of
> > which rely on the NBNS server to resolve names).
> 
> Sorry to be ignorant, I am not that familiar with NetBIOS jargon -- what are P
> and H modes?

Knowing how NBT works is key to understanding how to accomplish what you 
want to accomplish.  If you have time, see: http://www.ubiqx.org/cifs/
and read the NetBIOS over TCP/IP section.

Basically, though, there are four modes:

B - NetBIOS names are announced and discovered by sending broadcast messages
    over the local IP subnet.  This is a LAN-only mechanism.
P - Point-to-point mode.  Names are registered with an NBNS (WINS) server.
    Queries are also sent to the NBNS, which is *the* authority for 
    Name-to-IP mappings.
M - Mixed mode.  Names are registered via both B and P modes.  Queries 
    are done by first broadcasting and, if that fails, querying the NBNS.
H - Microsoft defined.  It is the same as M mode, only backward.

> And concerning the patch which includes lmhosts as static WINS entries: I will
> check the expiry codes, but what about workgroup mapping? As I wrote I managed
> to register that print server on our WINS, and addressing it explicitely seems
> to do the job (expiry to be checked), but it does not appear on browse list
> probably because I didn't manage to tell the lmhost/WINS about it.

The browsing service is a separate service.  It uses the name service, so
the name must be registered, but you still have to announce services to
the Master Browser if you want to see them in the browse list. 

Here is my best guess on how to approach this problem:

1) make sure that the printer name is in the DNS.  Many Microsoft 
   implementations will try DNS name resolution if NetBIOS name 
   resolution fails.  This is extremely ugly, but they do it and you can
   make use of it in this case.  Problem is, it does not prevent anyone
   from claiming the NetBIOS name for themselves.

2) Use Remote Announce to make sure that the service is seen in the 
   browse lists.  Note that the NBNS servers (Windows WINS or Samba nmbd)
   will need to use DNS lookup themselves or the names in the browse 
   lists will be meaningless.  I have no idea what the Master Browser will
   do if it gets a name that it cannot resolve.

> My try for
> creating a static entry for a server called print_zedat in the
> workgroup/domain physik was
> 
> 160.45.10.18    print_zedat#00
> 160.45.10.18    print_zedat#03
> 160.45.10.18    print_zedat#20
> 160.45.10.18    physik#00
> 
> which does not give the expected result :(

Really sorry, but to get this all to work you will first need to
understand how NBT and Browsing work. The URL listed above should
(hopefully) provide some information about the workings of NetBIOS.
I also recommend: 

  http://www.microsoft.com/TechNet/win95/technote/w95brows.asp

for information about how browsing works.

Good luck.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services

    Ideals are like stars; you will not succeed in touching them
    with your hands...you choose them as your guides, and following
    them you will reach your destiny.  --Carl Schultz