docs-xml/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml

   1 <?xml version="1.0" encoding="iso-8859-1"?>
   2 <!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
   3 <chapter id="NetworkBrowsing">
   4 <chapterinfo>
   5         &author.jht;
   6         &author.jelmer;
   7         <author>
   8                 <firstname>Jonathan</firstname><surname>Johnson</surname>
   9                 <affiliation>
  10                         <orgname>Sutinen Consulting, Inc.</orgname>
  11                         <address><email>jon@sutinen.com</email></address>
  12                 </affiliation>
  13         </author>
  14         <pubdate>July 5, 1998</pubdate>
  15         <pubdate>Updated: September 20, 2006</pubdate>
  16 </chapterinfo>
  17
  18 <title>Network Browsing</title>
  19
  20 <para>
  21 <indexterm><primary>browsing across subnets</primary></indexterm>
  22 <indexterm><primary>resolution of NetBIOS names</primary></indexterm>
  23 <indexterm><primary>browse list handling</primary></indexterm>
  24 <indexterm><primary>WINS</primary></indexterm>
  25 This chapter contains detailed information as well as a fast-track guide to
  26 implementing browsing across subnets and/or across workgroups (or domains).
  27 WINS is the best tool for resolution of NetBIOS names to IP addresses; however, WINS is
  28 not involved in browse list handling except by way of name-to-address resolution.
  29 </para>
  30
  31 <note><para>
  32 <indexterm><primary>WINS</primary></indexterm>
  33 What is WINS?
  34 </para>
  35 <para>
  36 WINS is a facility that provides resolution of a NetBIOS name to its IP address. WINS is like a
  37 Dynamic-DNS service for NetBIOS networking names.
  38 </para></note>
  39
  40 <note><para>
  41 <indexterm><primary>Windows 2000</primary></indexterm>
  42 <indexterm><primary>NetBIOS over TCP/IP</primary></indexterm>
  43 <indexterm><primary>DNS</primary></indexterm>
  44 <indexterm><primary>ADS</primary></indexterm>
  45 MS Windows 2000 and later versions can be configured to operate with no NetBIOS
  46 over TCP/IP. Samba-3 and later versions also support this mode of operation.
  47 When the use of NetBIOS over TCP/IP has been disabled, the primary
  48 means for resolution of MS Windows machine names is via DNS and Active Directory.
  49 The following information assumes that your site is running NetBIOS over TCP/IP.
  50 </para></note>
  51
  52 <sect1>
  53 <title>Features and Benefits</title>
  54
  55 <para>
  56 Charles Dickens once referred to the past in these words: <quote><emphasis>It was the best of times,
  57 it was the worst of times.</emphasis></quote> The more we look back, the more we long for what was and
  58 hope it never returns.
  59 </para>
  60
  61
  62 <para>
  63 <indexterm><primary>NetBIOS</primary></indexterm>
  64 <indexterm><primary>NetBIOS networking</primary></indexterm>
  65 <indexterm><primary>fickle</primary></indexterm>
  66 For many MS Windows network administrators, that statement sums up their feelings about
  67 NetBIOS networking precisely. For those who mastered NetBIOS networking, its fickle
  68 nature was just par for the course. For those who never quite managed to tame its
  69 lusty features, NetBIOS is like Paterson's Curse.
  70 </para>
  71
  72 <para>
  73 For those not familiar with botanical problems in Australia, Paterson's Curse,
  74 <emphasis>Echium plantagineum</emphasis>, was introduced to Australia from Europe during the mid-19th
  75 century. Since then it has spread rapidly. The high seed production, with densities of
  76 thousands of seeds per square meter, a seed longevity of more than 7 years, and an
  77 ability to germinate at any time of year, given the right conditions, are some of the
  78 features that make it such a persistent weed.
  79 </para>
  80
  81 <para>
  82 <indexterm><primary>Network Basic Input/Output System</primary><see>NetBIOS</see></indexterm>
  83 <indexterm><primary>SMB</primary></indexterm>
  84 <indexterm><primary>NetBIOS</primary></indexterm>
  85 <indexterm><primary>TCP/IP</primary></indexterm>
  86 <indexterm><primary>Windows network clients</primary></indexterm>
  87 In this chapter we explore vital aspects of Server Message Block (SMB) networking with
  88 a particular focus on SMB as implemented through running NetBIOS (Network Basic
  89 Input/Output System) over TCP/IP. Since Samba does not implement SMB or NetBIOS over
  90 any other protocols, we need to know how to configure our network environment and simply
  91 remember to use nothing but TCP/IP on all our MS Windows network clients.
  92 </para>
  93
  94 <para>
  95 <indexterm><primary>WINS</primary></indexterm>
  96 <indexterm><primary>MS WINS</primary></indexterm>
  97 Samba provides the ability to implement a WINS (Windows Internetworking Name Server)
  98 and implements extensions to Microsoft's implementation of WINS. These extensions
  99 help Samba to effect stable WINS operations beyond the normal scope of MS WINS.
 100 </para>
 101
 102 <para>
 103 <indexterm><primary>NetBIOS over TCP/IP</primary></indexterm>
 104 <indexterm><primary>NetBIOS disabled</primary></indexterm>
 105 <indexterm><primary>WINS</primary></indexterm>
 106 WINS is exclusively a service that applies only to those systems
 107 that run NetBIOS over TCP/IP. MS Windows 200x/XP have the capacity to operate with
 108 support for NetBIOS disabled, in which case WINS is of no relevance. Samba supports this also.
 109 </para>
 110
 111 <para>
 112 <indexterm><primary>NetBIOS disabled</primary></indexterm>
 113 <indexterm><primary>DNS</primary></indexterm>
 114 <indexterm><primary>WINS</primary></indexterm>
 115 For those networks on which NetBIOS has been disabled (i.e., WINS is not required),
 116 the use of DNS is necessary for hostname resolution.
 117 </para>
 118
 119 </sect1>
 120
 121 <sect1>
 122 <title>What Is Browsing?</title>
 123
 124 <para>
 125 <indexterm><primary>browsing</primary></indexterm>
 126 <indexterm><primary>Network Neighborhood</primary></indexterm>
 127 <indexterm><primary>shares</primary></indexterm>
 128 <indexterm><primary>printers available</primary></indexterm>
 129 To most people, browsing means they can see the MS Windows and Samba servers
 130 in the Network Neighborhood, and when the computer icon for a particular server is
 131 clicked, it opens up and shows the shares and printers available on the target server.
 132 </para>
 133
 134 <para>
 135 What seems so simple is in fact a complex interaction of different technologies.
 136 The technologies (or methods) employed in making all of this work include:
 137 </para>
 138
 139 <itemizedlist>
 140         <listitem><para>MS Windows machines register their presence to the network.</para></listitem>
 141         <listitem><para>Machines announce themselves to other machines on the network.</para></listitem>
 142         <listitem><para>One or more machines on the network collate the local announcements.</para></listitem>
 143         <listitem><para>The client machine finds the machine that has the collated list of machines.</para></listitem>
 144         <listitem><para>The client machine is able to resolve the machine names to IP addresses.</para></listitem>
 145         <listitem><para>The client machine is able to connect to a target machine.</para></listitem>
 146 </itemizedlist>
 147
 148 <para>
 149 <indexterm><primary>browse list management</primary></indexterm>
 150 <indexterm><primary>name resolution</primary></indexterm>
 151 <indexterm><primary>nmbd</primary></indexterm>
 152 The Samba application that controls browse list management and name resolution is
 153 called <filename>nmbd</filename>. The configuration parameters involved in nmbd's operation are:
 154 </para>
 155
 156 <para>
 157 Browsing options:
 158 </para>
 159 <itemizedlist>
 160         <listitem><smbconfoption name="os level"/></listitem>
 161         <listitem><smbconfoption name="lm announce"/></listitem>
 162         <listitem><smbconfoption name="lm interval"/></listitem>
 163         <listitem><smbconfoption name="preferred master"/>(*)</listitem>
 164         <listitem><smbconfoption name="local master"/>(*)</listitem>
 165         <listitem><smbconfoption name="domain master"/>(*)</listitem>
 166         <listitem><smbconfoption name="browse list"/></listitem>
 167         <listitem><smbconfoption name="enhanced browsing"/></listitem>
 168 </itemizedlist>
 169
 170 <para>
 171 Name Resolution Method:
 172 </para>
 173 <itemizedlist>
 174         <listitem><smbconfoption name="name resolve order"/>(*)</listitem>
 175 </itemizedlist>
 176
 177 <para>
 178 WINS options:
 179 </para>
 180 <itemizedlist>
 181         <listitem><smbconfoption name="dns proxy"/></listitem>
 182         <listitem><smbconfoption name="wins proxy"/></listitem>
 183         <listitem><smbconfoption name="wins server"/>(*)</listitem>
 184         <listitem><smbconfoption name="wins support"/>(*)</listitem>
 185         <listitem><smbconfoption name="wins hook"/></listitem>
 186 </itemizedlist>
 187
 188 <para>
 189 Those marked with an (*) are the only options that commonly may need to be modified. Even if none of these
 190 parameters is set, <filename>nmbd</filename> will still do its job.
 191 </para>
 192
 193 <para>
 194 <indexterm><primary>WINS</primary></indexterm>
 195 <indexterm><primary>WINS Server</primary></indexterm>
 196 <indexterm><primary>WINS Support</primary></indexterm>
 197 <indexterm><primary>nmbd</primary></indexterm>
 198 <indexterm><primary>mutually exclusive options</primary></indexterm>
 199 For Samba, the WINS Server and WINS Support are mutually exclusive options. When <command>nmbd</command> is
 200 started it will fail to execute if both options are set in the &smb.conf; file. The <command>nmbd</command>
 201 understands that when it spawns an instance of itself to run as a WINS server that it has to use its own WINS
 202 server also.
 203 </para>
 204
 205 </sect1>
 206
 207 <sect1 id="netdiscuss">
 208 <title>Discussion</title>
 209
 210 <para>
 211 <indexterm><primary>SMB-based messaging</primary></indexterm>
 212 <indexterm><primary>NetBIOS</primary></indexterm>
 213 <indexterm><primary>NetBIOS</primary></indexterm>
 214 <indexterm><primary>phasing out NetBIOS</primary></indexterm>
 215 All MS Windows networking uses SMB-based messaging.  SMB messaging may be implemented with or without NetBIOS.
 216 MS Windows 200x supports NetBIOS over TCP/IP for backwards compatibility. Microsoft appears intent on phasing
 217 out NetBIOS support.
 218 </para>
 219
 220 <sect2>
 221 <title>NetBIOS over TCP/IP</title>
 222
 223 <para>
 224 <indexterm><primary>encapsulating</primary></indexterm>
 225 <indexterm><primary>broadcast</primary></indexterm>
 226 <indexterm><primary>unicast</primary></indexterm>
 227 <indexterm><primary>UDP</primary></indexterm>
 228 Samba implements NetBIOS, as does MS Windows NT/200x/XP, by encapsulating it over TCP/IP.
 229 NetBIOS-based networking uses broadcast messaging to effect browse list management. When running NetBIOS over
 230 TCP/IP, this uses UDP-based messaging.  UDP messages can be broadcast or unicast.
 231 </para>
 232
 233 <para>
 234 <indexterm><primary>UDP</primary></indexterm>
 235 Normally, only unicast UDP messaging can be forwarded by routers. The <smbconfoption name="remote announce"/>
 236 parameter to smb.conf helps to project browse announcements to remote network segments via unicast UDP.
 237 Similarly, the <smbconfoption name="remote browse sync"/> parameter of &smb.conf; implements browse list
 238 collation using unicast UDP.
 239 </para>
 240
 241 <para>
 242 The methods used by MS Windows to perform name lookup requests (name resolution) is determined by a
 243 configuration parameter called the NetBIOS node-type. There are four basic NetBIOS node types:
 244 </para>
 245
 246 <indexterm><primary>b-node</primary></indexterm>
 247 <indexterm><primary>p-node</primary></indexterm>
 248 <indexterm><primary>m-node</primary></indexterm>
 249 <indexterm><primary>h-node</primary></indexterm>
 250 <indexterm><primary>node-type</primary></indexterm>
 251 <indexterm><primary>WINS</primary></indexterm>
 252 <indexterm><primary>broadcast</primary></indexterm>
 253 <indexterm><primary>unicast</primary></indexterm>
 254 <itemizedlist>
 255         <listitem><para><emphasis>b-node (type 0x01):</emphasis> The Windows client will use only
 256         NetBIOS broadcast requests using UDP broadcast.</para></listitem>
 257         <listitem><para><emphasis>p-node (type 0x02):</emphasis> The Windows client will use point-to-point
 258         (NetBIOS unicast) requests using UDP unicast directed to a WINS server.</para></listitem>
 259         <listitem><para><emphasis>m-node (type 0x04):</emphasis> The Windows client will first use
 260         NetBIOS broadcast requests using UDP broadcast, then it will use (NetBIOS unicast)
 261         requests using UDP unicast directed to a WINS server.</para></listitem>
 262         <listitem><para><emphasis>h-node (type 0x08):</emphasis> The Windows client will use
 263         (NetBIOS unicast) requests using UDP unicast directed to a WINS server, then it will use
 264         NetBIOS broadcast requests using UDP broadcast.</para></listitem>
 265 </itemizedlist>
 266
 267 <para>
 268 <indexterm><primary>h-node</primary></indexterm>
 269 <indexterm><primary>hybrid</primary></indexterm>
 270 <indexterm><primary>enables NetBIOS over TCP/IP</primary></indexterm>
 271 <indexterm><primary>WINS</primary></indexterm>
 272 <indexterm><primary>broadcast-based</primary></indexterm>
 273 <indexterm><primary>name resolution</primary></indexterm>
 274 The default Windows network client (or server) network configuration enables NetBIOS over TCP/IP
 275 and b-node configuration. The use of WINS makes most sense with h-node (hybrid mode) operation so that
 276 in the event of a WINS breakdown or non-availability, the client can use broadcast-based name resolution.
 277 </para>
 278
 279 <para>
 280 <indexterm><primary>LMB</primary><see>Local Master Browser</see></indexterm>
 281 <indexterm><primary>Local Master Browser</primary></indexterm>
 282 <indexterm><primary>SMB</primary></indexterm>
 283 <indexterm><primary>nmbd</primary></indexterm>
 284 <indexterm><primary>WINS</primary></indexterm>
 285 <indexterm><primary>cross-segment browsing</primary></indexterm>
 286 <indexterm><primary>network segment</primary></indexterm>
 287 In those networks where Samba is the only SMB server technology, wherever possible <filename>nmbd</filename>
 288 should be configured on one machine as the WINS server. This makes it easy to manage the browsing environment.
 289 If each network segment is configured with its own Samba WINS server, then the only way to get cross-segment
 290 browsing to work is by using the <smbconfoption name="remote announce"/> and the <smbconfoption name="remote
 291 browse sync"/> parameters to your &smb.conf; file.
 292 </para>
 293
 294 <para>
 295 <indexterm><primary>WINS</primary></indexterm>
 296 If only one WINS server is used for an entire multisegment network, then
 297 the use of the <smbconfoption name="remote announce"/> and the
 298 <smbconfoption name="remote browse sync"/> parameters should not be necessary.
 299 </para>
 300
 301 <para>
 302 <indexterm><primary>replication</primary><secondary>WINS</secondary></indexterm>
 303 As of Samba-3, WINS replication is being worked on. The bulk of the code has been committed, but it still
 304 needs maturation. This is not a supported feature of the Samba-3.0.20 release. Hopefully, this will become a
 305 supported feature of one of the Samba-3 release series. The delay is caused by the fact that this feature has
 306 not been of sufficient significance to inspire someone to pay a developer to complete it.
 307 </para>
 308
 309 <para>
 310 <indexterm><primary>WINS</primary></indexterm>
 311 <indexterm><primary>MS-WINS replication</primary></indexterm>
 312 <indexterm><primary>redundancy</primary></indexterm>
 313 <indexterm><primary>DNS</primary></indexterm>
 314 <indexterm><primary>NetBIOSless SMB over TCP/IP</primary></indexterm>
 315 <indexterm><primary>local names</primary></indexterm>
 316 <indexterm><primary>subnets</primary></indexterm>
 317 <indexterm><primary>multiple WINS servers</primary></indexterm>
 318 Right now Samba WINS does not support MS-WINS replication. This means that when setting up Samba as a WINS
 319 server, there must only be one <filename>nmbd</filename> configured as a WINS server on the network. Some
 320 sites have used multiple Samba WINS servers for redundancy (one server per subnet) and then used
 321 <smbconfoption name="remote browse sync"/> and <smbconfoption name="remote announce"/> to effect browse list
 322 collation across all segments. Note that this means clients will only resolve local names and must be
 323 configured to use DNS to resolve names on other subnets in order to resolve the IP addresses of the servers
 324 they can see on other subnets. This setup is not recommended but is mentioned as a practical consideration
 325 (i.e., an <quote>if all else fails</quote> scenario). NetBIOS over TCP/IP is an ugly and difficult to manage
 326 protocol. Its replacement, NetBIOSless SMB over TCP/IP is not without its own manageability concerns. NetBIOS
 327 based networking is a life of compromise and trade-offs. WINS stores information that cannot be stored in
 328 DNS; consequently, DNS is a poor substitute for WINS given that when NetBIOS over TCP/IP is used, Windows
 329 clients are designed to use WINS.
 330 </para>
 331
 332 <para>
 333 <indexterm><primary>broadcast messages</primary></indexterm>
 334 <indexterm><primary>repeated intervals</primary></indexterm>
 335 <indexterm><primary>across network segments</primary></indexterm>
 336 Lastly, take note that browse lists are a collection of unreliable broadcast
 337 messages that are repeated at intervals of not more than 15 minutes. This means
 338 that it will take time to establish a browse list, and it can take up to 45
 339 minutes to stabilize, particularly across network segments.
 340 </para>
 341
 342 <para>
 343 <indexterm><primary>Windows 200x/XP</primary></indexterm>
 344 When an MS Windows 200x/XP system attempts to resolve a host name to an IP address, it follows a defined path:
 345 </para>
 346
 347 <orderedlist>
 348         <listitem><para>
 349         Checks the <filename>hosts</filename> file. It is located in <filename>%SystemRoot%\System32\Drivers\etc</filename>.
 350         </para></listitem>
 351
 352         <listitem><para>
 353         Does a DNS lookup.
 354         </para></listitem>
 355
 356         <listitem><para>
 357         Checks the NetBIOS name cache.
 358         </para></listitem>
 359
 360         <listitem><para>
 361         Queries the WINS server.
 362         </para></listitem>
 363
 364         <listitem><para>
 365         Does a broadcast name lookup over UDP.
 366         </para></listitem>
 367
 368         <listitem><para>
 369         Looks up entries in LMHOSTS, located in <filename>%SystemRoot%\System32\Drivers\etc</filename>.
 370         </para></listitem>
 371 </orderedlist>
 372
 373 <para>
 374 <indexterm><primary>WINS</primary></indexterm>
 375 <indexterm><primary>NetBIOS over TCP/IP</primary></indexterm>
 376 <indexterm><primary>name lookups</primary></indexterm>
 377 <indexterm><primary>DNS</primary></indexterm>
 378 Given the nature of how the NetBIOS over TCP/IP protocol is implemented, only WINS is capable of resolving
 379 with any reliability name lookups for service-oriented names such as TEMPTATION&lt;1C&gt; &smbmdash; a NetBIOS
 380 name query that seeks to find network logon servers. DNS has no concept of service-oriented names such as
 381 this. In fact, the Microsoft ADS implementation specifically manages a whole range of extended
 382 service-oriented DNS entries. This type of facility is not implemented and is not supported for the NetBIOS
 383 over TCP/IP protocol namespace.
 384 </para>
 385
 386 </sect2>
 387
 388 <sect2>
 389 <title>TCP/IP without NetBIOS</title>
 390
 391 <para>
 392 <indexterm><primary>NetBIOS</primary></indexterm>
 393 <indexterm><primary>NetBIOS-less</primary></indexterm>
 394 <indexterm><primary>DNS</primary></indexterm>
 395 All TCP/IP-enabled systems use various forms of hostname resolution. The primary
 396 methods for TCP/IP hostname resolution involve either a static file (<filename>/etc/hosts</filename>)
 397 or the Domain Name System (DNS). DNS is the technology that makes
 398 the Internet usable. DNS-based hostname resolution is supported by nearly all
 399 TCP/IP-enabled systems. Only a few embedded TCP/IP systems do not support DNS.
 400 </para>
 401
 402 <para>
 403 <indexterm><primary>DNS</primary></indexterm>
 404 <indexterm><primary>DDNS</primary></indexterm>
 405 <indexterm><primary>ipconfig</primary></indexterm>
 406 <indexterm><primary>Dynamic DNS</primary><see>DDNS</see></indexterm>
 407 Windows 200x/XP can register its hostname with a Dynamic DNS server (DDNS). It is possible to force register with a
 408 dynamic DNS server in Windows 200x/XP using <command>ipconfig /registerdns</command>.
 409 </para>
 410
 411 <para>
 412 <indexterm><primary>ADS</primary></indexterm>
 413 <indexterm><primary>DNS</primary></indexterm>
 414 <indexterm><primary>severely impaired</primary></indexterm>
 415 With Active Directory, a correctly functioning DNS server is absolutely essential. In the absence of a working
 416 DNS server that has been correctly configured, MS Windows clients and servers will be unable to locate each
 417 other, so network services consequently will be severely impaired.
 418 </para>
 419
 420 <para>
 421 <indexterm><primary>raw SMB over TCP/IP</primary></indexterm>
 422 <indexterm><primary>No NetBIOS layer</primary></indexterm>
 423 <indexterm><primary>NetBIOS</primary></indexterm>
 424 <indexterm><primary>domain member server</primary></indexterm>
 425 <indexterm><primary>DNS</primary></indexterm>
 426 <indexterm><primary>ADS</primary></indexterm>
 427 Use of raw SMB over TCP/IP (No NetBIOS layer) can be done only with Active Directory domains. Samba is not an
 428 Active Directory domain controller: ergo, it is not possible to run Samba as a domain controller and at the same
 429 time <emphasis>not</emphasis> use NetBIOS. Where Samba is used as an Active Directory domain member server
 430 (DMS) it is possible to configure Samba to not use NetBIOS over TCP/IP. A Samba DMS can integrate fully into
 431 an Active Directory domain, however, if NetBIOS over TCP/IP is disabled, it is necessary to manually create
 432 appropriate DNS entries for the Samba DMS because they will not be automatically generated either by Samba, or
 433 by the ADS environment.
 434 </para>
 435
 436 </sect2>
 437
 438 <sect2 id="adsdnstech">
 439 <title>DNS and Active Directory</title>
 440
 441 <para>
 442 <indexterm><primary>DNS</primary><secondary>Active Directory</secondary></indexterm>
 443 <indexterm><primary>DDNS</primary></indexterm>
 444 <indexterm><primary>ADS</primary></indexterm>
 445 <indexterm><primary>SRV records</primary></indexterm>
 446 <indexterm><primary>DNS</primary><secondary>SRV records</secondary></indexterm>
 447 Occasionally we hear from UNIX network administrators who want to use a UNIX-based DDNS server in place
 448 of the Microsoft DNS server. While this might be desirable to some, the MS Windows 200x DNS server is
 449 autoconfigured to work with Active Directory. It is possible to use BIND version 8 or 9, but it will almost
 450 certainly be necessary to create service records (SRV records) so MS Active Directory clients can resolve
 451 hostnames to locate essential network services.  The following are some of the default service records that
 452 Active Directory requires:
 453 </para>
 454
 455 <para>
 456 <indexterm><primary>DDNS</primary></indexterm>
 457 <indexterm><primary>ADS</primary></indexterm>
 458 <indexterm><primary>BIND9</primary></indexterm>
 459 The use of DDNS is highly recommended with Active Directory, in which case the use of BIND9 is preferred for
 460 its ability to adequately support the SRV (service) records that are needed for Active Directory. Of course,
 461 when running ADS, it makes sense to use Microsoft's own DDNS server because of the natural affinity between ADS
 462 and MS DNS.
 463 </para>
 464
 465 <variablelist>
 466 <varlistentry>
 467         <term>_ldap._tcp.pdc._msdcs.<emphasis>Domain</emphasis></term>
 468         <listitem>
 469         <para>
 470         This provides the address of the Windows NT PDC for the domain.
 471         </para>
 472         </listitem>
 473 </varlistentry>
 474 <varlistentry>
 475         <term>_ldap._tcp.pdc._msdcs.<emphasis>DomainTree</emphasis></term>
 476         <listitem>
 477         <para>
 478         Resolves the addresses of global catalog servers in the domain.
 479         </para>
 480         </listitem>
 481 </varlistentry>
 482 <varlistentry>
 483         <term>_ldap._tcp.<emphasis>site</emphasis>.sites.writable._msdcs.<emphasis>Domain</emphasis></term>
 484         <listitem>
 485         <para>
 486         Provides list of domain controllers based on sites.
 487         </para>
 488         </listitem>
 489 </varlistentry>
 490 <varlistentry>
 491         <term>_ldap._tcp.writable._msdcs.<emphasis>Domain</emphasis></term>
 492         <listitem>
 493         <para>
 494         Enumerates list of domain controllers that have the writable copies of the Active Directory data store.
 495         </para>
 496         </listitem>
 497 </varlistentry>
 498 <varlistentry>
 499         <term>_ldap._tcp.<emphasis>GUID</emphasis>.domains._msdcs.<emphasis>DomainTree</emphasis></term>
 500         <listitem>
 501         <para>
 502         Entry used by MS Windows clients to locate machines using the global unique identifier.
 503         </para>
 504         </listitem>
 505 </varlistentry>
 506 <varlistentry>
 507         <term>_ldap._tcp.<emphasis>Site</emphasis>.gc._msdcs.<emphasis>DomainTree</emphasis></term>
 508         <listitem>
 509         <para>
 510         Used by Microsoft Windows clients to locate the site configuration-dependent global catalog server.
 511         </para>
 512         </listitem>
 513 </varlistentry>
 514 </variablelist>
 515
 516         <para>
 517         Specific entries used by Microsoft clients to locate essential services for an example domain
 518         called <constant>quenya.org</constant> include:
 519         </para>
 520
 521         <itemizedlist>
 522                 <listitem><para>
 523                 _kerberos._udp.quenya.org &smbmdash; Used to contact the KDC server via UDP.
 524                 This entry must list port 88 for each KDC.
 525                 </para></listitem>
 526
 527                 <listitem><para>
 528                 _kpasswd._udp.quenya.org &smbmdash; Used to locate the <constant>kpasswd</constant> server
 529                 when a user password change must be processed. This record must list port 464 on the
 530                 master KDC.
 531                 </para></listitem>
 532
 533                 <listitem><para>
 534                 _kerberos._tcp.quenya.org &smbmdash; Used to locate the KDC server via TCP.
 535                 This entry must list port 88 for each KDC.
 536                 </para></listitem>
 537
 538                 <listitem><para>
 539                 _ldap._tcp.quenya.org &smbmdash; Used to locate the LDAP service on the PDC.
 540                 This record must list port 389 for the PDC.
 541                 </para></listitem>
 542
 543                 <listitem><para>
 544                 _kpasswd._tcp.quenya.org &smbmdash; Used to locate the <constant>kpasswd</constant> server
 545                 to permit user password changes to be processed. This must list port 464.
 546                 </para></listitem>
 547
 548                 <listitem><para>
 549                 _gc._tcp.quenya.org &smbmdash; Used to locate the global catalog server  for the
 550                 top of the domain. This must list port 3268.
 551                 </para></listitem>
 552         </itemizedlist>
 553
 554         <para>
 555         The following records are also used by the Windows domain member client to locate vital
 556         services on the Windows ADS domain controllers.
 557         </para>
 558
 559         <itemizedlist>
 560                 <listitem><para>
 561                 _ldap._tcp.pdc._msdcs.quenya.org
 562                 </para></listitem>
 563
 564                 <listitem><para>
 565                 _ldap.gc._msdcs.quenya.org
 566                 </para></listitem>
 567
 568                 <listitem><para>
 569                 _ldap.default-first-site-name._sites.gc._msdcs.quenya.org
 570                 </para></listitem>
 571
 572                 <listitem><para>
 573                 _ldap.{SecID}.domains._msdcs.quenya.org
 574                 </para></listitem>
 575
 576                 <listitem><para>
 577                 _ldap._tcp.dc._msdcs.quenya.org
 578                 </para></listitem>
 579
 580                 <listitem><para>
 581                 _kerberos._tcp.dc._msdcs.quenya.org
 582                 </para></listitem>
 583
 584                 <listitem><para>
 585                 _ldap.default-first-site-name._sites.dc._msdcs.quenya.org
 586                 </para></listitem>
 587
 588                 <listitem><para>
 589                 _kerberos.default-first-site-name._sites.dc._msdcs.queyna.org
 590                 </para></listitem>
 591
 592                 <listitem><para>
 593                 SecID._msdcs.quenya.org
 594                 </para></listitem>
 595         </itemizedlist>
 596
 597         <para>
 598         Presence of the correct DNS entries can be validated by executing:
 599 <screen>
 600 &rootprompt; dig @frodo -t any _ldap._tcp.dc._msdcs.quenya.org
 601
 602 ; &lt;lt;&gt;&gt; DiG 9.2.2 &lt;lt;&gt;&gt; @frodo -t any _ldap._tcp.dc._msdcs.quenya.org
 603 ;; global options:  printcmd
 604 ;; Got answer:
 605 ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 3072
 606 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
 607
 608
 609 ;; QUESTION SECTION:
 610 ;_ldap._tcp.dc._msdcs.quenya.org. IN        ANY
 611
 612
 613 ;; ANSWER SECTION:
 614 _ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 frodo.quenya.org.
 615 _ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 noldor.quenya.org.
 616
 617
 618 ;; ADDITIONAL SECTION:
 619 frodo.quenya.org.  3600  IN      A       10.1.1.16
 620 noldor.quenya.org. 1200  IN      A       10.1.1.17
 621
 622
 623 ;; Query time: 0 msec
 624 ;; SERVER: frodo#53(10.1.1.16)
 625 ;; WHEN: Wed Oct  7 14:39:31 2004
 626 ;; MSG SIZE  rcvd: 171
 627 </screen>
 628         </para>
 629
 630 </sect2>
 631
 632 </sect1>
 633
 634 <sect1>
 635 <title>How Browsing Functions</title>
 636
 637 <para>
 638 <indexterm><primary>register NetBIOS names</primary></indexterm>
 639 <indexterm><primary>LMHOSTS</primary></indexterm>
 640 <indexterm><primary>DNS</primary></indexterm>
 641 <indexterm><primary>WINS</primary></indexterm>
 642 <indexterm><primary>WINS server address</primary></indexterm>
 643 MS Windows machines register their NetBIOS names (i.e., the machine name for each service type in operation)
 644 on startup.  The exact method by which this name registration takes place is determined by whether or not the
 645 MS Windows client/server has been given a WINS server address, whether or not LMHOSTS lookup is enabled,
 646 whether or not DNS for NetBIOS name resolution is enabled, and so on.
 647 </para>
 648
 649 <para>
 650 <indexterm><primary>WINS server</primary></indexterm>
 651 <indexterm><primary>name lookups</primary></indexterm>
 652 <indexterm><primary>UDP</primary></indexterm>
 653 In the case where there is no WINS server, all name registrations as well as name lookups are done by UDP
 654 broadcast. This isolates name resolution to the local subnet, unless LMHOSTS is used to list all names and IP
 655 addresses. In such situations, Samba provides a means by which the Samba server name may be forcibly injected
 656 into the browse list of a remote MS Windows network (using the <smbconfoption name="remote announce"/>
 657 parameter).
 658 </para>
 659
 660 <para>
 661 <indexterm><primary>WINS</primary></indexterm>
 662 <indexterm><primary>UDP unicast</primary></indexterm>
 663 <indexterm><primary>name resolution across routed networks</primary></indexterm>
 664 Where a WINS server is used, the MS Windows client will use UDP unicast to register with the WINS server. Such
 665 packets can be routed, and thus WINS allows name resolution to function across routed networks.
 666 </para>
 667
 668 <para>
 669 <indexterm><primary>LMB</primary></indexterm>
 670 <indexterm><primary>local master browser</primary><see>LMB</see></indexterm>
 671 <indexterm><primary>WINS</primary></indexterm>
 672 <indexterm><primary>LMHOSTS</primary></indexterm>
 673 <indexterm><primary>DMB</primary></indexterm>
 674 <indexterm><primary>browse list</primary></indexterm>
 675 <indexterm><primary>election</primary></indexterm>
 676 <indexterm><primary>election criteria</primary></indexterm>
 677 During the startup process, an election takes place to create a local master browser (LMB) if one does not
 678 already exist. On each NetBIOS network one machine will be elected to function as the domain master browser
 679 (DMB). This domain browsing has nothing to do with MS security Domain Control.  Instead, the DMB serves the
 680 role of contacting each LMB (found by asking WINS or from LMHOSTS) and exchanging browse list contents. This
 681 way every master browser will eventually obtain a complete list of all machines that are on the network. Every
 682 11 to 15 minutes an election is held to determine which machine will be the master browser. By the nature of
 683 the election criteria used, the machine with the highest uptime, or the most senior protocol version or other
 684 criteria, will win the election as DMB.
 685 </para>
 686
 687 <para>
 688 <indexterm><primary>WINS server</primary></indexterm>
 689 <indexterm><primary>DMB</primary></indexterm>
 690 <indexterm><primary>NetBIOS name type</primary></indexterm>
 691 <indexterm><primary>n security context</primary></indexterm>
 692 <indexterm><primary>network segment</primary></indexterm>
 693 <indexterm><primary>authoritive</primary></indexterm>
 694 <indexterm><primary>browse list maintainers</primary></indexterm>
 695 <indexterm><primary>LMB</primary></indexterm>
 696 Where a WINS server is used, the DMB registers its IP address with the WINS server using the name of the
 697 domain and the NetBIOS name type 1B (e.g., DOMAIN&lt;1B&gt;). All LMBs register their IP addresses with the WINS
 698 server, also with the name of the domain and the NetBIOS name type of 1D. The 1B name is unique to one
 699 server within the domain security context, and only one 1D name is registered for each network segment.
 700 Machines that have registered the 1D name will be authoritive browse list maintainers for the network segment
 701 they are on. The DMB is responsible for synchronizing the browse lists it obtains from the LMBs.
 702 </para>
 703
 704 <para>
 705 <indexterm><primary>name resolution</primary></indexterm>
 706 Clients wishing to browse the network make use of this list but also depend on the availability of correct
 707 name resolution to the respective IP address or addresses.
 708 </para>
 709
 710 <para>
 711 <indexterm><primary>browsing intrinsics</primary></indexterm>
 712 Any configuration that breaks name resolution and/or browsing intrinsics will annoy users because they will
 713 have to put up with protracted inability to use the network services.
 714 </para>
 715
 716 <para>
 717 <indexterm><primary>forced synchronization</primary></indexterm>
 718 <indexterm><primary>LMB</primary></indexterm>
 719 <indexterm><primary>bridges networks</primary></indexterm>
 720 <indexterm><primary>cross-subnet browsing</primary></indexterm>
 721 <indexterm><primary>DNS</primary></indexterm>
 722 <indexterm><primary>/etc/hosts</primary></indexterm>
 723 Samba supports a feature that allows forced synchronization of browse lists across routed networks using the
 724 <smbconfoption name="remote browse sync"/> parameter in the &smb.conf; file. This causes Samba to contact the
 725 LMB on a remote network and to request browse list synchronization. This effectively bridges two networks that
 726 are separated by routers. The two remote networks may use either broadcast-based name resolution or WINS-based
 727 name resolution, but it should be noted that the <smbconfoption name="remote browse sync"/> parameter provides
 728 browse list synchronization &smbmdash; and that is distinct from name-to-address resolution. In other words,
 729 for cross-subnet browsing to function correctly, it is essential that a name-to-address resolution mechanism
 730 be provided. This mechanism could be via DNS, <filename>/etc/hosts</filename>, and so on.
 731 </para>
 732
 733 <sect2 id="DMB">
 734 <title>Configuring Workgroup Browsing</title>
 735
 736 <para>
 737 <indexterm><primary>cross-subnet browsing</primary></indexterm>
 738 <indexterm><primary>DMB</primary></indexterm>
 739 <indexterm><primary>PDC</primary></indexterm>
 740 <indexterm><primary>LMB</primary></indexterm>
 741 <indexterm><primary>isolated workgroup</primary></indexterm>
 742 <indexterm><primary>workgroup</primary></indexterm>
 743 To configure cross-subnet browsing on a network containing machines in a workgroup, not an NT domain, you need
 744 to set up one Samba server to be the DMB (note that this is not the same as a Primary Domain Controller,
 745 although in an NT domain the same machine plays both roles). The role of a DMB is to collate the browse lists
 746 from LMB on all the subnets that have a machine participating in the workgroup. Without one machine configured
 747 as a DMB, each subnet would be an isolated workgroup unable to see any machines on another subnet. It is the
 748 presence of a DMB that makes cross-subnet browsing possible for a workgroup.
 749 </para>
 750
 751 <para>
 752 <indexterm><primary>DMB</primary></indexterm>
 753 In a workgroup environment the DMB must be a Samba server, and there must only be one DMB per workgroup name.
 754 To set up a Samba server as a DMB, set the following option in the <smbconfsection name="[global]"/> section
 755 of the &smb.conf; file:
 756 </para>
 757
 758 <para>
 759 <smbconfblock>
 760 <smbconfoption name="domain master">yes</smbconfoption>
 761 </smbconfblock>
 762 </para>
 763
 764 <para>
 765 <indexterm><primary>DMB</primary></indexterm>
 766 <indexterm><primary>LMB</primary></indexterm>
 767 The DMB should preferably be the LMB for its own subnet. In order to achieve this, set the following options
 768 in the <smbconfsection name="[global]"/> section of the &smb.conf; file as shown in <link
 769 linkend="dmbexample">Domain Master Browser smb.conf</link>
 770 </para>
 771
 772 <example id="dmbexample">
 773 <title>Domain Master Browser smb.conf</title>
 774 <smbconfblock>
 775 <smbconfsection name="[global]"/>
 776 <smbconfoption name="domain master">yes</smbconfoption>
 777 <smbconfoption name="local master">yes</smbconfoption>
 778 <smbconfoption name="preferred master">yes</smbconfoption>
 779 <smbconfoption name="os level">65</smbconfoption>
 780 </smbconfblock>
 781 </example>
 782
 783 <para>
 784 <indexterm><primary>DMB</primary></indexterm>
 785 <indexterm><primary>WINS server</primary></indexterm>
 786 The DMB may be the same machine as the WINS server, if necessary.
 787 </para>
 788
 789 <para>
 790 <indexterm><primary>subnets</primary></indexterm>
 791 <indexterm><primary>LMB</primary></indexterm>
 792 <indexterm><primary>rebooted</primary></indexterm>
 793 Next, you should ensure that each of the subnets contains a machine that can act as an LMB for the workgroup.
 794 Any MS Windows NT/200x/XP machine should be able to do this, as will Windows 9x/Me machines (although these
 795 tend to get rebooted more often, so it is not such a good idea to use them). To make a Samba server an LMB,
 796 set the following options in the <smbconfsection name="[global]"/> section of the &smb.conf; file as shown in
 797 <link linkend="lmbexample">Local master browser smb.conf</link>
 798 </para>
 799
 800 <example id="lmbexample">
 801 <title>Local master browser smb.conf</title>
 802 <smbconfblock>
 803 <smbconfsection name="[global]"/>
 804 <smbconfoption name="domain master">no</smbconfoption>
 805 <smbconfoption name="local master">yes</smbconfoption>
 806 <smbconfoption name="preferred master">yes</smbconfoption>
 807 <smbconfoption name="os level">65</smbconfoption>
 808 </smbconfblock>
 809 </example>
 810
 811 <para>
 812 <indexterm><primary>LMB</primary></indexterm>
 813 Do not do this for more than one Samba server on each subnet, or they will war with
 814 each other over which is to be the LMB.
 815 </para>
 816
 817 <para>
 818 <indexterm><primary>LMB</primary></indexterm>
 819 <indexterm><primary>browser election</primary></indexterm>
 820 The <smbconfoption name="local master"/> parameter allows Samba to act as a
 821 LMB. The <smbconfoption name="preferred master"/> causes <command>nmbd</command>
 822 to force a browser election on startup and the <smbconfoption name="os level"/>
 823 parameter sets Samba high enough so it should win any browser elections.
 824 </para>
 825
 826 <para>
 827 <indexterm><primary>disable LMB</primary></indexterm>
 828 If you have an NT machine on the subnet that you wish to be the LMB, you can disable Samba from
 829 becoming an LMB by setting the following options in the <smbconfsection name="[global]"/> section of the
 830 &smb.conf; file as shown in <link linkend="nombexample">smb.conf for Not Being a Master Browser</link>.
 831 </para>
 832
 833 <para>
 834 <example id="nombexample">
 835 <title>smb.conf for Not Being a Master Browser</title>
 836 <smbconfblock>
 837 <smbconfsection name="[global]"/>
 838 <smbconfoption name="domain master">no</smbconfoption>
 839 <smbconfoption name="local master">no</smbconfoption>
 840 <smbconfoption name="preferred master">no</smbconfoption>
 841 <smbconfoption name="os level">0</smbconfoption>
 842 </smbconfblock>
 843 </example>
 844 </para>
 845
 846 </sect2>
 847
 848 <sect2>
 849 <title>Domain Browsing Configuration</title>
 850
 851 <para>
 852 <indexterm><primary>DMB</primary></indexterm>
 853 <indexterm><primary>PDC</primary></indexterm>
 854 <indexterm><primary>registers</primary></indexterm>
 855 <indexterm><primary>WINS</primary></indexterm>
 856 If you are adding Samba servers to a Windows NT domain, then you must not set up a Samba server as a DMB.  By
 857 default, a Windows NT PDC for a domain is also the DMB for that domain. Network browsing may break if a Samba
 858 server other than the PDC registers the DMB NetBIOS name (<replaceable>DOMAIN</replaceable>&lt;1B&gt;) with
 859 WINS.
 860 </para>
 861
 862 <para>
 863 <indexterm><primary>Local Master Browser</primary></indexterm>
 864 For subnets other than the one containing the Windows NT PDC, you may set up Samba servers as LMBs as
 865 described. To make a Samba server a Local Master Browser, set the following options in the <smbconfsection
 866 name="[global]"/> section of the &smb.conf; file as shown in <link linkend="remsmb">Local Master Browser
 867 smb.conf</link>
 868 </para>
 869
 870 <example id="remsmb">
 871 <title>Local Master Browser smb.conf</title>
 872 <smbconfblock>
 873 <smbconfsection name="[global]"/>
 874 <smbconfoption name="domain master">no</smbconfoption>
 875 <smbconfoption name="local master">yes</smbconfoption>
 876 <smbconfoption name="preferred master">yes</smbconfoption>
 877 <smbconfoption name="os level">65</smbconfoption>
 878 </smbconfblock>
 879 </example>
 880
 881 <para>
 882 <indexterm><primary>election</primary></indexterm>
 883 <indexterm><primary>LMB</primary></indexterm>
 884 If you wish to have a Samba server fight the election with machines on the same subnet, you may set the
 885 <smbconfoption name="os level"/> parameter to lower levels.  By doing this you can tune the order of machines
 886 that will become LMBs if they are running. For more details on this, refer to <link
 887 linkend="browse-force-master">Forcing Samba to Be the Master</link>.
 888 </para>
 889
 890 <para>
 891 <indexterm><primary>domain members</primary></indexterm>
 892 <indexterm><primary>browser elections</primary></indexterm>
 893 <indexterm><primary>LMB</primary></indexterm>
 894 If you have Windows NT machines that are members of the domain on all subnets and you are sure they will
 895 always be running, you can disable Samba from taking part in browser elections and ever becoming an LMB by
 896 setting the following options in the <smbconfsection name="[global]"/> section of the &smb.conf; file as shown
 897 in <link linkend="xremmb">&smb.conf; for Not Being a master browser</link>
 898 </para>
 899
 900 <para>
 901 <example id="xremmb">
 902 <title>&smb.conf; for Not Being a master browser</title>
 903 <smbconfsection name="[global]"/>
 904 <smbconfoption name="domain master">no</smbconfoption>
 905 <smbconfoption name="local master">no</smbconfoption>
 906 <smbconfoption name="preferred master">no</smbconfoption>
 907 <smbconfoption name="os level">0</smbconfoption>
 908 </example>
 909 </para>
 910
 911 </sect2>
 912
 913 <sect2 id="browse-force-master">
 914 <title>Forcing Samba to Be the Master</title>
 915
 916 <para>
 917 <indexterm><primary>master browser</primary></indexterm>
 918 <indexterm><primary>election process</primary></indexterm>
 919 <indexterm><primary>broadcasts</primary></indexterm>
 920 <indexterm><primary>election packet</primary></indexterm>
 921 <indexterm><primary>bias</primary></indexterm>
 922 <indexterm><primary>election</primary></indexterm>
 923 <indexterm><primary>precedence</primary></indexterm>
 924 Who becomes the master browser is determined by an election process using broadcasts. Each election packet
 925 contains a number of parameters that determine what precedence (bias) a host should have in the election. By
 926 default Samba uses a low precedence and thus loses elections to just about every Windows network server or
 927 client.
 928 </para>
 929
 930 <para>
 931 If you want Samba to win elections, set the <smbconfoption name="os level"/> global option in &smb.conf; to a
 932 higher number. It defaults to 20. Using 34 would make it win all elections over every other system (except
 933 other Samba systems).
 934 </para>
 935
 936 <para>
 937 An <smbconfoption name="os level"/> of two would make it beat Windows for Workgroups and Windows 9x/Me, but
 938 not MS Windows NT/200x Server. An MS Windows NT/200x Server domain controller uses level 32. The maximum os
 939 level is 255.
 940 </para>
 941
 942 <para>
 943 <indexterm><primary>force an election</primary></indexterm>
 944 <indexterm><primary>potential master browsers</primary></indexterm>
 945 <indexterm><primary>local subnet</primary></indexterm>
 946 <indexterm><primary>LMB</primary></indexterm>
 947 If you want Samba to force an election on startup, set the <smbconfoption name="preferred master"/> global
 948 option in &smb.conf; to <constant>yes</constant>.  Samba will then have a slight advantage over other
 949 potential master browsers that are not preferred master browsers.  Use this parameter with care, because if
 950 you have two hosts (whether they are Windows 9x/Me or NT/200x/XP or Samba) on the same local subnet both set
 951 with <smbconfoption name="preferred master"/> to <constant>yes</constant>, then periodically and continually
 952 they will force an election in order to become the LMB.
 953 </para>
 954
 955 <para>
 956 <indexterm><primary>DMB</primary></indexterm>
 957 <indexterm><primary>LAN</primary></indexterm>
 958 <indexterm><primary>WAN</primary></indexterm>
 959 <indexterm><primary>LMB</primary></indexterm>
 960 <indexterm><primary>broadcast isolated subnet</primary></indexterm>
 961 If you want Samba to be a <emphasis>DMB</emphasis>, then it is recommended that you also set <smbconfoption
 962 name="preferred master"/> to <constant>yes</constant>, because Samba will not become a DMB for the whole of
 963 your LAN or WAN if it is not also a LMB on its own broadcast isolated subnet.
 964 </para>
 965
 966 <para>
 967 <indexterm><primary>DMB</primary></indexterm>
 968 <indexterm><primary>automatic redundancy</primary></indexterm>
 969 <indexterm><primary>UDP</primary></indexterm>
 970 <indexterm><primary>network bandwidth</primary></indexterm>
 971 <indexterm><primary>browser elections</primary></indexterm>
 972 It is possible to configure two Samba servers to attempt to become the DMB for a domain. The first server that
 973 comes up will be the DMB. All other Samba servers will attempt to become the DMB every 5 minutes. They will
 974 find that another Samba server is already the DMB and will fail. This provides automatic redundancy should the
 975 current DMB fail. The network bandwidth overhead of browser elections is relatively small, requiring
 976 approximately four UDP packets per machine per election. The maximum size of a UDP packet is 576 bytes.
 977 </para>
 978
 979 </sect2>
 980
 981 <sect2>
 982 <title>Making Samba the Domain Master</title>
 983
 984 <para>
 985 <indexterm><primary>DMB</primary></indexterm>
 986 <indexterm><primary>collating</primary></indexterm>
 987 <indexterm><primary>browse lists</primary></indexterm>
 988 <indexterm><primary>browsing</primary></indexterm>
 989 The domain master browser is responsible for collating the browse lists of multiple subnets so browsing can
 990 occur between subnets. You can make Samba act as the domain master browser by setting <smbconfoption name="domain
 991 master">yes</smbconfoption> in &smb.conf;. By default it will not be a domain master browser.
 992 </para>
 993
 994 <para>
 995 <indexterm><primary>workgroup</primary></indexterm>
 996 <indexterm><primary>network browsing problems</primary></indexterm>
 997 Do not set Samba to be the domain master for a workgroup that has the same name as an NT/200x domain.  If
 998 Samba is configured to be the domain master for a workgroup that is present on the same network as a Windows
 999 NT/200x domain that has the same name, network browsing problems will certainly be experienced.
