summaryrefslogtreecommitdiff
path: root/docs/htmldocs/integrate-ms-networks.html
diff options
context:
space:
mode:
authorJelmer Vernooij <jelmer@samba.org>2003-09-23 21:24:11 +0000
committerJelmer Vernooij <jelmer@samba.org>2003-09-23 21:24:11 +0000
commit4d6b1b6836af6b8e46d03b2f0357a2d171a9c0cb (patch)
tree1b410259a6201d72d936cf8b8281624ea887f19a /docs/htmldocs/integrate-ms-networks.html
parentb222defc2743d7003f3eaa95864e93cbe5bbea66 (diff)
downloadsamba-4d6b1b6836af6b8e46d03b2f0357a2d171a9c0cb.tar.gz
samba-4d6b1b6836af6b8e46d03b2f0357a2d171a9c0cb.tar.bz2
samba-4d6b1b6836af6b8e46d03b2f0357a2d171a9c0cb.zip
regenerate
(This used to be commit bdee29ef5b45210c4d6477e5e764a8a298bebaa7)
Diffstat (limited to 'docs/htmldocs/integrate-ms-networks.html')
-rw-r--r--docs/htmldocs/integrate-ms-networks.html427
1 files changed, 427 insertions, 0 deletions
diff --git a/docs/htmldocs/integrate-ms-networks.html b/docs/htmldocs/integrate-ms-networks.html
new file mode 100644
index 0000000000..2e75885499
--- /dev/null
+++ b/docs/htmldocs/integrate-ms-networks.html
@@ -0,0 +1,427 @@
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 26. Integrating MS Windows Networks with Samba</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="previous" href="pam.html" title="Chapter 25. PAM-Based Distributed Authentication"><link rel="next" href="unicode.html" title="Chapter 27. Unicode/Charsets"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 26. Integrating MS Windows Networks with Samba</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="pam.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="unicode.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="integrate-ms-networks"></a>Chapter 26. Integrating MS Windows Networks with Samba</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email">&lt;<a href="mailto:jht@samba.org">jht@samba.org</a>&gt;</tt></p></div></div></div></div><div><p class="pubdate"> (Jan 01 2001) </p></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="integrate-ms-networks.html#id2961659">Features and Benefits</a></dt><dt><a href="integrate-ms-networks.html#id2961683">Background Information</a></dt><dt><a href="integrate-ms-networks.html#id2961747">Name Resolution in a Pure UNIX/Linux World</a></dt><dd><dl><dt><a href="integrate-ms-networks.html#id2961804">/etc/hosts</a></dt><dt><a href="integrate-ms-networks.html#id2961955">/etc/resolv.conf</a></dt><dt><a href="integrate-ms-networks.html#id2961999">/etc/host.conf</a></dt><dt><a href="integrate-ms-networks.html#id2962064">/etc/nsswitch.conf</a></dt></dl></dd><dt><a href="integrate-ms-networks.html#id2962179">Name Resolution as Used within MS Windows Networking</a></dt><dd><dl><dt><a href="integrate-ms-networks.html#id2962531">The NetBIOS Name Cache</a></dt><dt><a href="integrate-ms-networks.html#id2962597">The LMHOSTS File</a></dt><dt><a href="integrate-ms-networks.html#id2962844">HOSTS File</a></dt><dt><a href="integrate-ms-networks.html#id2962877">DNS Lookup</a></dt><dt><a href="integrate-ms-networks.html#id2962910">WINS Lookup</a></dt></dl></dd><dt><a href="integrate-ms-networks.html#id2963026">Common Errors</a></dt><dd><dl><dt><a href="integrate-ms-networks.html#id2963041">Pinging Works Only in One Way</a></dt><dt><a href="integrate-ms-networks.html#id2963083">Very Slow Network Connections</a></dt><dt><a href="integrate-ms-networks.html#id2963134">Samba Server Name Change Problem</a></dt></dl></dd></dl></div><p>
+<a class="indexterm" name="id2961626"></a>
+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.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+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 the existence of such a protocol is a complete
+and utter misapprehension.
+</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2961659"></a>Features and Benefits</h2></div></div><div></div></div><p>
+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).
+</p><p>
+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.
+</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2961683"></a>Background Information</h2></div></div><div></div></div><p>
+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.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+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).
+</p></div><p>
+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
+<a class="indexterm" name="id2961722"></a>
+Dynamic DNS with Service Resource Records (SRV RR) and with Incremental Zone Transfers (IXFR).
+<a class="indexterm" name="id2961735"></a>
+Use of DHCP with ADS is recommended as a further means of maintaining central control
+over the client workstation network configuration.
+</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2961747"></a>Name Resolution in a Pure UNIX/Linux World</h2></div></div><div></div></div><p>
+The key configuration files covered in this section are:
+</p><div class="itemizedlist"><ul type="disc"><li><p><tt class="filename">/etc/hosts</tt></p></li><li><p><tt class="filename">/etc/resolv.conf</tt></p></li><li><p><tt class="filename">/etc/host.conf</tt></p></li><li><p><tt class="filename">/etc/nsswitch.conf</tt></p></li></ul></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2961804"></a><tt class="filename">/etc/hosts</tt></h3></div></div><div></div></div><p>
+This file contains a static list of IP addresses and names.
+</p><pre class="programlisting">
+127.0.0.1 localhost localhost.localdomain
+192.168.1.1 bigbox.quenya.org bigbox alias4box
+</pre><p>
+The purpose of <tt class="filename">/etc/hosts</tt> is to provide a
+name resolution mechanism so uses do not need to remember
+IP addresses.
+</p><p>
+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.
+</p><p>
+<a class="indexterm" name="id2961857"></a>
+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.
+</p><p>
+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
+this is the address that will be returned in the ARP reply.
+</p><p>
+When a user or a process wants to communicate with another machine,
+the protocol implementation ensures that the &#8220;<span class="quote">machine name</span>&#8221; or &#8220;<span class="quote">host
+name</span>&#8221; is resolved to an IP address in a manner that is controlled
+by the TCP/IP configuration control files. The file
+<tt class="filename">/etc/hosts</tt> is one such file.
+</p><p>
+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.
+</p><p>
+<a class="indexterm" name="id2961931"></a>
+The <tt class="filename">/etc/hosts</tt> 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.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2961955"></a><tt class="filename">/etc/resolv.conf</tt></h3></div></div><div></div></div><p>
+This file tells the name resolution libraries:
+</p><div class="itemizedlist"><ul type="disc"><li><p>The name of the domain to which the machine
+ belongs.
+ </p></li><li><p>The name(s) of any domains that should be
+ automatically searched when trying to resolve unqualified
+ host names to their IP address.
+ </p></li><li><p>The name or IP address of available Domain
+ Name Servers that may be asked to perform name-to-address
+ translation lookups.
+ </p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2961999"></a><tt class="filename">/etc/host.conf</tt></h3></div></div><div></div></div><p>
+<a class="indexterm" name="id2962014"></a>
+<tt class="filename">/etc/host.conf</tt> is the primary means by
+which the setting in <tt class="filename">/etc/resolv.conf</tt> may be effected. It is a
+critical configuration file. This file controls the order by
+which name resolution may proceed. The typical structure is:
+</p><pre class="programlisting">
+order hosts,bind
+multi on
+</pre><p>
+then both addresses should be returned. Please refer to the
+man page for <tt class="filename">host.conf</tt> for further details.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2962064"></a><tt class="filename">/etc/nsswitch.conf</tt></h3></div></div><div></div></div><p>
+<a class="indexterm" name="id2962078"></a>
+This file controls the actual name resolution targets. The
+file typically has resolver object specifications as follows:
+</p><pre class="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
+</pre><p>
+Of course, each of these mechanisms requires that the appropriate
+facilities and/or services are correctly configured.
+</p><p>
+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.
+</p><p>
+<a class="indexterm" name="id2962123"></a>
+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., <b class="userinput"><tt>make
+nsswitch/libnss_wins.so</tt></b>). The resulting library should
+then be installed in the <tt class="filename">/lib</tt> directory and
+the <i class="parameter"><tt>wins</tt></i> parameter needs to be added to the &#8220;<span class="quote">hosts:</span>&#8221; line in
+the <tt class="filename">/etc/nsswitch.conf</tt> 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.
+</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2962179"></a>Name Resolution as Used within MS Windows Networking</h2></div></div><div></div></div><p>
+MS Windows networking is predicated about the name each machine
+is given. This name is known variously (and inconsistently) as
+the &#8220;<span class="quote">computer name,</span>&#8221; &#8220;<span class="quote">machine name,</span>&#8221; &#8220;<span class="quote">networking name,</span>&#8221; &#8220;<span class="quote">netbios name,</span>&#8221;
+or &#8220;<span class="quote">SMB name.</span>&#8221; All terms mean the same thing with the exception of
+&#8220;<span class="quote">netbios name</span>&#8221; that can also apply to the name of the workgroup or the
+domain name. The terms &#8220;<span class="quote">workgroup</span>&#8221; and &#8220;<span class="quote">domain</span>&#8221; are really just a
+simple name with which the machine is associated. All NetBIOS names
+are exactly 16 characters in length. The 16<sup>th</sup> 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.
+</p><p>
+<link linkend="uniqnetbiosnames"> and <link linkend="netbiosnamesgrp"> list typical NetBIOS name/service type registrations.
+</p><div class="table"><a name="uniqnetbiosnames"></a><p class="title"><b>Table 26.1. Unique NetBIOS Names</b></p><table summary="Unique NetBIOS Names" border="1"><colgroup><col align="left"><col align="justify"></colgroup><tbody><tr><td align="left">MACHINENAME&lt;00&gt;</td><td align="justify">Server Service is running on MACHINENAME</td></tr><tr><td align="left">MACHINENAME&lt;03&gt;</td><td align="justify">Generic Machine Name (NetBIOS name)</td></tr><tr><td align="left">MACHINENAME&lt;20&gt;</td><td align="justify">LanMan Server service is running on MACHINENAME</td></tr><tr><td align="left">WORKGROUP&lt;1b&gt;</td><td align="justify">Domain Master Browser</td></tr></tbody></table></div><div class="table"><a name="netbiosnamesgrp"></a><p class="title"><b>Table 26.2. Group Names</b></p><table summary="Group Names" border="1"><colgroup><col align="left"><col align="justify"></colgroup><tbody><tr><td align="left">WORKGROUP&lt;03&gt;</td><td align="justify">Generic Name registered by all members of WORKGROUP</td></tr><tr><td align="left">WORKGROUP&lt;1c&gt;</td><td align="justify">Domain Controllers / Netlogon Servers</td></tr><tr><td align="left">WORKGROUP&lt;1d&gt;</td><td align="justify">Local Master Browsers</td></tr><tr><td align="left">WORKGROUP&lt;1e&gt;</td><td align="justify">Internet Name Resolvers</td></tr></tbody></table></div><p>
+<a class="indexterm" name="id2962414"></a>
+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 <tt class="filename">/etc/hosts</tt> or in the DNS database what names
+are associated with each IP address.
+</p><p>
+<a class="indexterm" name="id2962438"></a>
+One further point of clarification should be noted. The <tt class="filename">/etc/hosts</tt>
+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 *&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.
+</p><p>
+The name &#8220;<span class="quote">workgroup</span>&#8221; or &#8220;<span class="quote">domain</span>&#8221; really can be confusing since these
+have the added significance of indicating what is the security
+architecture of the MS Windows network. The term &#8220;<span class="quote">workgroup</span>&#8221; 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.
+</p><p>
+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 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 in which case the resulting protocol is called
+NBT or NetBT, the NetBIOS over TCP/IP.
+</p><p>
+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.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2962531"></a>The NetBIOS Name Cache</h3></div></div><div></div></div><p>
+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.
+</p><p>
+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.
+</p><p>
+<a class="indexterm" name="id2962566"></a>
+<a class="indexterm" name="id2962574"></a>
+The MS Windows utility that allows examination of the NetBIOS
+name cache is called &#8220;<span class="quote">nbtstat</span>&#8221;. The Samba equivalent of this
+is called <b class="command">nmblookup</b>.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2962597"></a>The LMHOSTS File</h3></div></div><div></div></div><p>
+<a class="indexterm" name="id2962608"></a>
+This file is usually located in MS Windows NT 4.0 or Windows 200x/XP in the directory
+<tt class="filename">C:\WINNT\SYSTEM32\DRIVERS\ETC</tt> and contains the IP Address
+and the machine name in matched pairs. The <tt class="filename">LMHOSTS</tt> file
+performs NetBIOS name to IP address mapping.
+</p><p>
+It typically looks like this:
+</p><pre class="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 computernames
+# (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 computername. The address and the computername
+# 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 preloaded 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
+# LanManServer 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
+# preloaded, 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.
+</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2962844"></a>HOSTS File</h3></div></div><div></div></div><p>
+This file is usually located in MS Windows NT 4.0 or Windows 200x/XP in
+the directory <tt class="filename">C:\WINNT\SYSTEM32\DRIVERS\ETC</tt> 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 <tt class="filename">/etc/hosts</tt> file.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2962877"></a>DNS Lookup</h3></div></div><div></div></div><p>
+<a class="indexterm" name="id2962888"></a>
+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.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2962910"></a>WINS Lookup</h3></div></div><div></div></div><p>
+<a class="indexterm" name="id2962921"></a>
+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.
+</p><p>
+To configure Samba to be a WINS server, the following parameter needs
+to be added to the <tt class="filename">smb.conf</tt> file:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>wins support = Yes</tt></i></td></tr></table><p>
+To configure Samba to use a WINS server, the following parameters are
+needed in the <tt class="filename">smb.conf</tt> file:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>wins support = No</tt></i></td></tr><tr><td><i class="parameter"><tt>wins server = xxx.xxx.xxx.xxx</tt></i></td></tr></table><p>
+where <i class="replaceable"><tt>xxx.xxx.xxx.xxx</tt></i> is the IP address
+of the WINS server.
+</p><p>For information about setting up Samba as a WINS server, read
+<link linkend="NetworkBrowsing">.</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2963026"></a>Common Errors</h2></div></div><div></div></div><p>
+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!
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2963041"></a>Pinging Works Only in One Way</h3></div></div><div></div></div><p>
+ &#8220;<span class="quote">I can ping my Samba server from Windows, but I cannot ping my Windows
+ machine from the Samba server.</span>&#8221;
+ </p><p>
+ <span class="emphasis"><em>Answer:</em></span> 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.
+ </p><p>
+ 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 logically a different network.
+ </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2963083"></a>Very Slow Network Connections</h3></div></div><div></div></div><p>
+ A common cause of slow network response includes:
+ </p><div class="itemizedlist"><ul type="disc"><li><p>Client is configured to use DNS and the DNS server is down.</p></li><li><p>Client is configured to use remote DNS server, but the
+ remote connection is down.</p></li><li><p>Client is configured to use a WINS server, but there is no WINS server.</p></li><li><p>Client is not configured to use a WINS server, but there is a WINS server.</p></li><li><p>Firewall is filtering our DNS or WINS traffic.</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2963134"></a>Samba Server Name Change Problem</h3></div></div><div></div></div><p>
+ &#8220;<span class="quote">The name of the Samba server was changed, Samba was restarted, Samba server cannot be
+ pinged by new name from MS Windows NT4 Workstation, but it does still respond to ping using
+ the old name. Why?</span>&#8221;
+ </p><p>
+ From this description, three things are obvious:
+ </p><div class="itemizedlist"><ul type="disc"><li><p>WINS is not in use, only broadcast-based name resolution is used.</p></li><li><p>The Samba server was renamed and restarted within the last 10-15 minutes.</p></li><li><p>The old Samba server name is still in the NetBIOS name cache on the MS Windows NT4 Workstation.</p></li></ul></div><p>
+ To find what names are present in the NetBIOS name cache on the MS Windows NT4 machine,
+ open a <b class="command">cmd</b> shell and then:
+ </p><p>
+</p><pre class="screen">
+<tt class="prompt">C:\&gt; </tt><b class="userinput"><tt>nbtstat -n</tt></b>
+
+ NetBIOS Local Name Table
+
+ Name Type Status
+------------------------------------------------
+FRODO &lt;03&gt; UNIQUE Registered
+ADMINSTRATOR &lt;03&gt; UNIQUE Registered
+FRODO &lt;00&gt; UNIQUE Registered
+SARDON &lt;00&gt; GROUP Registered
+FRODO &lt;20&gt; UNIQUE Registered
+FRODO &lt;1F&gt; UNIQUE Registered
+
+
+<tt class="prompt">C:\&gt; </tt>nbtstat -c
+
+ NetBIOS Remote Cache Name Table
+
+ Name Type Host Address Life [sec]
+--------------------------------------------------------------
+GANDALF &lt;20&gt; UNIQUE 192.168.1.1 240
+
+<tt class="prompt">C:\&gt; </tt>
+</pre><p>
+ </p><p>
+ In the above example, GANDALF is the Samba server and FRODO 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.
+ </p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="pam.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="unicode.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 25. PAM-Based Distributed Authentication </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 27. Unicode/Charsets</td></tr></table></div></body></html>