Moving docs tree to docs-xml to make room for generated docs in the release tarball.

(This used to be commit 9f672c26d63955f613088489c6efbdc08b5b2d14)

1 files changed, 745 insertions, 0 deletions

diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-Integrating-with-Windows.xml b/docs-xml/Samba3-HOWTO/TOSHARG-Integrating-with-Windows.xml
new file mode 100644
index 0000000000..68b9d49b69
--- /dev/null
+++ b/docs-xml/Samba3-HOWTO/TOSHARG-Integrating-with-Windows.xml
@@ -0,0 +1,745 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
+<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 chapter 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 chapter may help you to resolve networking problems.
+</para>
+
+<note>
+<para>
+<indexterm><primary>NetBEUI</primary></indexterm>
+<indexterm><primary>LLC</primary></indexterm>
+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 that 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>
+<indexterm><primary>NetBIOS over TCP/IP</primary></indexterm>
+<indexterm><primary>UDP port 137</primary></indexterm>
+<indexterm><primary>TCP port 139</primary></indexterm>
+<indexterm><primary>TCP port 445</primary></indexterm>
+<indexterm><primary>UDP port 137</primary></indexterm>
+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 is
+used, and the UDP port 137 and TCP port 139 are 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>
+<indexterm><primary>DNS</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>DDNS</primary></indexterm>
+<indexterm><primary>SRV RR</primary></indexterm>
+<indexterm><primary>IXFR</primary></indexterm>
+<indexterm><primary>DHCP</primary></indexterm>
+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>
+
+<indexterm><primary>/etc/hosts</primary></indexterm>
+<indexterm><primary>/etc/resolv.conf</primary></indexterm>
+<indexterm><primary>/etc/host.conf</primary></indexterm>
+<indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
+
+<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.
+<programlisting>
+127.0.0.1	localhost localhost.localdomain
+192.168.1.1	bigbox.quenya.org	bigbox	alias4box
+</programlisting>
+</para>
+
+<para>
+<indexterm><primary>/etc/hosts></primary></indexterm>
+<indexterm><primary>name resolution</primary></indexterm>
+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>
+<indexterm><primary>IP addresses</primary></indexterm>
+<indexterm><primary>MAC address</primary></indexterm>
+<indexterm><primary>physical network transport layer</primary></indexterm>
+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 decimal 
+numbers that are separated by a dot (or period) &smbmdash; 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 Address Resolution Protocol (ARP) reply.
+</para>
+
+<para>
+<indexterm><primary>machine name</primary></indexterm>
+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>
+<indexterm><primary>ARP/RARP</primary></indexterm>
+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 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:
+<programlisting>
+order hosts,bind
+multi on
+</programlisting></para>
+
+<para>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:
+<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>
+<indexterm><primary>NetBIOS names</primary></indexterm>
+<indexterm><primary>make</primary></indexterm>
+<indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
+<indexterm><primary>wins</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>
+<indexterm><primary>computer name</primary></indexterm>
+<indexterm><primary>machine name</primary></indexterm>
+<indexterm><primary>NetBIOS name</primary></indexterm>
+<indexterm><primary>SMB name</primary></indexterm>
+MS Windows networking is predicated on 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> which 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 1-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&lt;00&gt;</entry><entry>Server Service is running on MACHINENAME</entry></row>
+<row><entry>MACHINENAME&lt;03&gt;</entry><entry>Generic machine name (NetBIOS name)</entry></row>
+<row><entry>MACHINENAME&lt;20&gt;</entry><entry>LanMan server service is running on MACHINENAME</entry></row>
+<row><entry>WORKGROUP&lt;1b&gt;</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&lt;03&gt;</entry><entry>Generic name registered by all members of WORKGROUP</entry></row>
+<row><entry>WORKGROUP&lt;1c&gt;</entry><entry>Domain cntrollers/netlogon servers</entry></row>
+<row><entry>WORKGROUP&lt;1d&gt;</entry><entry>Local master browsers</entry></row>
+<row><entry>WORKGROUP&lt;1e&gt;</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 <link linkend="uniqnetbiosnames">Unique NetBIOS names</link> and <link
+linkend="netbiosnamesgrp">group names</link>. This is in vast contrast to TCP/IP 
+installations where the system administrator traditionally 
+determines 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>
+<indexterm><primary>/etc/hosts</primary></indexterm>
+<indexterm><primary>NetBIOS name</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 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 *&lt;1C&gt;. 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>
+<indexterm><primary>domain</primary></indexterm>
+<indexterm><primary>workgroup</primary></indexterm>
+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 username and a matching password.
+</para>
+
+<para>
+<indexterm><primary>SMB</primary></indexterm>
+<indexterm><primary>Network Basic Input/Output System</primary><see>NetBIOS</see></indexterm>
+<indexterm><primary>Logical Link Control</primary><see>LLC</see></indexterm>
+<indexterm><primary>Network Basic Extended User Interface</primary><see>NetBEUI</see></indexterm>
+<indexterm><primary>Internetworking Packet Exchange</primary><see>IPX</see></indexterm>
+<indexterm><primary>NetWare</primary></indexterm>
+<indexterm><primary>NetBT</primary></indexterm>
+<indexterm><primary>NBT</primary></indexterm>
+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 (Internetworking 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>
+<indexterm><primary>n-memory buffer</primary></indexterm>
+<indexterm><primary>local cache</primary></indexterm>
+<indexterm><primary></primary></indexterm>
+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 to 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>
+<indexterm><primary>name lookup</primary></indexterm>
+If a machine whose name is in the local name cache is shut 
+down before the name is expired and flushed from the cache, then 
+an attempt to exchange a message with that machine will be subject 
+to timeout 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>
+<indexterm><primary>NetBIOS</primary></indexterm>
+The MS Windows utility that allows examination of the NetBIOS 
+name cache is called <quote>nbtstat.</quote> The Samba equivalent
+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>%SystemRoot%\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:&lt;domain&gt;
+#      #INCLUDE &lt;filename&gt;
+#      #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 preloaded into the name cache. By default, entries are
+# not preloaded, but are parsed only after dynamic name resolution fails.
+#
+# Following an entry with the "#DOM:&lt;domain&gt;" tag will associate the
+# entry with the domain specified by &lt;domain&gt;. 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 &lt;domain&gt; is always pre-loaded although it will not
+# be shown when the name cache is viewed.
+#
+# Specifying "#INCLUDE &lt;filename&gt;" will force the RFC NetBIOS (NBT)
+# software to seek the specified &lt;filename&gt; and parse it as if it were
+# local. &lt;filename&gt; 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>%SystemRoot%\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 dependent 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>
+<indexterm><primary>Windows Internet Name Server</primary><see>WINS</see></indexterm>
+<indexterm><primary>NetBIOS Name Server</primary><see>NBNS</see></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">Yes</smbconfoption>
+</smbconfblock></para>
+
+<para>
+<indexterm><primary>WINS</primary></indexterm>
+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">No</smbconfoption>
+<smbconfoption name="wins server">xxx.xxx.xxx.xxx</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 to forgetfulness to simple mistakes to
+carelessness. Of course, no one is ever deliberately careless!
+</para>
+
+	<sect2>
+		<title>Pinging Works Only 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>
+	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 out 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, and now the Samba server cannot be
+	pinged by its new name from an MS Windows NT4 workstation, but it does still respond to pinging 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 or 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;            &lt;03&gt;  UNIQUE      Registered
+ADMINISTRATOR     &lt;03&gt;  UNIQUE      Registered
+&example.workstation.windows;            &lt;00&gt;  UNIQUE      Registered
+SARDON           &lt;00&gt;  GROUP       Registered
+&example.workstation.windows;            &lt;20&gt;  UNIQUE      Registered
+&example.workstation.windows;            &lt;1F&gt;  UNIQUE      Registered
+
+
+&dosprompt;nbtstat -c
+
+             NetBIOS Remote Cache Name Table
+
+   Name                 Type       Host Address     Life [sec]
+--------------------------------------------------------------
+&example.server.samba;	&lt;20&gt;  UNIQUE      192.168.1.1          240
+
+&dosprompt;
+</screen>
+	</para>
+
+	<para>
+	In this 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>