1000 </para>
1001
1002 <para>
1003 When Samba is the domain master and the master browser, it will listen for master announcements (made roughly
1004 every 12 minutes) from LMBs on other subnets and then contact them to synchronize browse lists.
1005 </para>
1006
1007 <para>
1008 <indexterm><primary>win election</primary></indexterm>
1009 <indexterm><primary>force election</primary></indexterm>
1010 If you want Samba to be the domain master, you should also set the <smbconfoption name="os level"/> high
1011 enough to make sure it wins elections, and set <smbconfoption name="preferred master"/> to
1012 <constant>yes</constant>, to get Samba to force an election on startup.
1013 </para>
1014
1015 <para>
1016 <indexterm><primary>WINS server</primary></indexterm>
1017 <indexterm><primary>resolve NetBIOS names</primary></indexterm>
1018 All servers (including Samba) and clients should be using a WINS server to resolve NetBIOS names. If your
1019 clients are only using broadcasting to resolve NetBIOS names, then two things will occur:
1020 </para>
1021
1022 <orderedlist>
1023 <listitem>
1024         <para>
1025 <indexterm><primary>LMB</primary></indexterm>
1026 <indexterm><primary>DMB</primary></indexterm>
1027         LMBs will be unable to find a DMB because they will be looking only on the local subnet.
1028         </para>
1029 </listitem>
1030
1031 <listitem>
1032         <para>
1033 <indexterm><primary>domain-wide browse list</primary></indexterm>
1034         If a client happens to get hold of a domain-wide browse list and a user attempts to access a
1035         host in that list, it will be unable to resolve the NetBIOS name of that host.
1036         </para>
1037 </listitem>
1038 </orderedlist>
1039
1040 <para>
1041 <indexterm><primary>WINS</primary></indexterm>
1042 If, however, both Samba and your clients are using a WINS server, then:
1043 </para>
1044
1045 <orderedlist>
1046 <listitem>
1047         <para>
1048         LMBs will contact the WINS server and, as long as Samba has registered that it is a DMB with the WINS
1049         server, the LMB will receive Samba's IP address as its DMB.
1050         </para>
1051 </listitem>
1052
1053 <listitem>
1054         <para>
1055         When a client receives a domain-wide browse list and a user attempts to access a host in that list, it will
1056         contact the WINS server to resolve the NetBIOS name of that host. As long as that host has registered its
1057         NetBIOS name with the same WINS server, the user will be able to see that host..
1058         </para>
1059 </listitem>
1060 </orderedlist>
1061
1062 </sect2>
1063
1064 <sect2>
1065 <title>Note about Broadcast Addresses</title>
1066
1067 <para>
1068 <indexterm><primary>zero-based broadcast</primary></indexterm>
1069 If your network uses a zero-based broadcast address (for example, if it ends in a 0), then you will strike
1070 problems. Windows for Workgroups does not seem to support a zeros broadcast, and you will probably find that
1071 browsing and name lookups will not work.
1072 </para>
1073 </sect2>
1074
1075 <sect2>
1076 <title>Multiple Interfaces</title>
1077
1078 <para>
1079 <indexterm><primary>multiple network interfaces</primary></indexterm>
1080 Samba supports machines with multiple network interfaces. If you have multiple interfaces, you will
1081 need to use the <smbconfoption name="interfaces"/> option in &smb.conf; to configure them. For example, the
1082 machine you are working with has 4 network interfaces; <literal>eth0</literal>, <literal>eth1</literal>,
1083 <literal>eth2</literal>, <literal>eth3</literal> and only interfaces <literal>eth1</literal> and
1084 <literal>eth4</literal> should be used by Samba. In this case, the following &smb.conf; file entries would
1085 permit that intent:
1086 <smbconfblock>
1087 <smbconfoption name="interfaces">eth1, eth4</smbconfoption>
1088 <smbconfoption name="bind interfaces only">Yes</smbconfoption>
1089 </smbconfblock>
1090 <indexterm><primary>port 135</primary></indexterm>
1091 <indexterm><primary>port 137</primary></indexterm>
1092 <indexterm><primary>port 138</primary></indexterm>
1093 <indexterm><primary>port 139</primary></indexterm>
1094 <indexterm><primary>port 445</primary></indexterm>
1095 <indexterm><primary>UDP</primary></indexterm>
1096 <indexterm><primary>TCP</primary></indexterm>
1097 The <smbconfoption name="bind interfaces only">Yes</smbconfoption> is necessary to exclude TCP/IP session
1098 services (ports 135, 139, and 445) over the interfaces that are not specified. Please be aware that
1099 <command>nmbd</command> will listen for incoming UDP port 137 packets on the unlisted interfaces, but it will
1100 not answer them. It will, however, send its broadcast packets over the unlisted interfaces. Total isolation of
1101 ethernet interface requires the use of a firewall to block ports 137 and 138 (UDP), and ports 135, 139, and
1102 445 (TCP) on all network interfaces that must not be able to access the Samba server.
1103 </para>
1104
1105 </sect2>
1106
1107 <sect2>
1108 <title>Use of the Remote Announce Parameter</title>
1109 <para>
1110 The <smbconfoption name="remote announce"/> parameter of &smb.conf; can be used to forcibly ensure that all
1111 the NetBIOS names on a network get announced to a remote network.  The syntax of the <smbconfoption
1112 name="remote announce"/> parameter is:
1113 <smbconfblock>
1114 <smbconfoption name="remote announce">192.168.12.23 [172.16.21.255] ...</smbconfoption>
1115 </smbconfblock>
1116 <emphasis>or</emphasis>
1117 <smbconfblock>
1118 <smbconfoption name="remote announce">192.168.12.23/MIDEARTH [172.16.21.255/ELVINDORF] ...</smbconfoption>
1119 </smbconfblock>
1120
1121 where:
1122 <variablelist>
1123         <varlistentry><term><replaceable>192.168.12.23</replaceable> and <replaceable>172.16.21.255</replaceable></term>
1124                 <listitem><para>
1125 <indexterm><primary>LMB</primary><see>Local Master Browser</see></indexterm>
1126 <indexterm><primary>Local Master Browser</primary></indexterm>
1127                 is either the LMB IP address or the broadcast address of the remote network.
1128                 That is, the LMB is at 192.168.1.23, or the address could be given as 172.16.21.255 where the netmask
1129                 is assumed to be 24 bits (255.255.255.0). When the remote announcement is made to the broadcast
1130                 address of the remote network, every host will receive our announcements. This is noisy and therefore
1131                 undesirable but may be necessary if we do not know the IP address of the remote LMB.
1132                 </para></listitem>
1133         </varlistentry>
1134
1135         <varlistentry>
1136                 <term><replaceable>WORKGROUP</replaceable></term>
1137                 <listitem><para>is optional and can be either our own workgroup or that of the remote network. If you use the
1138                 workgroup name of the remote network, our NetBIOS machine names will end up looking like
1139                 they belong to that workgroup. This may cause name resolution problems and should be avoided.
1140                 </para></listitem>
1141         </varlistentry>
1142 </variablelist>
1143 </para>
1144
1145 </sect2>
1146
1147 <sect2>
1148 <title>Use of the Remote Browse Sync Parameter</title>
1149
1150 <para>
1151 <indexterm><primary>LMB</primary></indexterm>
1152 <indexterm><primary>synchronize</primary></indexterm>
1153 The <smbconfoption name="remote browse sync"/> parameter of &smb.conf; is used to announce to another LMB that
1154 it must synchronize its NetBIOS name list with our Samba LMB. This works only if the Samba server that has
1155 this option is simultaneously the LMB on its network segment.
1156 </para>
1157
1158 <para>
1159 The syntax of the <smbconfoption name="remote browse sync"/> parameter is:
1160
1161 <smbconfblock>
1162 <smbconfoption name="remote browse sync"><replaceable>192.168.10.40</replaceable></smbconfoption>
1163 </smbconfblock>
1164 <indexterm><primary>LMB</primary></indexterm>
1165 <indexterm><primary>remote segment</primary></indexterm>
1166 where <replaceable>192.168.10.40</replaceable> is either the IP address of the
1167 remote LMB or the network broadcast address of the remote segment.
1168 </para>
1169
1170 </sect2>
1171
1172 </sect1>
1173
1174 <sect1>
1175 <title>WINS: The Windows Internetworking Name Server</title>
1176
1177 <para>
1178 <indexterm><primary>WINS</primary></indexterm>
1179 <indexterm><primary>name_type</primary></indexterm>
1180 <indexterm><primary>LanManager-compatible</primary></indexterm>
1181 Use of WINS (either Samba WINS or MS Windows NT Server WINS) is highly
1182 recommended. Every NetBIOS machine registers its name together with a
1183 name_type value for each of several types of service it has available.
1184 It registers its name directly as a unique (the type 0x03) name.
1185 It also registers its name if it is running the LanManager-compatible
1186 server service (used to make shares and printers available to other users)
1187 by registering the server (the type 0x20) name.
1188 </para>
1189
1190 <para>
1191 <indexterm><primary>NetBIOS name length</primary></indexterm>
1192 <indexterm><primary>name_type</primary></indexterm>
1193 All NetBIOS names are up to 15 characters in length. The name_type variable
1194 is added to the end of the name, thus creating a 16 character name. Any
1195 name that is shorter than 15 characters is padded with spaces to the 15th
1196 character. Thus, all NetBIOS names are 16 characters long (including the
1197 name_type information).
1198 </para>
1199
1200 <para>
1201 <indexterm><primary>WINS</primary></indexterm>
1202 <indexterm><primary>registered</primary></indexterm>
1203 <indexterm><primary>NetLogon service</primary></indexterm>
1204 <indexterm><primary>lmhosts</primary></indexterm>
1205 WINS can store these 16-character names as they get registered. A client
1206 that wants to log onto the network can ask the WINS server for a list
1207 of all names that have registered the NetLogon service name_type. This saves
1208 broadcast traffic and greatly expedites logon processing. Since broadcast
1209 name resolution cannot be used across network segments, this type of
1210 information can only be provided via WINS or via a statically configured
1211 <filename>lmhosts</filename> file that must reside on all clients in the
1212 absence of WINS.
1213 </para>
1214
1215 <para>
1216 <indexterm><primary>synchronization</primary></indexterm>
1217 <indexterm><primary>LMB</primary></indexterm>
1218 <indexterm><primary>DMB</primary></indexterm>
1219 <indexterm><primary>WINS</primary></indexterm>
1220 <indexterm><primary>browse list</primary></indexterm>
1221 WINS also forces browse list synchronization by all LMBs. LMBs must synchronize their browse list with the
1222 DMB, and WINS helps the LMB to identify its DMB. By definition this will work only within a single workgroup.
1223 Note that the DMB has nothing to do with what is referred to as an MS Windows NT domain. The latter is a
1224 reference to a security environment, while the DMB refers to the master controller for browse list information
1225 only.
1226 </para>
1227
1228 <para>
1229 <indexterm><primary>WINS</primary></indexterm>
1230 <indexterm><primary>TCP/IP protocol stack</primary></indexterm>
1231 <indexterm><primary>WINS servers</primary></indexterm>
1232 <indexterm><primary>name-to-address</primary></indexterm>
1233 WINS will work correctly only if every client TCP/IP protocol stack
1234 is configured to use the WINS servers. Any client that is not
1235 configured to use the WINS server will continue to use only broadcast-based
1236 name registration, so WINS may never get to know about it. In any case,
1237 machines that have not registered with a WINS server will fail name-to-address
1238 lookup attempts by other clients and will therefore cause workstation access
1239 errors.
1240 </para>
1241
1242 <para>
1243 To configure Samba as a WINS server, just add
1244 <smbconfoption name="wins support">yes</smbconfoption> to the &smb.conf;
1245 file [global] section.
1246 </para>
1247
1248 <para>
1249 To configure Samba to register with a WINS server, just add <smbconfoption name="wins
1250 server">10.0.0.18</smbconfoption> to your &smb.conf; file <smbconfsection name="[global]"/> section.
1251 </para>
1252
1253 <important><para>
1254 Never use <smbconfoption name="wins support">yes</smbconfoption> together with <smbconfoption name="wins
1255 server">10.0.0.18</smbconfoption> particularly not using its own IP address. Specifying both will cause &nmbd;
1256 to refuse to start!
1257 </para></important>
1258
1259 <sect2>
1260 <title>WINS Server Configuration</title>
1261
1262 <para>
1263 <indexterm><primary>WINS</primary></indexterm>
1264 Either a Samba server or a Windows NT server machine may be set up
1265 as a WINS server. To configure a Samba server to be a WINS server, you must
1266 add to the &smb.conf; file on the selected Server the following line to
1267 the <smbconfsection name="[global]"/> section:
1268 </para>
1269
1270 <para>
1271 <smbconfblock>
1272 <smbconfoption name="wins support">yes</smbconfoption>
1273 </smbconfblock>
1274 </para>
1275
1276 <para>
1277 <indexterm><primary>Samba 1.9.17</primary></indexterm>
1278 Versions of Samba prior to 1.9.17 had this parameter default to
1279 yes. If you have any older versions of Samba on your network, it is
1280 strongly suggested you upgrade to a recent version, or at the very
1281 least set the parameter to <quote>no</quote> on all these machines.
1282 </para>
1283
1284 <para>
1285 Machines configured with <smbconfoption name="wins support">yes</smbconfoption> will keep a list of
1286 all NetBIOS names registered with them, acting as a DNS for NetBIOS names.
1287 </para>
1288
1289 <para>
1290 <indexterm><primary>only one WINS server</primary></indexterm>
1291 It is strongly recommended to set up only one WINS server. Do not set the <smbconfoption name="wins
1292 support">yes</smbconfoption> option on more than one Samba server on a network.
1293 </para>
1294
1295 <para>
1296 <indexterm><primary>replication</primary><secondary>WINS</secondary></indexterm>
1297 <indexterm><primary>Windows NT/200x</primary></indexterm>
1298 <indexterm><primary>WINS service</primary></indexterm>
1299 <indexterm><primary>replication protocols</primary></indexterm>
1300 <indexterm><primary>WINS server</primary></indexterm>
1301 To configure Windows NT/200x Server as a WINS server, install and configure the WINS service. See the Windows
1302 NT/200x documentation for details.  Windows NT/200x WINS servers can replicate to each other, allowing more
1303 than one to be set up in a complex subnet environment. Because Microsoft refuses to document the replication
1304 protocols, Samba cannot currently participate in these replications. It is possible that a Samba-to-Samba WINS
1305 replication protocol may be defined in the future, in which case more than one Samba machine could be set up
1306 as a WINS server.  Currently only one Samba server should have the <smbconfoption name="wins
1307 support">yes</smbconfoption> parameter set.
1308 </para>
1309
1310 <para>
1311 <indexterm><primary>WINS server</primary></indexterm>
1312 <indexterm><primary>Primary WINS Server</primary></indexterm>
1313 After the WINS server has been configured, you must ensure that all machines participating on the network are
1314 configured with the address of this WINS server. If your WINS server is a Samba machine, fill in the Samba
1315 machine IP address in the <guilabel>Primary WINS Server</guilabel> field of the <guilabel>Control
1316 Panel->Network->Protocols->TCP->WINS Server</guilabel> dialogs in Windows 9x/Me or Windows NT/200x. To tell a
1317 Samba server the IP address of the WINS server, add the following line to the <smbconfsection
1318 name="[global]"/> section of all &smb.conf; files:
1319 <smbconfblock>
1320 <smbconfoption name="wins server">&lt;name or IP address&gt;</smbconfoption>
1321 </smbconfblock>
1322 where &lt;name or IP address&gt; is either the DNS name of the WINS server
1323 machine or its IP address.
1324 </para>
1325
1326 <para>
1327 This line must not be set in the &smb.conf; file of the Samba
1328 server acting as the WINS server itself. If you set both the
1329 <smbconfoption name="wins support">yes</smbconfoption> option and the
1330 <smbconfoption name="wins server">&lt;name&gt;</smbconfoption> option then
1331 <command>nmbd</command> will fail to start.
1332 </para>
1333
1334 <para>
1335 <indexterm><primary>cross-subnet browsing</primary></indexterm>
1336 <indexterm><primary>Windows 9x/Me</primary></indexterm>
1337 <indexterm><primary>Windows NT/200x</primary></indexterm>
1338 <indexterm><primary>not part of domain</primary></indexterm>
1339 There are two possible scenarios for setting up cross-subnet browsing.
1340 The first details setting up cross-subnet browsing on a network containing
1341 Windows 9x/Me, Samba, and Windows NT/200x machines that are not configured as
1342 part of a Windows NT domain. The second details setting up cross-subnet
1343 browsing on networks that contain NT domains.
1344 </para>
1345
1346 </sect2>
1347
1348 <sect2>
1349 <title>WINS Replication</title>
1350
1351 <para>
1352 <indexterm><primary>replication</primary><secondary>WINS</secondary></indexterm>
1353 <indexterm><primary>WINS replication</primary></indexterm>
1354 Samba-3 does not support native WINS replication. There was an approach to implement it, called
1355 <filename>wrepld</filename>, but it was never ready for action and the development is now discontinued.
1356 </para>
1357 <para>
1358 Meanwhile, there is a project named <filename>samba4WINS</filename>, which makes it possible to
1359 run the Samba-4 WINS server parallel to Samba-3 since version 3.0.21. More information about
1360 <filename>samba4WINS</filename> are available at http://ftp.sernet.de/pub/samba4WINS.
1361
1362 </para>
1363
1364 </sect2>
1365 <sect2>
1366 <title>Static WINS Entries</title>
1367
1368 <para>
1369 <indexterm><primary>static WINS entries</primary></indexterm>
1370 <indexterm><primary>wins.dat</primary></indexterm>
1371 <indexterm><primary>/usr/local/samba/var/locks</primary></indexterm>
1372 <indexterm><primary>/var/run/samba</primary></indexterm>
1373 Adding static entries to your Samba WINS server is actually fairly easy.  All you have to do is add a line to
1374 <filename>wins.dat</filename>, typically located in <filename
1375 class="directory">/usr/local/samba/var/locks</filename> or <filename>/var/run/samba</filename>.
1376 </para>
1377
1378 <para>
1379 Entries in <filename>wins.dat</filename> take the form of:
1380 <programlisting>
1381 "NAME#TYPE" TTL ADDRESS+ FLAGS
1382 </programlisting>
1383 <indexterm><primary>TTL</primary></indexterm>
1384 <indexterm><primary>time-to-live</primary><see>TTL</see></indexterm>
1385 where NAME is the NetBIOS name, TYPE is the NetBIOS type, TTL is the time-to-live as an absolute time in
1386 seconds, ADDRESS+ is one or more addresses corresponding to the registration, and FLAGS are the NetBIOS flags
1387 for the registration.
1388 </para>
1389
1390 <note><para>
1391 A change that has been made to the <filename>wins.dat</filename> will not take effect until &nmbd; has been
1392 restarted. It should be noted that since the <filename>wins.dat</filename> file changes dynamically, &nmbd;
1393 should be stopped before editting this file. Do not forget to restart &nmbd; when this file has been editted.
1394 </para></note>
1395
1396 <para>
1397 A typical dynamic entry looks like this:
1398 <programlisting>
1399 "MADMAN#03" 1155298378 192.168.1.2 66R
1400 </programlisting>
1401 To make a NetBIOS name static (permanent), simply set the TTL to 0, like this:
1402 <programlisting>
1403 "MADMAN#03" 0 192.168.1.2 66R
1404 </programlisting>
1405 </para>
1406
1407 <para>
1408 <indexterm><primary>NetBIOS flags</primary></indexterm>
1409 <indexterm><primary>Broadcast node</primary></indexterm>
1410 <indexterm><primary>Peer node</primary></indexterm>
1411 <indexterm><primary>Meta node</primary></indexterm>
1412 <indexterm><primary>Hybrid node</primary></indexterm>
1413 <indexterm><primary>Permanent name</primary></indexterm>
1414 <indexterm><primary>nameserv.h</primary></indexterm>
1415 The NetBIOS flags may be interpreted as additive hexadecimal values: 00 - Broadcast node registration, 20 -
1416 Peer node registration, 40 - Meta node registration, 60 - Hybrid node registration, 02 - Permanent name, 04 -
1417 Active name, 80 - Group name. The 'R' indicates this is a registration record. Thus 66R means: Hybrid node
1418 active and permanent NetBIOS name. These values may be found in the <filename>nameserv.h</filename> header
1419 file from the Samba source code repository. These are the values for the NB flags.
1420 </para>
1421
1422 <para>
1423 <indexterm><primary>WINS replication</primary></indexterm>
1424 Though this method works with early Samba-3 versions, there is a possibility that it may change in future
1425 versions if WINS replication is added.
1426 </para>
1427
1428 </sect2>
1429 </sect1>
1430
1431 <sect1>
1432 <title>Helpful Hints</title>
1433
1434 <para>
1435 The following hints should be carefully considered because they are stumbling points
1436 for many new network administrators.
1437 </para>
1438
1439 <sect2>
1440 <title>Windows Networking Protocols</title>
1441
1442 <para>
1443 <indexterm><primary>browsing problems</primary></indexterm>
1444 <indexterm><primary>more than one protocol</primary></indexterm>
1445 A common cause of browsing problems results from the installation of more than one protocol on an MS Windows
1446 machine.
1447 </para>
1448
1449 <warning><para>
1450 Do not use more than one protocol on MS Windows clients.
1451 </para></warning>
1452
1453 <para>
1454 <indexterm><primary>LMB</primary></indexterm>
1455 <indexterm><primary>DMB</primary></indexterm>
1456 Every NetBIOS machine takes part in a process of electing the LMB (and DMB)
1457 every 15 minutes. A set of election criteria is used to determine the order
1458 of precedence for winning this election process. A machine running Samba or
1459 Windows NT will be biased, so the most suitable machine will predictably
1460 win and thus retain its role.
1461 </para>
1462
1463 <para>
1464 <indexterm><primary>NetBIOS network interface</primary></indexterm>
1465 <indexterm><primary>TCP/IP</primary></indexterm>
1466 <indexterm><primary>IPX</primary></indexterm>
1467 <indexterm><primary>LMB</primary></indexterm>
1468 <indexterm><primary>Windows 9x/Me</primary></indexterm>
1469 <indexterm><primary>TCP/IP-only</primary></indexterm>
1470 The election process is <emphasis>fought out, so to speak</emphasis> over every NetBIOS network interface. In
1471 the case of a Windows 9x/Me machine that has both TCP/IP and IPX installed and has NetBIOS enabled over both
1472 protocols, the election will be decided over both protocols. As often happens, if the Windows 9x/Me machine is
1473 the only one with both protocols, then the LMB may be won on the NetBIOS interface over the IPX protocol.
1474 Samba will then lose the LMB role because Windows 9x/Me will insist it knows who the LMB is. Samba will then
1475 cease to function as an LMB, and browse list operation on all TCP/IP-only machines will therefore fail.
1476 </para>
1477
1478 <para>
1479 <indexterm><primary>Windows 9x/Me</primary></indexterm>
1480 <indexterm><primary>extended protocol</primary></indexterm>
1481 Windows 95, 98, 98se, and Me are referred to generically as Windows 9x/Me.  The Windows NT4, 200x, and XP use
1482 common protocols. These are roughly referred to as the Windows NT family, but it should be recognized that
1483 2000 and XP/2003 introduce new protocol extensions that cause them to behave differently from MS Windows NT4.
1484 Generally, where a server does not support the newer or extended protocol, these will fall back to the NT4
1485 protocols.
1486 </para>
1487
1488 <para>
1489 The safest rule of all to follow is: Use only one protocol!
1490 </para>
1491
1492 </sect2>
1493
1494 <sect2>
1495 <title>Name Resolution Order</title>
1496
1497 <para>
1498 <indexterm><primary>NetBIOS names</primary></indexterm>
1499 <indexterm><primary>name_type</primary></indexterm>
1500 Resolution of NetBIOS names to IP addresses can take place using a number
1501 of methods. The only ones that can provide NetBIOS name_type information
1502 are:
1503 </para>
1504
1505 <itemizedlist>
1506         <listitem><para>WINS &smbmdash; the best tool.</para></listitem>
1507         <listitem><para>LMHOSTS &smbmdash; static and hard to maintain.</para></listitem>
1508         <listitem><para>Broadcast &smbmdash; uses UDP and cannot resolve names across remote segments.</para></listitem>
1509 </itemizedlist>
1510
1511 <para>
1512 Alternative means of name resolution include:
1513 </para>
1514 <itemizedlist>
1515 <listitem><para>Static <filename>/etc/hosts</filename> &smbmdash;  hard to maintain and lacks name_type info.</para></listitem>
1516 <listitem><para>DNS &smbmdash; is a good choice but lacks essential NetBIOS name_type information.</para></listitem>
1517 </itemizedlist>
1518
1519 <para>
1520 <indexterm><primary>restrict DNS</primary></indexterm>
1521 <indexterm><primary>name resolve order</primary></indexterm>
1522 Many sites want to restrict DNS lookups and avoid broadcast name
1523 resolution traffic. The <parameter>name resolve order</parameter> parameter is of great help here.
1524 The syntax of the <parameter>name resolve order</parameter> parameter is:
1525 <smbconfblock>
1526 <smbconfoption name="name resolve order">wins lmhosts bcast host</smbconfoption>
1527 </smbconfblock>
1528 <emphasis>or</emphasis>
1529 <smbconfblock>
1530 <smbconfoption name="name resolve order">wins lmhosts   (eliminates bcast and host)</smbconfoption>
1531 </smbconfblock>
1532 The default is:
1533 <smbconfblock>
1534 <smbconfoption name="name resolve order">host lmhost wins bcast</smbconfoption>,
1535 </smbconfblock>
1536 <indexterm><primary>gethostbyname() function call</primary></indexterm>
1537 where <quote>host</quote> refers to the native methods used by the UNIX system to implement the
1538 gethostbyname() function call. This is normally controlled by <filename>/etc/host.conf</filename>,
1539 <filename>/etc/nsswitch.conf</filename> and <filename>/etc/resolv.conf</filename>.
1540 </para>
1541 </sect2>
1542 </sect1>
1543
1544 <sect1>
1545 <title>Technical Overview of Browsing</title>
1546
1547 <para>
1548 <indexterm><primary>SMB</primary></indexterm>
1549 SMB networking provides a mechanism by which clients can access a list
1550 of machines in a network called <smbconfoption name="browse list"/>. This list
1551 contains machines that are ready to offer file and/or print services
1552 to other machines within the network. It therefore does not include
1553 machines that aren't currently able to do server tasks. The browse
1554 list is heavily used by all SMB clients. Configuration of SMB
1555 browsing has been problematic for some Samba users, hence this
1556 document.
1557 </para>
1558
1559 <para>
1560 <indexterm><primary>NetBIOS over TCP/IP</primary></indexterm>
1561 <indexterm><primary>DNS/LDAP/ADS</primary></indexterm>
1562 <indexterm><primary>name resolution</primary></indexterm>
1563 MS Windows 2000 and later versions, as with Samba-3 and later versions, can be
1564 configured to not use NetBIOS over TCP/IP. When configured this way,
1565 it is imperative that name resolution (using DNS/LDAP/ADS) be correctly
1566 configured and operative. Browsing will not work if name resolution
1567 from SMB machine names to IP addresses does not function correctly.
1568 </para>
1569
1570 <para>
1571 <indexterm><primary>NetBIOS</primary></indexterm>
1572 <indexterm><primary>WINS</primary></indexterm>
1573 Where NetBIOS over TCP/IP is enabled, use of a WINS server is highly
1574 recommended to aid the resolution of NetBIOS (SMB) names to IP addresses.
1575 WINS allows remote segment clients to obtain NetBIOS name_type information
1576 that cannot be provided by any other means of name resolution.
1577 </para>
1578
1579 <sect2>
1580 <title>Browsing Support in Samba</title>
1581
1582 <para>
1583 <indexterm><primary>browsing</primary></indexterm>
1584 <indexterm><primary>LMB</primary></indexterm>
1585 <indexterm><primary>domain logons</primary></indexterm>
1586 <indexterm><primary>scripts</primary></indexterm>
1587 Samba facilitates browsing. The browsing is supported by &nmbd;
1588 and is also controlled by options in the &smb.conf; file.
1589 Samba can act as an LMB for a workgroup, and the ability
1590 to support domain logons and scripts is now available.
1591 </para>
1592
1593 <para>
1594 <indexterm><primary>DMB for a workgroup</primary></indexterm>
1595 <indexterm><primary>LMB</primary></indexterm>
1596 <indexterm><primary>WINS</primary></indexterm>
1597 Samba can also act as a DMB for a workgroup. This
1598 means that it will collate lists from LMBs into a
1599 wide-area network server list. In order for browse clients to
1600 resolve the names they may find in this list, it is recommended that
1601 both Samba and your clients use a WINS server.
1602 </para>
1603
1604 <para>
1605 <indexterm><primary>domain master</primary></indexterm>
1606 Do not set Samba to be the domain master for a workgroup that has the same
1607 name as an NT Domain. On each wide-area network, you must only ever have one
1608 DMB per workgroup, regardless of whether it is NT, Samba,
1609 or any other type of domain master that is providing this service.
1610 </para>
1611
1612 <note><para>
1613 <indexterm><primary>nmbd</primary></indexterm>
1614 <indexterm><primary>WINS server</primary></indexterm>
1615 <command>nmbd</command> can be configured as a WINS server, but it is not
1616 necessary to specifically use Samba as your WINS server. MS Windows
1617 NT4, Server or Advanced Server 200x can be configured as
1618 your WINS server. In a mixed NT/200x server and Samba environment on
1619 a WAN, it is recommended that you use the Microsoft
1620 WINS server capabilities. In a Samba-only environment, it is
1621 recommended that you use one and only one Samba server as the WINS server.
1622 </para></note>
1623
1624 <para>
1625 <indexterm><primary>nmbd</primary></indexterm>
1626 To get browsing to work, you need to run <command>nmbd</command> as usual, but must
1627 use the <smbconfoption name="workgroup"/> option in &smb.conf;
1628 to control what workgroup Samba becomes a part of.
1629 </para>
1630
1631 <para>
1632 <indexterm><primary>browsing another subnet</primary></indexterm>
1633 Samba also has a useful option for a Samba server to offer itself for browsing on another subnet. It is
1634 recommended that this option is used only for <quote>unusual</quote> purposes: announcements over the
1635 Internet, for example. See <smbconfoption name="remote announce"/> in the &smb.conf; man page.
1636 </para>
1637 </sect2>
1638
1639 <sect2>
1640 <title>Problem Resolution</title>
1641
1642 <para>
1643 <indexterm><primary>log.nmbd</primary></indexterm>
1644 <indexterm><primary>browse.dat</primary></indexterm>
1645 If something does not work, the <filename>log.nmbd</filename> file will help
1646 to track down the problem. Try a <smbconfoption name="log level"></smbconfoption> of 2 or 3 for finding
1647 problems. Also note that the current browse list usually gets stored
1648 in text form in a file called <filename>browse.dat</filename>.
1649 </para>
1650
1651 <para>
1652 <indexterm><primary>\\SERVER</primary></indexterm>
1653 <indexterm><primary>filemanager</primary></indexterm>
1654 If it does not work, you should still be able to
1655 type the server name as <filename>\\SERVER</filename> in <command>filemanager</command>, then
1656 press enter, and <command>filemanager</command> should display the list of available shares.
1657 </para>
1658
1659 <para>
1660 <indexterm><primary>IPC$</primary></indexterm>
1661 <indexterm><primary>guest account</primary></indexterm>
1662 Some people find browsing fails because they do not have the global
1663 <smbconfoption name="guest account"/> set to a valid account. Remember that the
1664 IPC$ connection that lists the shares is done as guest and so you must have a valid guest account.
1665 </para>
1666
1667 <note><para>
1668 <indexterm><primary>IPC$</primary></indexterm>
1669 <indexterm><primary>Windows Explorer</primary></indexterm>
1670 <indexterm><primary>browse resources</primary></indexterm>
1671 <indexterm><primary>Network Neighborhood</primary></indexterm>
1672 <indexterm><primary>My Network Places</primary></indexterm>
1673 The <literal>IPC$</literal> share is used by all SMB/CIFS clients to obtain the list of resources that is
1674 available on the server. This is the source of the list of shares and printers when browsing an SMB/CIFS
1675 server (also Windows machines) using the Windows Explorer to browse resources through the Windows Network
1676 Neighborhood (also called My Network Places) through to a Windows server. At this point, the client has opened
1677 a connection to the <literal>\\server\IPC4</literal> resource.  Clicking on a share will then open up a
1678 connection to the <literal>\\server\share</literal>.
1679 </para></note>
1680
1681 <para>
1682 <indexterm><primary>guest account</primary></indexterm>
1683 <indexterm><primary>anonymous access</primary></indexterm>
1684 <indexterm><primary>IPC$</primary></indexterm>
1685 <indexterm><primary>browse server resources</primary></indexterm>
1686 MS Windows 2000 and later (as with Samba) can be configured to disallow
1687 anonymous (i.e., guest account) access to the IPC$ share. In that case, the
1688 MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the
1689 name of the currently logged-in user to query the IPC$ share. MS Windows
1690 9x/Me clients are not able to do this and thus will not be able to browse
1691 server resources.
1692 </para>
1693
1694 <para>
1695 <indexterm><primary>broadcast address</primary></indexterm>
1696 The other big problem people have is that their broadcast address,
1697 netmask, or IP address is wrong (specified with the <smbconfoption name="interfaces"></smbconfoption> option
1698 in &smb.conf;)
1699 </para>
1700 </sect2>
1701
1702 <sect2>
1703 <title>Cross-Subnet Browsing</title>
1704
1705 <para>
1706 <indexterm><primary>replication</primary><secondary>browse lists</secondary></indexterm>
1707 <indexterm><primary>browse across subnet</primary></indexterm>
1708 Since the release of Samba 1.9.17 (alpha1), Samba has supported the replication of browse lists across subnet
1709 boundaries. This section describes how to set this feature up in different settings.
1710 </para>
1711
1712 <para>
1713 <indexterm><primary>browse lists</primary></indexterm>
1714 <indexterm><primary>broadcast traffic</primary></indexterm>
1715 <indexterm><primary>UDP</primary></indexterm>
1716 <indexterm><primary>WINS</primary></indexterm>
1717 <indexterm><primary>remote announce</primary></indexterm>
1718 <indexterm><primary>remote browse sync</primary></indexterm>
1719 To see browse lists that span TCP/IP subnets (i.e., networks separated by routers that do not pass broadcast
1720 traffic), you must set up at least one WINS server. The WINS server acts as a DNS for NetBIOS names. This will
1721 allow NetBIOS name-to-IP address translation to be completed by a direct query of the WINS server. This is
1722 done via a directed UDP packet on port 137 to the WINS server machine. The WINS server avoids the necessity of
1723 default NetBIOS name-to-IP address translation, which is done using UDP broadcasts from the querying machine.
1724 This means that machines on one subnet will not be able to resolve the names of machines on another subnet
1725 without using a WINS server. The Samba hacks, <parameter>remote browse sync</parameter>, and <parameter>remote
1726 announce</parameter> are designed to get around the natural limitations that prevent UDP broadcast
1727 propagation. The hacks are not a universal solution and they should not be used in place of WINS, they are
1728 considered last resort methods.
1729 </para>
1730
1731 <para>
1732 <indexterm><primary>DHCP</primary></indexterm>
1733 <indexterm><primary>browsing across subnets</primary></indexterm>
1734 <indexterm><primary>WINS</primary></indexterm>
1735 <indexterm><primary>Network settings</primary></indexterm>
1736 Remember, for browsing across subnets to work correctly, all machines, be they Windows 95, Windows NT, or
1737 Samba servers, must have the IP address of a WINS server given to them by a DHCP server or by manual
1738 configuration: for Windows 9x/Me and Windows NT/200x/XP, this is in the TCP/IP Properties, under Network
1739 settings; for Samba, this is in the &smb.conf; file.
1740 </para>
1741
1742 <para>
1743 <indexterm><primary>NetBIOS over TCP/IP</primary></indexterm>
1744 <indexterm><primary>ADS</primary></indexterm>
1745 <indexterm><primary>DNS</primary></indexterm>
1746 It is possible to operate Samba-3 without NetBIOS over TCP/IP. If you do this, be warned that if used outside
1747 of MS ADS, this will forgo network browsing support. ADS permits network browsing support through DNS,
1748 providing appropriate DNS records are inserted for all Samba servers.
1749 </para>
1750
1751 <sect3>
1752 <title>Behavior of Cross-Subnet Browsing</title>
1753
1754 <para>
1755 <indexterm><primary>cross-subnet browsing</primary></indexterm>
1756 <indexterm><primary>complicated</primary></indexterm>
1757 Cross-subnet browsing is a complicated dance, containing multiple moving parts. It has taken Microsoft several
1758 years to get the code that correctly achieves this, and Samba lags behind in some areas.  Samba is capable of
1759 cross-subnet browsing when configured correctly.
1760 </para>
1761
1762 <para>
1763 Consider a network set up as in <link linkend="browsing1">Cross-Subnet Browsing Example</link>.
1764 </para>
1765
1766 <figure id="browsing1">
1767         <title>Cross-Subnet Browsing Example.</title>
1768         <imagefile scale="40">browsing1</imagefile>
1769 </figure>
1770
1771 <para>
1772 <indexterm><primary>broadcasts</primary></indexterm>
1773 <indexterm><primary>DMB</primary></indexterm>
1774 <indexterm><primary>WINS</primary></indexterm>
1775 This consists of three subnets (1, 2, 3) connected by two routers (R1, R2), which do not pass broadcasts.
1776 Subnet 1 has five machines on it, subnet 2 has four machines, and subnet 3 has four machines. Assume for the
1777 moment that all machines are configured to be in the same workgroup (for simplicity's sake). Machine N1_C on
1778 subnet 1 is configured as the DMB (i.e., it will collate the browse lists for the workgroup). Machine N2_D is
1779 configured as a WINS server, and all the other machines are configured to register their NetBIOS names with
1780 it.
1781 </para>
1782
1783 <para>
1784 <indexterm><primary>master browsers</primary></indexterm>
1785 <indexterm><primary>LMB</primary></indexterm>
1786 <indexterm><primary>DMB</primary></indexterm>
1787 As these machines are booted up, elections for master browsers
1788 take place on each of the three subnets. Assume that machine
1789 N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on
1790 subnet 3. These machines are known as LMBs for
1791 their particular subnet. N1_C has an advantage in winning as the
1792 LMB on subnet 1 because it is set up as DMB.
1793 </para>
1794
1795 <para>
1796 <indexterm><primary>LMB</primary></indexterm>
1797 <indexterm><primary>browse list</primary></indexterm>
1798 On each of the three networks, machines that are configured to offer sharing services will broadcast that they
1799 are offering these services. The LMB on each subnet will receive these broadcasts and keep a record of the
1800 fact that the machine is offering a service. This list of records is the basis of the browse list. For this
1801 case, assume that all the machines are configured to offer services, so all machines will be on the browse
1802 list.
1803 </para>
1804
1805 <para>
1806 <indexterm><primary>LMB</primary></indexterm>
1807 <indexterm><primary>authoritative</primary></indexterm>
1808 <indexterm><primary>verifiable</primary></indexterm>
1809 <indexterm><primary>trusted</primary></indexterm>
1810 <indexterm><primary>non-authoritative</primary></indexterm>
1811 For each network, the LMB on that network is
1812 considered <emphasis>authoritative</emphasis> for all the names it receives via
1813 local broadcast. This is because a machine seen by the LMB
1814 via a local broadcast must be on the same network as the
1815 Local Master Browser and thus is a <emphasis>trusted</emphasis>
1816 and <emphasis>verifiable</emphasis> resource. Machines on other networks that
1817 the LMBs learn about when collating their
1818 browse lists have not been directly seen. These records are
1819 called <emphasis>non-authoritative.</emphasis>
1820 </para>
1821
1822 <para>
1823 <indexterm><primary>network neighborhood</primary></indexterm>
1824 At this point the browse lists appear as shown in <link linkend="browsubnet">Browse Subnet Example 1</link>
1825 (these are the machines you would see in your network neighborhood if you looked in it on a particular network
1826 right now).
1827 </para>
1828
1829 <para>
1830 <table frame="all" id="browsubnet">
1831         <title>Browse Subnet Example 1</title>
1832         <tgroup align="left" cols="3">
1833         <thead>
1834                 <row><entry>Subnet</entry><entry>Browse Master</entry><entry>List</entry></row>
1835         </thead>
1836
1837         <tbody>
1838                 <row><entry>Subnet1</entry><entry>N1_C</entry><entry>N1_A, N1_B, N1_C, N1_D, N1_E</entry></row>
1839                 <row><entry>Subnet2</entry><entry>N2_B</entry><entry>N2_A, N2_B, N2_C, N2_D</entry></row>
1840                 <row><entry>Subnet3</entry><entry>N3_D</entry><entry>N3_A, N3_B, N3_C, N3_D</entry></row>
1841         </tbody>
1842         </tgroup>
1843 </table>
1844 </para>
1845
1846 <para>
1847 At this point all the subnets are separate, and no machine is seen across any of the subnets.
1848 </para>
1849
1850 <para>
1851 <indexterm><primary>DMB</primary></indexterm>
1852 <indexterm><primary>LMB</primary></indexterm>
1853 <indexterm><primary>synchronize</primary></indexterm>
1854 <indexterm><primary>WINS</primary></indexterm>
1855 Now examine subnet 2 in <link linkend="brsbex">Browse Subnet Example 2</link>.  As soon as N2_B has become the
1856 LMB, it looks for a DMB with which to synchronize its browse list. It does this by querying the WINS server
1857 (N2_D) for the IP address associated with the NetBIOS name WORKGROUP&lt;1B&gt;. This name was registered by
1858 the DMB (N1_C) with the WINS server as soon as it was started.
1859 </para>
1860
1861 <para>
1862 <indexterm><primary>MasterAnnouncement</primary></indexterm>
1863 <indexterm><primary>NetServerEnum2</primary></indexterm>
1864 <indexterm><primary>synchronization</primary></indexterm>
1865 <indexterm><primary>browse lists</primary></indexterm>
1866 Once N2_B knows the address of the DMB, it tells the DMB that it is the LMB
1867 for subnet 2 by sending the DMB a
1868 <emphasis>MasterAnnouncement</emphasis> packet to UDP port 138.  It then
1869 synchronizes with the DMB by
1870 doing a <emphasis>NetServerEnum2</emphasis> call. This tells the DMB to
1871 send the sender all the server names it knows
1872 about. Once the DMB receives the <emphasis>MasterAnnouncement</emphasis> packet, it schedules a
1873 synchronization request to the sender of that packet. After both synchronizations are complete, the browse
1874 lists look like those in <link linkend="brsbex">Browse Subnet Example 2</link>
1875 </para>
1876
1877 <table frame="all" id="brsbex">
1878         <title>Browse Subnet Example 2</title>
1879         <tgroup cols="3">
1880                 <colspec align="left"/>
1881                 <colspec align="left"/>
1882                 <colspec align="justify" colwidth="1*"/>
1883         <thead>
1884                 <row><entry>Subnet</entry><entry>Browse Master</entry><entry>List</entry></row>
1885         </thead>
1886
1887         <tbody>
1888                 <row><entry>Subnet1</entry><entry>N1_C</entry><entry>N1_A, N1_B, N1_C, N1_D, N1_E,
1889 N2_A(*), N2_B(*), N2_C(*), N2_D(*)</entry></row>
1890                 <row><entry>Subnet2</entry><entry>N2_B</entry><entry>N2_A, N2_B, N2_C, N2_D, N1_A(*),
1891 N1_B(*), N1_C(*), N1_D(*), N1_E(*)</entry></row>
1892                 <row><entry>Subnet3</entry><entry>N3_D</entry><entry>N3_A, N3_B, N3_C, N3_D</entry></row>
1893         </tbody>
1894         </tgroup>
1895 </table>
1896
1897 <para>
1898 <indexterm><primary>non-authoritative</primary></indexterm>
1899 Servers with an (*) after them are non-authoritative names.
1900 </para>
1901
1902 <para>
1903 <indexterm><primary>Network Neighborhood</primary></indexterm>
1904 At this point users looking in their Network Neighborhood on subnets 1 or 2 will see all the servers on both;
1905 users on subnet 3 will still see only the servers on their own subnet.
1906 </para>
1907
1908 <para>
1909 <indexterm><primary>DMB</primary></indexterm>
1910 The same sequence of events that occurred for N2_B now occurs for the LMB on subnet 3 (N3_D). When it
1911 synchronizes browse lists with the DMB (N1_A) it gets both the server entries on subnet 1 and those on subnet
1912 2. After N3_D has synchronized with N1_C and vica versa, the browse lists will appear as shown in <link
1913 linkend="brsex2">Browse Subnet Example 3</link>
1914 </para>
1915
1916 <table frame="all" id="brsex2">
1917         <title>Browse Subnet Example 3</title>
1918         <tgroup cols="3" align="left">
1919                 <colspec align="left"/>
1920                 <colspec align="left"/>
1921                 <colspec align="justify" colwidth="1*"/>
1922
1923         <thead>
1924                 <row><entry>Subnet</entry><entry>Browse Master</entry><entry>List</entry></row>
1925         </thead>
1926
1927         <tbody>
1928                 <row><entry>Subnet1</entry><entry>N1_C</entry><entry>N1_A, N1_B, N1_C, N1_D, N1_E,
1929 N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)</entry></row>
1930                 <row><entry>Subnet2</entry><entry>N2_B</entry><entry>N2_A, N2_B, N2_C, N2_D, N1_A(*),
1931 N1_B(*), N1_C(*), N1_D(*), N1_E(*)</entry></row>
1932                 <row><entry>Subnet3</entry><entry>N3_D</entry><entry>N3_A, N3_B, N3_C, N3_D, N1_A(*),
1933 N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*)</entry></row>
1934         </tbody>
1935         </tgroup>
1936 </table>
1937
1938 <para>
1939 Servers with an (*) after them are non-authoritative names.
1940 </para>
1941
1942 <para>
1943 At this point, users looking in their Network Neighborhood on
1944 subnets 1 or 3 will see all the servers on all subnets, while users on
1945 subnet 2 will still see only the servers on subnets 1 and 2, but not 3.
1946 </para>
1947
1948 <para>
1949 <indexterm><primary>LMB</primary></indexterm>
1950 <indexterm><primary>DMB</primary></indexterm>
1951 <indexterm><primary>browse lists</primary></indexterm>
1952 Finally, the LMB for subnet 2 (N2_B) will sync again
1953 with the DMB (N1_C) and will receive the missing
1954 server entries. Finally, as when a steady state (if no machines
1955 are removed or shut off) has been achieved, the browse lists will appear
1956 as shown in <link linkend="brsex3">Browse Subnet Example 4</link>.
1957 </para>
1958
1959 <table frame="all" id="brsex3">
1960         <title>Browse Subnet Example 4</title>
1961         <tgroup cols="3" align="left">
1962                 <colspec align="left"/>
1963                 <colspec align="left"/>
1964                 <colspec align="justify" colwidth="1*"/>
1965
1966         <thead>
1967                 <row><entry>Subnet</entry><entry>Browse Master</entry><entry>List</entry></row>
1968         </thead>
1969
1970         <tbody>
1971                 <row><entry>Subnet1</entry><entry>N1_C</entry><entry>N1_A, N1_B, N1_C, N1_D, N1_E,
1972 N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*),
1973 N3_C(*), N3_D(*)</entry></row>
1974                 <row><entry>Subnet2</entry><entry>N2_B</entry><entry>N2_A, N2_B, N2_C, N2_D, N1_A(*),
1975 N1_B(*), N1_C(*), N1_D(*), N1_E(*), N3_A(*), N3_B(*),
1976 N3_C(*), N3_D(*)</entry></row>
1977                 <row><entry>Subnet3</entry><entry>N3_D</entry><entry>N3_A, N3_B, N3_C, N3_D, N1_A(*),
1978 N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*),
1979 N2_C(*), N2_D(*)</entry></row>
1980         </tbody>
1981         </tgroup>
1982 </table>
1983
1984 <para>
1985 Servers with an (*) after them are non-authoritative names.
1986 </para>
1987
1988 <para>
1989 Synchronizations between the DMB and LMBs
1990 will continue to occur, but this should remain a
1991 steady-state operation.
1992 </para>
1993
1994 <para>
1995 If either router R1 or R2 fails, the following will occur:
1996 </para>
1997
1998 <orderedlist>
1999 <listitem>
2000         <para>
2001 <indexterm><primary>Network Neighborhood</primary></indexterm>
2002         Names of computers on each side of the inaccessible network fragments
2003         will be maintained for as long as 36 minutes in the Network Neighborhood
2004         lists.
2005         </para>
2006 </listitem>
2007
2008 <listitem>
2009         <para>
2010         Attempts to connect to these inaccessible computers will fail, but the
2011         names will not be removed from the Network Neighborhood lists.
2012         </para>
2013 </listitem>
2014
2015 <listitem>
2016         <para>
2017 <indexterm><primary>WINS</primary></indexterm>
2018 <indexterm><primary>NetBIOS name resolution</primary></indexterm>
2019 <indexterm><primary>DNS server</primary></indexterm>
2020         If one of the fragments is cut off from the WINS server, it will only
2021         be able to access servers on its local subnet using subnet-isolated
2022         broadcast NetBIOS name resolution. The effect is similar to that of
2023         losing access to a DNS server.
2024         </para>
2025 </listitem>
2026 </orderedlist>
2027 </sect3>
2028 </sect2>
2029 </sect1>
2030
2031 <sect1>
2032 <title>Common Errors</title>
2033
2034 <para>
2035 <indexterm><primary>browsing problems</primary></indexterm>
2036 <indexterm><primary>name resolution</primary></indexterm>
2037 Many questions are asked on the mailing lists regarding browsing. The majority of browsing
2038 problems originate from incorrect configuration of NetBIOS name resolution. Some are of
2039 particular note.
2040 </para>
2041
2042 <sect2>
2043 <title>Flushing the Samba NetBIOS Name Cache</title>
2044
2045 <para>
2046 How Can One Flush the Samba NetBIOS Name Cache without Restarting Samba?
2047 </para>
2048
2049 <para>
2050 <indexterm><primary>flush name cache</primary></indexterm>
2051 <indexterm><primary>nmbd</primary></indexterm>
2052 <indexterm><primary>NetBIOS name cache</primary></indexterm>
2053 <indexterm><primary>rogue machine</primary></indexterm>
2054 Samba's <command>nmbd</command> process controls all browse list handling. Under normal circumstances it is
2055 safe to restart <command>nmbd</command>. This will effectively flush the Samba NetBIOS name cache and cause it
2056 to be rebuilt. This does not make certain that a rogue machine name will not reappear
2057 in the browse list. When <command>nmbd</command> is taken out of service, another machine on the network will
2058 become the browse master. This new list may still have the rogue entry in it. If you really
2059 want to clear a rogue machine from the list, every machine on the network must be
2060 shut down and restarted after all machines are down. Failing a complete restart, the only
2061 other thing you can do is wait until the entry times out and is then flushed from the list.
2062 This may take a long time on some networks (perhaps months).
2063 </para>
2064
2065 </sect2>
2066
2067 <sect2>
2068         <title>Server Resources Cannot Be Listed</title>
2069
2070 <para><quote>My Client Reports "<quote>This server is not configured to list shared resources."</quote></quote></para>
2071
2072
2073 <para>
2074 Your guest account is probably invalid for some reason. Samba uses the
2075 guest account for browsing in <command>smbd</command>. Check that your guest account is
2076 valid.
2077 </para>
2078
2079 <para>Also see <smbconfoption name="guest account"/> in the &smb.conf; man page.</para>
2080
2081 </sect2>
2082
2083 <sect2>
2084         <title>I Get an "<errorname>Unable to browse the network</errorname>" Error</title>
2085
2086         <para>This error can have multiple causes:
2087 <indexterm><primary>browsing problems</primary></indexterm>
2088         </para>
2089
2090         <itemizedlist>
2091                 <listitem><para>There is no LMB. Configure &nmbd;
2092                         or any other machine to serve as LMB.</para></listitem>
2093                 <listitem><para>You cannot log onto the machine that is the LMB.
2094                         Can you log on to it as a guest user? </para></listitem>
2095                 <listitem><para>There is no IP connectivity to the LMB.
2096                         Can you reach it by broadcast?</para></listitem>
2097 </itemizedlist>
2098 </sect2>
2099
2100 <sect2>
2101 <title>Browsing of Shares and Directories is Very Slow</title>
2102
2103 <para><quote>
2104 <indexterm><primary>slow browsing</primary></indexterm>
2105 There are only two machines on a test network. One is a Samba server, the other a Windows XP machine.
2106 Authentication and logons work perfectly, but when I try to explore shares on the Samba server, the
2107 Windows XP client becomes unresponsive. Sometimes it does not respond for some minutes. Eventually,
2108 Windows Explorer will respond and displays files and directories without problem.
2109 </quote>
2110 </para>
2111
2112 <para><quote>
2113 <indexterm><primary>cmd</primary></indexterm>
2114 But, the share is immediately available from a command shell (<command>cmd</command>, followed by
2115 exploration with DOS command. Is this a Samba problem, or is it a Windows problem? How can I solve this?
2116 </quote></para>
2117
2118 <para>
2119 Here are a few possibilities:
2120 </para>
2121
2122 <variablelist>
2123         <varlistentry>
2124                 <term>Bad Networking Hardware</term>
2125                 <listitem><para>
2126 <indexterm><primary>bad hardware</primary></indexterm>
2127 <indexterm><primary>WebClient</primary></indexterm>
2128 <indexterm><primary>defective hardware</primary></indexterm>
2129 <indexterm><primary>Bad networking hardware</primary></indexterm>
2130 <indexterm><primary>data corruption</primary></indexterm>
2131                 Most common defective hardware problems center around low cost or defective hubs, routers,
2132                 network interface controllers (NICs), and bad wiring. If one piece of hardware is defective,
2133                 the whole network may suffer. Bad networking hardware can cause data corruption. Most bad
2134                 networking hardware problems are accompanied by an increase in apparent network traffic,
2135                 but not all.
2136                 </para></listitem>
2137         </varlistentry>
2138
2139         <varlistentry>
2140                 <term>The Windows XP WebClient</term>
2141                 <listitem><para>
2142 <indexterm><primary>network browsing problems</primary></indexterm>
2143                 A number of sites have reported similar slow network browsing problems and found that when
2144                 the WebClient service is turned off, the problem disappears. This is certainly something
2145                 that should be explored because it is a simple solution &smbmdash; if it works.
2146                 </para></listitem>
2147         </varlistentry>
2148
2149         <varlistentry>
2150                 <term>Inconsistent WINS Configuration</term>
2151                 <listitem><para>
2152 <indexterm><primary>WINS Configuration</primary></indexterm>
2153 <indexterm><primary>WINS server</primary></indexterm>
2154                 This type of problem is common when one client is configured to use a WINS server (that is
2155                 a TCP/IP configuration setting) and there is no WINS server on the network. Alternatively,
2156                 this will happen if there is a WINS server and Samba is not configured to use it. The use of
2157                 WINS is highly recommended if the network is using NetBIOS over TCP/IP protocols. If use
2158                 of NetBIOS over TCP/IP is disabled on all clients, Samba should not be configured as a WINS
2159                 server, nor should it be configured to use one.
2160                 </para></listitem>
2161         </varlistentry>
2162
2163         <varlistentry>
2164                 <term>Incorrect DNS Configuration</term>
2165                 <listitem><para>
2166 <indexterm><primary>DNS Configuration</primary></indexterm>
2167 <indexterm><primary>NetBIOS over TCP/IP disabled</primary></indexterm>
2168                 If use of NetBIOS over TCP/IP is disabled, Active Directory is in use and the DNS server
2169                 has been incorrectly configured. For further information refer to
2170                 <link linkend="adsdnstech">DNS and Active Directory</link>.
2171                 </para></listitem>
2172         </varlistentry>
2173 </variablelist>
2174
2175 </sect2>
2176 <sect2>
2177 <title>Invalid Cached Share References Affects Network Browsing</title>
2178 <para>
2179 <indexterm><primary>cached references</primary></indexterm>
2180 <indexterm><primary>stale network links</primary></indexterm>
2181 Cached references on your MS Windows client (workstation or server) to shares or servers that no longer exist
2182 can cause MS Windows Explorer to appear unresponsive as it tries to connect to these shares. After a delay
2183 (can take a long time) it times out and browsing will appear to be mostly normal again.
2184 </para>
2185
2186 <para>
2187 To eliminate the problem the stale cached references should be removed. This does not happen automatically and
2188 requires manual intervention. This is a design feature of MS Windows and not anything that Samba can change.
2189 To remove the stale shortcuts found in <emphasis>My Network Places</emphasis> which refer to what are now
2190 invalid shares or servers it is necessary to edit the Windows Registry under
2191 <literal>HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\</literal>. Edit the entry
2192 <literal>MountPoints2</literal> (on Windows XP and later, or <literal>MountPoints</literal> on Windows 2000
2193 and earlier). Remove all keys named <literal>\\server\share</literal> (where 'server' and 'share' refer to a
2194 non-existent server or share).
2195 </para>
2196
2197 <note><para>
2198 Removal of stale network links needs to be done on a per-user basis. Alternately, you can delete the
2199 shortcuts from the MS Windows Explorer in <literal>My Network Places</literal> just by right-clicking them and
2200 selecting <emphasis>Delete.</emphasis>
2201 </para></note>
2202
2203 <para>
2204 <indexterm><primary>slow network browsing</primary></indexterm>
2205 Samba users have reported that these stale references negatively affect network browsing with Windows, Samba,
2206 and Novell servers. It is suspected to be a universal problem not directly related to the Samba
2207 server. Samba users may experience this more often due to Samba being somewhat viewed as an experimenter's
2208 toolkit. This results from the fact that a user might go through several reconfigurations and incarnations of
2209 their Samba server, by different names, with different shares, increasing the chances for having stale
2210 (invalid) cached share references. Windows clients do not expire these references thus necessitating manual
2211 removal.
2212 </para>
2213
2214 <para>
2215 It is common for <emphasis>Open</emphasis> dialog boxes (for example; in Word and Excel) to respond very
2216 slowly, as they attempt to locate all of the cached references, even if they are not in the current directory
2217 being accessed.
2218 </para>
2219 </sect2>
2220 </sect1>
2221 </chapter>