mirror of
https://github.com/samba-team/samba.git
synced 2024-12-23 17:34:34 +03:00
992f1e6b8f
add the 5 missing chapters from the HOWTO
and add jht's Samba by Example book.
(This used to be commit 9fb5bcb93e
)
714 lines
26 KiB
XML
714 lines
26 KiB
XML
<chapter id="integrate-ms-networks">
|
|
|
|
<chapterinfo>
|
|
&author.jht;
|
|
<pubdate> (Jan 01 2001) </pubdate>
|
|
</chapterinfo>
|
|
|
|
<title>Integrating MS Windows Networks with Samba</title>
|
|
|
|
<para>
|
|
<indexterm><primary>NetBIOS</primary></indexterm>
|
|
This section deals with NetBIOS over TCP/IP name to IP address resolution. If
|
|
your MS Windows clients are not configured to use NetBIOS over TCP/IP, then this
|
|
section does not apply to your installation. If your installation
|
|
involves the use of
|
|
NetBIOS over TCP/IP then this section may help you to resolve networking problems.
|
|
</para>
|
|
|
|
<note>
|
|
<para>
|
|
NetBIOS over TCP/IP has nothing to do with NetBEUI. NetBEUI is NetBIOS
|
|
over Logical Link Control (LLC). On modern networks it is highly advised
|
|
to not run NetBEUI at all. Note also there is no such thing as
|
|
NetBEUI over TCP/IP &smbmdash; the existence of such a protocol is a complete
|
|
and utter misapprehension.
|
|
</para>
|
|
</note>
|
|
|
|
<sect1>
|
|
<title>Features and Benefits</title>
|
|
|
|
<para>
|
|
Many MS Windows network administrators have never been exposed to basic TCP/IP
|
|
networking as it is implemented in a UNIX/Linux operating system. Likewise, many UNIX and
|
|
Linux administrators have not been exposed to the intricacies of MS Windows TCP/IP-based
|
|
networking (and may have no desire to be either).
|
|
</para>
|
|
|
|
<para>
|
|
This chapter gives a short introduction to the basics of how a name can be resolved to
|
|
its IP address for each operating system environment.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Background Information</title>
|
|
|
|
<para>
|
|
Since the introduction of MS Windows 2000, it is possible to run MS Windows networking
|
|
without the use of NetBIOS over TCP/IP. NetBIOS over TCP/IP uses UDP port 137 for NetBIOS
|
|
name resolution and uses TCP port 139 for NetBIOS session services. When NetBIOS over
|
|
TCP/IP is disabled on MS Windows 2000 and later clients, then only the TCP port 445 will be
|
|
used and the UDP port 137 and TCP port 139 will not.
|
|
</para>
|
|
|
|
<note>
|
|
<para>
|
|
When using Windows 2000 or later clients, if NetBIOS over TCP/IP is not disabled, then
|
|
the client will use UDP port 137 (NetBIOS Name Service, also known as the Windows Internet
|
|
Name Service or WINS), TCP port 139 and TCP port 445 (for actual file and print traffic).
|
|
</para>
|
|
</note>
|
|
|
|
<para>
|
|
When NetBIOS over TCP/IP is disabled, the use of DNS is essential. Most installations that
|
|
disable NetBIOS over TCP/IP today use MS Active Directory Service (ADS). ADS requires
|
|
<indexterm><primary>DNS</primary><secondary>Dynamic</secondary></indexterm>
|
|
Dynamic DNS with Service Resource Records (SRV RR) and with Incremental Zone Transfers (IXFR).
|
|
<indexterm><primary>DHCP</primary></indexterm>
|
|
Use of DHCP with ADS is recommended as a further means of maintaining central control
|
|
over the client workstation network configuration.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Name Resolution in a Pure UNIX/Linux World</title>
|
|
|
|
<para>
|
|
The key configuration files covered in this section are:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><filename>/etc/hosts</filename></para></listitem>
|
|
<listitem><para><filename>/etc/resolv.conf</filename></para></listitem>
|
|
<listitem><para><filename>/etc/host.conf</filename></para></listitem>
|
|
<listitem><para><filename>/etc/nsswitch.conf</filename></para></listitem>
|
|
</itemizedlist>
|
|
|
|
<sect2>
|
|
<title><filename>/etc/hosts</filename></title>
|
|
|
|
<para>
|
|
This file contains a static list of IP addresses and names.
|
|
</para>
|
|
<para><programlisting>
|
|
127.0.0.1 localhost localhost.localdomain
|
|
192.168.1.1 bigbox.quenya.org bigbox alias4box
|
|
</programlisting></para>
|
|
|
|
<para>
|
|
The purpose of <filename>/etc/hosts</filename> is to provide a
|
|
name resolution mechanism so users do not need to remember
|
|
IP addresses.
|
|
</para>
|
|
|
|
<para>
|
|
Network packets that are sent over the physical network transport
|
|
layer communicate not via IP addresses but rather using the Media
|
|
Access Control address, or MAC address. IP addresses are currently
|
|
32 bits in length and are typically presented as four (4) decimal
|
|
numbers that are separated by a dot (or period). For example, 168.192.1.1.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>MAC Addresses</primary></indexterm>
|
|
MAC Addresses use 48 bits (or 6 bytes) and are typically represented
|
|
as two-digit hexadecimal numbers separated by colons: 40:8e:0a:12:34:56.
|
|
</para>
|
|
|
|
<para>
|
|
Every network interface must have a MAC address. Associated with
|
|
a MAC address may be one or more IP addresses. There is no
|
|
relationship between an IP address and a MAC address; all such assignments
|
|
are arbitrary or discretionary in nature. At the most basic level, all
|
|
network communications take place using MAC addressing. Since MAC
|
|
addresses must be globally unique and generally remain fixed for
|
|
any particular interface, the assignment of an IP address makes sense
|
|
from a network management perspective. More than one IP address can
|
|
be assigned per MAC address. One address must be the primary IP
|
|
address &smbmdash;
|
|
this is the address that will be returned in the ARP reply.
|
|
</para>
|
|
|
|
<para>
|
|
When a user or a process wants to communicate with another machine,
|
|
the protocol implementation ensures that the <quote>machine name</quote> or <quote>host
|
|
name</quote> is resolved to an IP address in a manner that is controlled
|
|
by the TCP/IP configuration control files. The file
|
|
<filename>/etc/hosts</filename> is one such file.
|
|
</para>
|
|
|
|
<para>
|
|
When the IP address of the destination interface has been
|
|
determined, a protocol called ARP/RARP is used to identify
|
|
the MAC address of the target interface. ARP stands for Address
|
|
Resolution Protocol and is a broadcast-oriented method that
|
|
uses User Datagram Protocol (UDP) to send a request to all
|
|
interfaces on the local network segment using the all 1s MAC
|
|
address. Network interfaces are programmed to respond to two
|
|
MAC addresses only; their own unique address and the address
|
|
ff:ff:ff:ff:ff:ff. The reply packet from an ARP request will
|
|
contain the MAC address and the primary IP address for each
|
|
interface.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>/etc/hosts</primary></indexterm>
|
|
The <filename>/etc/hosts</filename> file is foundational to all
|
|
UNIX/Linux TCP/IP installations and as a minimum will contain
|
|
the localhost and local network interface IP addresses and the
|
|
primary names by which they are known within the local machine.
|
|
This file helps to prime the pump so a basic level of name
|
|
resolution can exist before any other method of name resolution
|
|
becomes available.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
<sect2>
|
|
<title><filename>/etc/resolv.conf</filename></title>
|
|
|
|
<para>
|
|
This file tells the name resolution libraries:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>The name of the domain to which the machine
|
|
belongs.
|
|
</para></listitem>
|
|
|
|
<listitem><para>The name(s) of any domains that should be
|
|
automatically searched when trying to resolve unqualified
|
|
host names to their IP address.
|
|
</para></listitem>
|
|
|
|
<listitem><para>The name or IP address of available Domain
|
|
Name Servers that may be asked to perform name-to-address
|
|
translation lookups.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
|
|
</sect2>
|
|
|
|
|
|
<sect2>
|
|
<title><filename>/etc/host.conf</filename></title>
|
|
|
|
|
|
<para>
|
|
<indexterm><primary>/etc/host.conf</primary></indexterm>
|
|
<filename>/etc/host.conf</filename> is the primary means by
|
|
which the setting in <filename>/etc/resolv.conf</filename> may be effected. It is a
|
|
critical configuration file. This file controls the order by
|
|
which name resolution may proceed. The typical structure is:
|
|
</para>
|
|
|
|
<para><programlisting>
|
|
order hosts,bind
|
|
multi on
|
|
</programlisting></para>
|
|
|
|
<para>
|
|
then both addresses should be returned. Please refer to the
|
|
man page for <filename>host.conf</filename> for further details.
|
|
</para>
|
|
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2>
|
|
<title><filename>/etc/nsswitch.conf</filename></title>
|
|
|
|
|
|
<para>
|
|
<indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
|
|
This file controls the actual name resolution targets. The
|
|
file typically has resolver object specifications as follows:
|
|
</para>
|
|
|
|
|
|
<para><programlisting>
|
|
# /etc/nsswitch.conf
|
|
#
|
|
# Name Service Switch configuration file.
|
|
#
|
|
|
|
passwd: compat
|
|
# Alternative entries for password authentication are:
|
|
# passwd: compat files nis ldap winbind
|
|
shadow: compat
|
|
group: compat
|
|
|
|
hosts: files nis dns
|
|
# Alternative entries for host name resolution are:
|
|
# hosts: files dns nis nis+ hesiod db compat ldap wins
|
|
networks: nis files dns
|
|
|
|
ethers: nis files
|
|
protocols: nis files
|
|
rpc: nis files
|
|
services: nis files
|
|
</programlisting></para>
|
|
|
|
<para>
|
|
Of course, each of these mechanisms requires that the appropriate
|
|
facilities and/or services are correctly configured.
|
|
</para>
|
|
|
|
<para>
|
|
It should be noted that unless a network request/message must be
|
|
sent, TCP/IP networks are silent. All TCP/IP communications assume a
|
|
principal of speaking only when necessary.
|
|
</para>
|
|
|
|
|
|
<para>
|
|
<indexterm><primary>libnss_wins.so</primary></indexterm>
|
|
Starting with version 2.2.0, Samba has Linux support for extensions to
|
|
the name service switch infrastructure so Linux clients will
|
|
be able to obtain resolution of MS Windows NetBIOS names to IP
|
|
Addresses. To gain this functionality, Samba needs to be compiled
|
|
with appropriate arguments to the make command (i.e., <userinput>make
|
|
nsswitch/libnss_wins.so</userinput>). The resulting library should
|
|
then be installed in the <filename>/lib</filename> directory and
|
|
the <parameter>wins</parameter> parameter needs to be added to the <quote>hosts:</quote> line in
|
|
the <filename>/etc/nsswitch.conf</filename> file. At this point, it
|
|
will be possible to ping any MS Windows machine by its NetBIOS
|
|
machine name, as long as that machine is within the workgroup to
|
|
which both the Samba machine and the MS Windows machine belong.
|
|
</para>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
|
|
<sect1>
|
|
<title>Name Resolution as Used within MS Windows Networking</title>
|
|
|
|
<para>
|
|
MS Windows networking is predicated about the name each machine
|
|
is given. This name is known variously (and inconsistently) as
|
|
the <quote>computer name,</quote> <quote>machine name,</quote> <quote>networking name,</quote> <quote>netbios name,</quote>
|
|
or <quote>SMB name.</quote> All terms mean the same thing with the exception of
|
|
<quote>netbios name</quote> that can also apply to the name of the workgroup or the
|
|
domain name. The terms <quote>workgroup</quote> and <quote>domain</quote> are really just a
|
|
simple name with which the machine is associated. All NetBIOS names
|
|
are exactly 16 characters in length. The 16<superscript>th</superscript> character is reserved.
|
|
It is used to store a one-byte value that indicates service level
|
|
information for the NetBIOS name that is registered. A NetBIOS machine
|
|
name is, therefore, registered for each service type that is provided by
|
|
the client/server.
|
|
</para>
|
|
|
|
<para>
|
|
<link linkend="uniqnetbiosnames">Unique NetBIOS Names</link> and <link linkend="netbiosnamesgrp">Group Names</link> tables
|
|
list typical NetBIOS name/service type registrations.
|
|
</para>
|
|
|
|
<table frame="all" id="uniqnetbiosnames">
|
|
<title>Unique NetBIOS Names</title>
|
|
<tgroup cols="2">
|
|
<colspec align="left"/>
|
|
<colspec align="justify"/>
|
|
<tbody>
|
|
<row><entry>MACHINENAME<00></entry><entry>Server Service is running on MACHINENAME</entry></row>
|
|
<row><entry>MACHINENAME<03></entry><entry>Generic Machine Name (NetBIOS name)</entry></row>
|
|
<row><entry>MACHINENAME<20></entry><entry>LanMan Server service is running on MACHINENAME</entry></row>
|
|
<row><entry>WORKGROUP<1b></entry><entry>Domain Master Browser</entry></row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<table frame="all" id="netbiosnamesgrp">
|
|
<title>Group Names</title>
|
|
<tgroup cols="2">
|
|
<colspec align="left"/>
|
|
<colspec align="justify"/>
|
|
<tbody>
|
|
<row><entry>WORKGROUP<03></entry><entry>Generic Name registered by all members of WORKGROUP</entry></row>
|
|
<row><entry>WORKGROUP<1c></entry><entry>Domain Controllers / Netlogon Servers</entry></row>
|
|
<row><entry>WORKGROUP<1d></entry><entry>Local Master Browsers</entry></row>
|
|
<row><entry>WORKGROUP<1e></entry><entry>Browser Election Service</entry></row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>
|
|
<indexterm><primary>NetBIOS</primary></indexterm>
|
|
It should be noted that all NetBIOS machines register their own
|
|
names as per the above. This is in vast contrast to TCP/IP
|
|
installations where traditionally the system administrator will
|
|
determine in the <filename>/etc/hosts</filename> or in the DNS database what names
|
|
are associated with each IP address.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>NetBIOS</primary></indexterm>
|
|
One further point of clarification should be noted. The <filename>/etc/hosts</filename>
|
|
file and the DNS records do not provide the NetBIOS name type information
|
|
that MS Windows clients depend on to locate the type of service that may
|
|
be needed. An example of this is what happens when an MS Windows client
|
|
wants to locate a domain logon server. It finds this service and the IP
|
|
address of a server that provides it by performing a lookup (via a
|
|
NetBIOS broadcast) for enumeration of all machines that have
|
|
registered the name type *<1c>. A logon request is then sent to each
|
|
IP address that is returned in the enumerated list of IP addresses.
|
|
Whichever machine first replies, it then ends up providing the logon services.
|
|
</para>
|
|
|
|
<para>
|
|
The name <quote>workgroup</quote> or <quote>domain</quote> really can be confusing since these
|
|
have the added significance of indicating what is the security
|
|
architecture of the MS Windows network. The term <quote>workgroup</quote> indicates
|
|
that the primary nature of the network environment is that of a
|
|
peer-to-peer design. In a WORKGROUP, all machines are responsible for
|
|
their own security, and generally such security is limited to the use of
|
|
just a password (known as Share Level security). In most situations
|
|
with peer-to-peer networking, the users who control their own machines
|
|
will simply opt to have no security at all. It is possible to have
|
|
User Level Security in a WORKGROUP environment, thus requiring the use
|
|
of a user name and a matching password.
|
|
</para>
|
|
|
|
<para>
|
|
MS Windows networking is thus predetermined to use machine names
|
|
for all local and remote machine message passing. The protocol used is
|
|
called Server Message Block (SMB) and this is implemented using
|
|
the NetBIOS protocol (Network Basic Input Output System). NetBIOS can
|
|
be encapsulated using LLC (Logical Link Control) protocol &smbmdash; in which case
|
|
the resulting protocol is called NetBEUI (Network Basic Extended User
|
|
Interface). NetBIOS can also be run over IPX (Inter-networking Packet
|
|
Exchange) protocol as used by Novell NetWare, and it can be run
|
|
over TCP/IP protocols &smbmdash; in which case the resulting protocol is called
|
|
NBT or NetBT, the NetBIOS over TCP/IP.
|
|
</para>
|
|
|
|
<para>
|
|
MS Windows machines use a complex array of name resolution mechanisms.
|
|
Since we are primarily concerned with TCP/IP, this demonstration is
|
|
limited to this area.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>The NetBIOS Name Cache</title>
|
|
|
|
<para>
|
|
All MS Windows machines employ an in-memory buffer in which is
|
|
stored the NetBIOS names and IP addresses for all external
|
|
machines that machine has communicated with over the
|
|
past 10-15 minutes. It is more efficient to obtain an IP address
|
|
for a machine from the local cache than it is to go through all the
|
|
configured name resolution mechanisms.
|
|
</para>
|
|
|
|
<para>
|
|
If a machine whose name is in the local name cache has been shut
|
|
down before the name had been expired and flushed from the cache, then
|
|
an attempt to exchange a message with that machine will be subject
|
|
to time-out delays. Its name is in the cache, so a name resolution
|
|
lookup will succeed, but the machine cannot respond. This can be
|
|
frustrating for users but is a characteristic of the protocol.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>nbtstat</primary></indexterm>
|
|
<indexterm><primary>nmblookup</primary></indexterm>
|
|
The MS Windows utility that allows examination of the NetBIOS
|
|
name cache is called <quote>nbtstat</quote>. The Samba equivalent of this
|
|
is called <command>nmblookup</command>.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>The LMHOSTS File</title>
|
|
|
|
<para>
|
|
<indexterm><primary>LMHOSTS</primary></indexterm>
|
|
This file is usually located in MS Windows NT 4.0 or Windows 200x/XP in the directory
|
|
<filename>C:\WINNT\SYSTEM32\DRIVERS\ETC</filename> and contains the IP Address
|
|
and the machine name in matched pairs. The <filename>LMHOSTS</filename> file
|
|
performs NetBIOS name to IP address mapping.
|
|
</para>
|
|
|
|
<para>
|
|
It typically looks like this:
|
|
</para>
|
|
|
|
<para><programlisting>
|
|
# Copyright (c) 1998 Microsoft Corp.
|
|
#
|
|
# This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS
|
|
# over TCP/IP) stack for Windows98
|
|
#
|
|
# This file contains the mappings of IP addresses to NT computer names
|
|
# (NetBIOS) names. Each entry should be kept on an individual line.
|
|
# The IP address should be placed in the first column followed by the
|
|
# corresponding computer name. The address and the computer name
|
|
# should be separated by at least one space or tab. The "#" character
|
|
# is generally used to denote the start of a comment (see the exceptions
|
|
# below).
|
|
#
|
|
# This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
|
|
# files and offers the following extensions:
|
|
#
|
|
# #PRE
|
|
# #DOM:<domain>
|
|
# #INCLUDE <filename>
|
|
# #BEGIN_ALTERNATE
|
|
# #END_ALTERNATE
|
|
# \0xnn (non-printing character support)
|
|
#
|
|
# Following any entry in the file with the characters "#PRE" will cause
|
|
# the entry to be pre-loaded into the name cache. By default, entries are
|
|
# not pre-loaded, but are parsed only after dynamic name resolution fails.
|
|
#
|
|
# Following an entry with the "#DOM:<domain>" tag will associate the
|
|
# entry with the domain specified by <domain>. This effects how the
|
|
# browser and logon services behave in TCP/IP environments. To preload
|
|
# the host name associated with #DOM entry, it is necessary to also add a
|
|
# #PRE to the line. The <domain> is always pre-loaded although it will not
|
|
# be shown when the name cache is viewed.
|
|
#
|
|
# Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT)
|
|
# software to seek the specified <filename> and parse it as if it were
|
|
# local. <filename> is generally a UNC-based name, allowing a
|
|
# centralized lmhosts file to be maintained on a server.
|
|
# It is ALWAYS necessary to provide a mapping for the IP address of the
|
|
# server prior to the #INCLUDE. This mapping must use the #PRE directive.
|
|
# In addition the share "public" in the example below must be in the
|
|
# LanMan Server list of "NullSessionShares" in order for client machines to
|
|
# be able to read the lmhosts file successfully. This key is under
|
|
# \machine\system\currentcontrolset\services\lanmanserver\
|
|
# parameters\nullsessionshares
|
|
# in the registry. Simply add "public" to the list found there.
|
|
#
|
|
# The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
|
|
# statements to be grouped together. Any single successful include
|
|
# will cause the group to succeed.
|
|
#
|
|
# Finally, non-printing characters can be embedded in mappings by
|
|
# first surrounding the NetBIOS name in quotations, then using the
|
|
# \0xnn notation to specify a hex value for a non-printing character.
|
|
#
|
|
# The following example illustrates all of these extensions:
|
|
#
|
|
# 102.54.94.97 rhino #PRE #DOM:networking #net group's DC
|
|
# 102.54.94.102 "appname \0x14" #special app server
|
|
# 102.54.94.123 popular #PRE #source server
|
|
# 102.54.94.117 localsrv #PRE #needed for the include
|
|
#
|
|
# #BEGIN_ALTERNATE
|
|
# #INCLUDE \\localsrv\public\lmhosts
|
|
# #INCLUDE \\rhino\public\lmhosts
|
|
# #END_ALTERNATE
|
|
#
|
|
# In the above example, the "appname" server contains a special
|
|
# character in its name, the "popular" and "localsrv" server names are
|
|
# pre-loaded, and the "rhino" server name is specified so it can be used
|
|
# to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"
|
|
# system is unavailable.
|
|
#
|
|
# Note that the whole file is parsed including comments on each lookup,
|
|
# so keeping the number of comments to a minimum will improve performance.
|
|
# Therefore it is not advisable to simply add lmhosts file entries onto the
|
|
# end of this file.
|
|
</programlisting></para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>HOSTS File</title>
|
|
|
|
<para>
|
|
This file is usually located in MS Windows NT 4.0 or Windows 200x/XP in
|
|
the directory <filename>C:\WINNT\SYSTEM32\DRIVERS\ETC</filename> and contains
|
|
the IP Address and the IP hostname in matched pairs. It can be
|
|
used by the name resolution infrastructure in MS Windows, depending
|
|
on how the TCP/IP environment is configured. This file is in
|
|
every way the equivalent of the UNIX/Linux <filename>/etc/hosts</filename> file.
|
|
</para>
|
|
</sect2>
|
|
|
|
|
|
<sect2>
|
|
<title>DNS Lookup</title>
|
|
|
|
|
|
<para>
|
|
<indexterm><primary>DNS</primary></indexterm>
|
|
This capability is configured in the TCP/IP setup area in the network
|
|
configuration facility. If enabled, an elaborate name resolution sequence
|
|
is followed, the precise nature of which is dependant on how the NetBIOS
|
|
Node Type parameter is configured. A Node Type of 0 means that
|
|
NetBIOS broadcast (over UDP broadcast) is used if the name
|
|
that is the subject of a name lookup is not found in the NetBIOS name
|
|
cache. If that fails then DNS, HOSTS and LMHOSTS are checked. If set to
|
|
Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the
|
|
WINS Server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast
|
|
lookup is used.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>WINS Lookup</title>
|
|
|
|
|
|
<para>
|
|
<indexterm><primary>WINS</primary></indexterm>
|
|
A WINS (Windows Internet Name Server) service is the equivalent of the
|
|
rfc1001/1002 specified NBNS (NetBIOS Name Server). A WINS server stores
|
|
the names and IP addresses that are registered by a Windows client
|
|
if the TCP/IP setup has been given at least one WINS Server IP Address.
|
|
</para>
|
|
|
|
<para>
|
|
To configure Samba to be a WINS server, the following parameter needs
|
|
to be added to the &smb.conf; file:
|
|
</para>
|
|
|
|
<para><smbconfblock>
|
|
<smbconfoption><name>wins support</name><value>Yes</value></smbconfoption>
|
|
</smbconfblock></para>
|
|
|
|
<para>
|
|
To configure Samba to use a WINS server, the following parameters are
|
|
needed in the &smb.conf; file:
|
|
</para>
|
|
|
|
<para><smbconfblock>
|
|
<smbconfoption><name>wins support</name><value>No</value></smbconfoption>
|
|
<smbconfoption><name>wins server</name><value>xxx.xxx.xxx.xxx</value></smbconfoption>
|
|
</smbconfblock></para>
|
|
|
|
<para>
|
|
where <replaceable>xxx.xxx.xxx.xxx</replaceable> is the IP address
|
|
of the WINS server.
|
|
</para>
|
|
|
|
<para>For information about setting up Samba as a WINS server, read
|
|
<link linkend="NetworkBrowsing">Network Browsing</link>.</para>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Common Errors</title>
|
|
|
|
<para>
|
|
TCP/IP network configuration problems find every network administrator sooner or later.
|
|
The cause can be anything from keyboard mishaps, forgetfulness, simple mistakes, and
|
|
carelessness. Of course, no one is ever deliberately careless!
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Pinging Works Only in One Way</title>
|
|
|
|
<para>
|
|
<quote>I can ping my Samba server from Windows, but I cannot ping my Windows
|
|
machine from the Samba server.</quote>
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis>Answer:</emphasis> The Windows machine was at IP Address 192.168.1.2 with netmask 255.255.255.0, the
|
|
Samba server (Linux) was at IP Address 192.168.1.130 with netmask 255.255.255.128.
|
|
The machines were on a local network with no external connections.
|
|
</para>
|
|
|
|
<para>
|
|
Due to inconsistent netmasks, the Windows machine was on network 192.168.1.0/24, while
|
|
the Samba server was on network 192.168.1.128/25 &smbmdash; logically a different network.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Very Slow Network Connections</title>
|
|
|
|
<para>
|
|
A common cause of slow network response includes:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Client is configured to use DNS and the DNS server is down.</para></listitem>
|
|
<listitem><para>Client is configured to use remote DNS server, but the
|
|
remote connection is down.</para></listitem>
|
|
<listitem><para>Client is configured to use a WINS server, but there is no WINS server.</para></listitem>
|
|
<listitem><para>Client is not configured to use a WINS server, but there is a WINS server.</para></listitem>
|
|
<listitem><para>Firewall is filtering our DNS or WINS traffic.</para></listitem>
|
|
</itemizedlist>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Samba Server Name Change Problem</title>
|
|
|
|
<para>
|
|
<quote>The name of the Samba server was changed, Samba was restarted, Samba server cannot be
|
|
ping-ed by new name from MS Windows NT4 Workstation, but it does still respond to ping using
|
|
the old name. Why?</quote>
|
|
</para>
|
|
|
|
<para>
|
|
From this description, three things are obvious:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>WINS is not in use, only broadcast-based name resolution is used.</para></listitem>
|
|
<listitem><para>The Samba server was renamed and restarted within the last 10-15 minutes.</para></listitem>
|
|
<listitem><para>The old Samba server name is still in the NetBIOS name cache on the MS Windows NT4 Workstation.</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
To find what names are present in the NetBIOS name cache on the MS Windows NT4 machine,
|
|
open a <command>cmd</command> shell and then:
|
|
</para>
|
|
|
|
<para>
|
|
<screen>
|
|
&dosprompt;<userinput>nbtstat -n</userinput>
|
|
|
|
NetBIOS Local Name Table
|
|
|
|
Name Type Status
|
|
------------------------------------------------
|
|
&example.workstation.windows; <03> UNIQUE Registered
|
|
ADMINISTRATOR <03> UNIQUE Registered
|
|
&example.workstation.windows; <00> UNIQUE Registered
|
|
SARDON <00> GROUP Registered
|
|
&example.workstation.windows; <20> UNIQUE Registered
|
|
&example.workstation.windows; <1F> UNIQUE Registered
|
|
|
|
|
|
&dosprompt;nbtstat -c
|
|
|
|
NetBIOS Remote Cache Name Table
|
|
|
|
Name Type Host Address Life [sec]
|
|
--------------------------------------------------------------
|
|
&example.server.samba; <20> UNIQUE 192.168.1.1 240
|
|
|
|
&dosprompt;
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
In the above example, &example.server.samba; is the Samba server and &example.workstation.windows; is the MS Windows NT4 Workstation.
|
|
The first listing shows the contents of the Local Name Table (i.e., Identity information on
|
|
the MS Windows workstation) and the second shows the NetBIOS name in the NetBIOS name cache.
|
|
The name cache contains the remote machines known to this workstation.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
</chapter>
|