From d4b35b895cdf157e49609b59ec89ab648dafb524 Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Wed, 13 Apr 2005 04:04:36 +0000 Subject: More updates. (This used to be commit 20f8bde1d0a2b2e42efedcdac21778fe34c0ab79) --- .../TOSHARG-NetworkBrowsing.xml | 1797 ++++++++++++++++++++ 1 file changed, 1797 insertions(+) create mode 100644 docs/Samba-HOWTO-Collection/TOSHARG-NetworkBrowsing.xml (limited to 'docs/Samba-HOWTO-Collection/TOSHARG-NetworkBrowsing.xml') diff --git a/docs/Samba-HOWTO-Collection/TOSHARG-NetworkBrowsing.xml b/docs/Samba-HOWTO-Collection/TOSHARG-NetworkBrowsing.xml new file mode 100644 index 0000000000..6470295d66 --- /dev/null +++ b/docs/Samba-HOWTO-Collection/TOSHARG-NetworkBrowsing.xml @@ -0,0 +1,1797 @@ + + + + + &author.jht; + &author.jelmer; + July 5, 1998 + Updated: April 21, 2003 + + +Network Browsing + + +This document contains detailed information as well as a fast track guide to +implementing browsing across subnets and/or across workgroups (or domains). +WINS is the best tool for resolution of NetBIOS names to IP addresses. WINS is +not involved in browse list handling except by way of name to address resolution. + + + +MS Windows 2000 and later versions can be configured to operate with no NetBIOS +over TCP/IP. Samba-3 and later versions also support this mode of operation. +When the use of NetBIOS over TCP/IP has been disabled, the primary +means for resolution of MS Windows machine names is via DNS and Active Directory. +The following information assumes that your site is running NetBIOS over TCP/IP. + + + +Features and Benefits + + +Someone once referred to the past in these words It was the best of times, +it was the worst of times. The more we look back, the more we long for what was and +hope it never returns. + + + + +NetBIOS +For many MS Windows network administrators, that statement sums up their feelings about +NetBIOS networking precisely. For those who mastered NetBIOS networking, its fickle +nature was just par for the course. For those who never quite managed to tame its +lusty features, NetBIOS is like Paterson's Curse. + + + +For those not familiar with botanical problems in Australia, Paterson's Curse, +Echium plantagineum, was introduced to Australia from Europe during the mid-nineteenth +century. Since then it has spread rapidly. The high seed production, with densities of +thousands of seeds per square meter, a seed longevity of more than seven years, and an +ability to germinate at any time of year, given the right conditions, are some of the +features which make it such a persistent weed. + + + +In this chapter we explore vital aspects of Server Message Block (SMB) networking with +a particular focus on SMB as implemented through running NetBIOS (Network Basic +Input/Output System) over TCP/IP. Since Samba does not implement SMB or NetBIOS over +any other protocols, we need to know how to configure our network environment and simply +remember to use nothing but TCP/IP on all our MS Windows network clients. + + + +Samba provides the ability to implement a WINS (Windows Inter-networking Name Server) +and implements extensions to Microsoft's implementation of WINS. These extensions +help Samba to effect stable WINS operations beyond the normal scope of MS WINS. + + + +WINS is exclusively a service that applies only to those systems +that run NetBIOS over TCP/IP. MS Windows 200x/XP have the capacity to operate with +support for NetBIOS disabled, in which case WINS is of no relevance. Samba supports this also. + + + +For those networks on which NetBIOS has been disabled (i.e., WINS is not required) +the use of DNS is necessary for host name resolution. + + + + + +What Is Browsing? + + +To most people browsing means they can see the MS Windows and Samba servers +in the Network Neighborhood, and when the computer icon for a particular server is +clicked, it opens up and shows the shares and printers available on the target server. + + + +What seems so simple is in fact a complex interaction of different technologies. +The technologies (or methods) employed in making all of this work include: + + + + MS Windows machines register their presence to the network. + Machines announce themselves to other machines on the network. + One or more machine on the network collates the local announcements. + The client machine finds the machine that has the collated list of machines. + The client machine is able to resolve the machine names to IP addresses. + The client machine is able to connect to a target machine. + + + +The Samba application that controls browse list management and name resolution is +called nmbd. The configuration parameters involved in nmbd's operation are: + + +Browsing options: (*), + , + , + (*), + (*), + (*), + , + . + + +Name Resolution Method: + (*). + + +WINS options: + , + , + (*), + (*), + . + + + +WINS +For Samba, the WINS Server and WINS Support are mutually exclusive options. Those marked with +an (*) are the only options that commonly may need to be modified. Even if none of these +parameters is set, nmbd will still do its job. + + + + + +Discussion + + +SMB-based messaging +NetBIOS +All MS Windows networking uses SMB-based messaging. SMB messaging may be implemented with or without NetBIOS. +MS Windows 200x supports NetBIOS over TCP/IP for backwards compatibility. Microsoft appears intent on phasing +out NetBIOS support. + + + +NetBIOS over TCP/IP + + +encapsulating +broadcast +unicast +UDP +Samba implements NetBIOS, as does MS Windows NT/200x/XP, by encapsulating it over TCP/IP. +MS Windows products can do likewise. NetBIOS-based networking uses broadcast messaging to +effect browse list management. When running NetBIOS over TCP/IP, this uses UDP-based messaging. +UDP messages can be broadcast or unicast. + + + +UDP +Normally, only uni-cast UDP messaging can be forwarded by routers. The + parameter to smb.conf helps to project browse announcements +to remote network segments via uni-cast UDP. Similarly, the + parameter of &smb.conf; +implements browse list collation using uni-cast UDP. + + + +The methods used by MS Windows to perform name lookup requests (name resolution) is determined by a +configuration parameter called the netbios node-type. There are four (4) basic NetBIOS node types: + + +b-node +p-node +m-node +h-node +node-type +WINS +broadcast +unicast + + b-node (type 0x01): The Windows client will use only + NetBIOS broadcast requests using UDP broadcast. + p-node (type 0x02): The Windows client will use point-to-point + (NetBIOS unicast) requests using UDP unicast directed to a WINS server. + m-node (type 0x04): The Windows client will first use + NetBIOS broadcast requests using UDP broadcast, then it will use (NetBIOS unicast) + requests using UDP unicast directed to a WINS server. + h-node (type 0x08): The Windows client will use + (NetBIOS unicast) requests using UDP unicast directed to a WINS server, then it will use + NetBIOS broadcast requests using UDP broadcast. + + + +Hybrid +The default Windows network client (or server) network configuration enables NetBIOS over TCP/IP +and b-node configuration. The use of WINS makes most sense with h-node (Hybid mode) operation so that +in the event of a WINS breakdown or non-availability the client can use broadcast based name resolution. + + + +LMBLocal Master Browser +Local Master Browser +In those networks where Samba is the only SMB server technology, wherever possible +nmbd should be configured on one machine as the WINS +server. This makes it easy to manage the browsing environment. If each network +segment is configured with its own Samba WINS server, then the only way to +get cross-segment browsing to work is by using the + and the + +parameters to your &smb.conf; file. + + + +WINS +If only one WINS server is used for an entire multi-segment network, then +the use of the and the + parameters should not be necessary. + + + +replicationWINS +As of Samba-3 WINS replication is being worked on. The bulk of the code has +been committed, but it still needs maturation. This is not a supported feature +of the Samba-3.0.0 release. Hopefully, this will become a supported feature +of one of the Samba-3 release series. + + + +Right now Samba WINS does not support MS-WINS replication. This means that +when setting up Samba as a WINS server, there must only be one nmbd +configured as a WINS server on the network. Some sites have used multiple Samba WINS +servers for redundancy (one server per subnet) and then used + and +to effect browse list collation across all segments. Note that this means clients +will only resolve local names, and must be configured to use DNS to resolve names +on other subnets in order to resolve the IP addresses of the servers they can see +on other subnets. This setup is not recommended, but is mentioned as a practical +consideration (i.e., an if all else fails scenario). + + + +Lastly, take note that browse lists are a collection of unreliable broadcast +messages that are repeated at intervals of not more than 15 minutes. This means +that it will take time to establish a browse list and it can take up to 45 +minutes to stabilize, particularly across network segments. + + + +When an MS Windows 200x/XP system attempts to resolve a host name to an IP address +it follows a defined path: + + + + + Checks the hosts file. It is located in + %SystemRoot%\System32\Drivers\etc. + + + + Does a DNS lookup. + + + + Checks the NetBIOS name cache. + + + + Queries the WINS server. + + + + Does a broadcast name lookup over UDP. + + + + Looks up entries in LMHOSTS, located in + %SystemRoot%\System32\Drivers\etc. + + + + + + +TCP/IP without NetBIOS + + +NetBIOS +NetBIOS-less +DNS +All TCP/IP-enabled systems use various forms of host name resolution. The primary +methods for TCP/IP hostname resolution involve either a static file (/etc/hosts) +or the Domain Name System (DNS). DNS is the technology that makes +the Internet usable. DNS-based host name resolution is supported by nearly all +TCP/IP-enabled systems. Only a few embedded TCP/IP systems do not support DNS. + + + +DNS +Windows 200x/XP can register its host name with a Dynamic DNS server. You can +force register with a Dynamic DNS server in Windows 200x/XP using: +ipconfig /registerdns. + + + +With Active Directory (ADS), a correctly functioning DNS server is absolutely +essential. In the absence of a working DNS server that has been correctly configured, +MS Windows clients and servers will be unable to locate each other, so +consequently network services will be severely impaired. + + + +The use of Dynamic DNS is highly recommended with Active Directory, in which case +the use of BIND9 is preferred for its ability to adequately support the SRV (service) +records that are needed for Active Directory. + + + +Use of raw SMB over TCP/IP (No NetBIOS layer) can be done only with Active +Directory domains. Samba is not an Active Directory Domain Controller: ergo, +it is not possible run Samba as a domain controller and at the same time NOT use +NetBIOS. Where Samba is used as an Active Directory Domain Member Server (DMS) +it is possible to configure Samba to not use NetBIOS over TCP/IP. A Samba DMS +can integrate fully into an Active Directory domain. + + + + + +DNS and Active Directory + + + +DNSActive Directory +Occasionally we hear from UNIX network administrators who want to use a UNIX-based Dynamic +DNS server in place of the Microsoft DNS server. While this might be desirable to some, the +MS Windows 200x DNS server is auto-configured to work with Active Directory. It is possible +to use BIND version 8 or 9, but it will almost certainly be necessary to create service records +(SRV records) so MS Active Directory clients can resolve host names to locate essential network services. +The following are some of the default service records that Active Directory requires: + + + + + _ldap._tcp.pdc._msdcs.Domain + + + This provides the address of the Windows NT PDC for the Domain. + + + + + _ldap._tcp.pdc._msdcs.DomainTree + + + Resolves the addresses of Global Catalog servers in the domain. + + + + + _ldap._tcp.site.sites.writable._msdcs.Domain + + + Provides list of Domain Controllers based on sites. + + + + + _ldap._tcp.writable._msdcs.Domain + + + Enumerates list of Domain Controllers that have the writable copies of the Active Directory data-store. + + + + + _ldap._tcp.GUID.domains._msdcs.DomainTree + + + Entry used by MS Windows clients to locate machines using the Global Unique Identifier. + + + + + _ldap._tcp.Site.gc._msdcs.DomainTree + + + Used by MS Windows clients to locate site configuration dependent Global Catalog server. + + + + + + + Specific entries used by Microsoft clients to locate essential services for an example domain + called quenya.org includes: + + + + + _kerberos._udp.quenya.org &smbmdash; Used to contact the KDC server via UDP. + This entry must list port 88 for each KDC. + + + + _kpasswd._udp.quenya.org &smbmdash; Used to locate the kpasswd server + when a user password change must be processed. This record must list port 464 on the + master KDC. + + + + _kerberos._tcp.quenya.org &smbmdash; Used to locate the KDC server via TCP. + This entry must list port 88 for each KDC. + + + + _ldap._tcp.quenya.org &smbmdash; Used to locate the LDAP service on the PDC. + This record must list port 389 for the PDC. + + + + _kpasswd._tcp.quenya.org &smbmdash; Used to locate the kpasswd server + to permit user password changes to be processed. This must list port 464. + + + + _gc._tcp.quenya.org &smbmdash; Used to locate the Global Catalog server for the + top of the domain. This must list port 3268. + + + + + The following records are also used by the Windows Domain Member client to locate vital + services on the Windows ADS domain controllers. + + + + + _ldap._tcp.pdc._msdcs.quenya.org + + + + _ldap.gc._msdcs.quenya.org + + + + _ldap.default-first-site-name._sites.gc._msdcs.quenya.org + + + + _ldap.{SecID}.domains._msdcs.quenya.org + + + + _ldap._tcp.dc._msdcs.quenya.org + + + + _kerberos._tcp.dc._msdcs.quenya.org + + + + _ldap.default-first-site-name._sites.dc._msdcs.quenya.org + + + + _kerberos.default-first-site-name._sites.dc._msdcs.queyna.org + + + + SecID._msdcs.quenya.org + + + + + Presence of the correct DNS entries can be validated by executing: + +&rootprompt; dig @frodo -t any _ldap._tcp.dc._msdcs.quenya.org + +; <lt;>> DiG 9.2.2 <lt;>> @frodo -t any _ldap._tcp.dc._msdcs.quenya.org +;; global options: printcmd +;; Got answer: +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3072 +;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 + + +;; QUESTION SECTION: +;_ldap._tcp.dc._msdcs.quenya.org. IN ANY + + +;; ANSWER SECTION: +_ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 frodo.quenya.org. +_ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 noldor.quenya.org. + + +;; ADDITIONAL SECTION: +frodo.quenya.org. 3600 IN A 10.1.1.16 +noldor.quenya.org. 1200 IN A 10.1.1.17 + + +;; Query time: 0 msec +;; SERVER: frodo#53(10.1.1.16) +;; WHEN: Wed Oct 7 14:39:31 2004 +;; MSG SIZE rcvd: 171 + + + + + + + + +How Browsing Functions + + +MS Windows machines register their NetBIOS names +(i.e., the machine name for each service type in operation) on start-up. +The exact method by which this name registration +takes place is determined by whether or not the MS Windows client/server +has been given a WINS server address, whether or not LMHOSTS lookup +is enabled, or if DNS for NetBIOS name resolution is enabled, etc. + + + +In the case where there is no WINS server, all name registrations as +well as name lookups are done by UDP broadcast. This isolates name +resolution to the local subnet, unless LMHOSTS is used to list all +names and IP addresses. In such situations, Samba provides a means by +which the Samba server name may be forcibly injected into the browse +list of a remote MS Windows network (using the + parameter). + + + +Where a WINS server is used, the MS Windows client will use UDP +uni-cast to register with the WINS server. Such packets can be routed +and thus WINS allows name resolution to function across routed networks. + + + +During the startup process an election will take place to create a +Local Master Browser if one does not already exist. On each NetBIOS network +one machine will be elected to function as the Domain Master Browser. This +domain browsing has nothing to do with MS security Domain Control. +Instead, the Domain Master Browser serves the role of contacting each local +master browser (found by asking WINS or from LMHOSTS) and exchanging browse +list contents. This way every master browser will eventually obtain a complete +list of all machines that are on the network. Every 11 to 15 minutes an election +is held to determine which machine will be the master browser. By the nature of +the election criteria used, the machine with the highest uptime, or the +most senior protocol version or other criteria, will win the election +as Domain Master Browser. + + + +Clients wishing to browse the network make use of this list, but also depend +on the availability of correct name resolution to the respective IP +address/addresses. + + + +Any configuration that breaks name resolution and/or browsing intrinsics +will annoy users because they will have to put up with protracted +inability to use the network services. + + + +Samba supports a feature that allows forced synchronization of browse lists across +routed networks using the +parameter in the &smb.conf; file. This causes Samba to contact the local master +browser on a remote network and to request browse list synchronization. This +effectively bridges two networks that are separated by routers. The two remote +networks may use either broadcast-based name resolution or WINS-based name +resolution, but it should be noted that the + parameter provides +browse list synchronization &smbmdash; and that is distinct from name to address +resolution. In other words, for cross-subnet browsing to function correctly it is +essential that a name-to-address resolution mechanism be provided. This mechanism +could be via DNS, /etc/hosts, and so on. + + + +Configuring WORKGROUP Browsing + + +To configure cross-subnet browsing on a network containing machines +in a WORKGROUP, not an NT Domain, you need to set up one +Samba server to be the Domain Master Browser (note that this is not +the same as a Primary Domain Controller, although in an NT Domain the +same machine plays both roles). The role of a Domain Master Browser is +to collate the browse lists from Local Master Browsers on all the +subnets that have a machine participating in the workgroup. Without +one machine configured as a Domain Master Browser, each subnet would +be an isolated workgroup unable to see any machines on another +subnet. It is the presence of a Domain Master Browser that makes +cross-subnet browsing possible for a workgroup. + + + +In a WORKGROUP environment the Domain Master Browser must be a +Samba server, and there must only be one Domain Master Browser per +workgroup name. To set up a Samba server as a Domain Master Browser, +set the following option in the section +of the &smb.conf; file: + + + + +yes + + + + +The Domain Master Browser should preferably be the local master +browser for its own subnet. In order to achieve this, set the following +options in the section of the &smb.conf; +file as shown in the following example: + + + + +Domain Master Browser smb.conf + +yes +yes +yes +65 + + + + +The Domain Master Browser may be the same machine as the WINS server, if necessary. + + + +Next, you should ensure that each of the subnets contains a machine that can act as +a Local Master Browser for the workgroup. Any MS Windows NT/200x/XP machine should +be able to do this, as will Windows 9x/Me machines (although these tend to get +rebooted more often, so it is not such a good idea to use these). To make a Samba +server a Local Master Browser set the following options in the + section of the &smb.conf; file as +shown in following example: + + + + +Local master browser smb.conf + +no +yes +yes +65 + + + + +Do not do this for more than one Samba server on each subnet, or they will war with +each other over which is to be the Local Master Browser. + + + +The parameter allows Samba to act as a +Local Master Browser. The causes nmbd +to force a browser election on startup and the +parameter sets Samba high enough so it should win any browser elections. + + + +If you have an NT machine on the subnet that you wish to be the Local Master Browser, you can disable Samba from +becoming a Local Master Browser by setting the following options in the section of the +&smb.conf; file as shown in following example: + + + + +smb.conf for not being a Master Browser + +no +no +no +0 + + + + + + +DOMAIN Browsing Configuration + + +If you are adding Samba servers to a Windows NT Domain, then you must not set up a Samba server as a Domain Master Browser. +By default, a Windows NT Primary Domain Controller for a domain is also the Domain Master Browser for that domain. Network +browsing may break if a Samba server registers the domain master browser NetBIOS name (DOMAIN<1B>) +with WINS instead of the PDC. + + + +For subnets other than the one containing the Windows NT PDC, you may set up Samba servers as Local Master Browsers as +described. To make a Samba server a Local Master Browser, set the following options in the section +of the &smb.conf; file as shown in following example: + + + + +Local Master Browser smb.conf + +no +yes +yes +65 + + + + +If you wish to have a Samba server fight the election with machines on the same subnet you +may set the parameter to lower levels. +By doing this you can tune the order of machines that will become Local Master Browsers if +they are running. For more details on this refer to Forcing Samba to Be the Master section. + + + +If you have Windows NT machines that are members of the domain on all subnets and you are +sure they will always be running, you can disable Samba from taking part in browser elections +and ever becoming a Local Master Browser by setting the following options in the + section of the &smb.conf; file as shown in next example: + + + + +&smb.conf; for not being a master browser + +no +no +no +0 + + + + + + +Forcing Samba to Be the Master + + +Who becomes the master browser is determined by an election process using broadcasts. Each election packet contains a number of parameters +that determine what precedence (bias) a host should have in the election. By default Samba uses a low precedence and thus loses +elections to just about every Windows network server or client. + + + +If you want Samba to win elections, set the +global option in &smb.conf; to a higher number. It defaults to 20. Using 34 would make it win +all elections every other system (except other samba systems). + + + +An of two would make it beat Windows for Workgroups and Windows 9x/Me, but not MS Windows +NT/200x Server. An MS Windows NT/200x Server Domain Controller uses level 32. The maximum os level is 255. + + + +If you want Samba to force an election on startup, set the + global option in &smb.conf; to yes. +Samba will then have a slight advantage over other potential master browsers that are not Preferred Master Browsers. +Use this parameter with care, as if you have two hosts (whether they are Windows 9x/Me or +NT/200x/XP or Samba) on the same local subnet both set with +to yes, then periodically and continually they will force an election in order +to become the Local Master Browser. + + + +If you want Samba to be a Domain Master Browser, then it is recommended that +you also set to yes, because +Samba will not become a Domain Master Browser for the whole of your LAN or WAN if it is not also a +Local Master Browser on its own broadcast isolated subnet. + + + +It is possible to configure two Samba servers to attempt to become the Domain Master Browser for a domain. The first server that comes +up will be the Domain Master Browser. All other Samba servers will attempt to become the Domain Master Browser every five minutes. They +will find that another Samba server is already the domain master browser and will fail. This provides automatic redundancy, should +the current Domain Master Browser fail. + + + + + +Making Samba the Domain Master + + +The domain master is responsible for collating the browse lists of multiple subnets so browsing can occur between subnets. You can +make Samba act as the Domain Master by setting yes +in &smb.conf;. By default it will not be a Domain Master. + + + +Do not set Samba to be the Domain Master for a workgroup that has the same name as an NT/200x Domain. +If Samba is configured to be the Domain Master for a workgroup that is present on the same +network as a Windows NT/200x domain that has the same name, network browsing problems will +certainly be experienced. + + + +When Samba is the Domain Master and the Master Browser, it will listen for master +announcements (made roughly every twelve minutes) from Local Master Browsers on +other subnets and then contact them to synchronize browse lists. + + + +If you want Samba to be the domain master, you should also set the + high enough to make sure it wins elections, and +set to yes, to +get Samba to force an election on startup. + + + +All servers (including Samba) and clients should be using a WINS server to resolve NetBIOS names. If your +clients are only using broadcasting to resolve NetBIOS names, then two things will occur: + + + + + + Local Master Browsers will be unable to find a Domain Master Browser, as they will be looking only on the local subnet. + + + + + + If a client happens to get hold of a domain-wide browse list and a user attempts to access a + host in that list, it will be unable to resolve the NetBIOS name of that host. + + + + + +If, however, both Samba and your clients are using a WINS server, then: + + + + + + Local master browsers will contact the WINS server and, as long as Samba has registered that it is a Domain Master Browser with the WINS + server, the Local Master Browser will receive Samba's IP address as its Domain Master Browser. + + + + + + When a client receives a domain-wide browse list and a user attempts to access a host in that list, it will contact the WINS server to + resolve the NetBIOS name of that host. As long as that host has registered its NetBIOS name with the same WINS server, the user will + be able to see that host. + + + + + + + +Note about Broadcast Addresses + + +If your network uses a 0 based broadcast address (for example, if it ends in a 0) then you will strike problems. Windows for Workgroups +does not seem to support a zeros broadcast and you will probably find that browsing and name lookups will not work. + + + + +Multiple Interfaces + + +Samba supports machines with multiple network interfaces. If you have multiple interfaces, you will +need to use the option in &smb.conf; to configure them. + + + +Use of the Remote Announce Parameter + +The parameter of +&smb.conf; can be used to forcibly ensure +that all the NetBIOS names on a network get announced to a remote network. +The syntax of the parameter is: + +a.b.c.d [e.f.g.h] ... + +or + +a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ... + + +where: + + a.b.c.d and e.f.g.h + +LMBLocal Master Browser +Local Master Browser + is either the LMB (Local Master Browser) IP address or the broadcast address of the remote network. + i.e., the LMB is at 192.168.1.10, or the address could be given as 192.168.1.255 where the netmask + is assumed to be 24 bits (255.255.255.0). When the remote announcement is made to the broadcast + address of the remote network, every host will receive our announcements. This is noisy and therefore + undesirable but may be necessary if we do not know the IP address of the remote LMB. + + + + + WORKGROUP + is optional and can be either our own workgroup or that of the remote network. If you use the + workgroup name of the remote network, our NetBIOS machine names will end up looking like + they belong to that workgroup. This may cause name resolution problems and should be avoided. + + + + + + + + +Use of the Remote Browse Sync Parameter + + +The parameter of +&smb.conf; is used to announce to another LMB that it must synchronize its NetBIOS name list with our +Samba LMB. This works only if the Samba server that has this option is +simultaneously the LMB on its network segment. + + + +The syntax of the parameter is: + + +a.b.c.d + + +where a.b.c.d is either the IP address of the +remote LMB or else is the network broadcast address of the remote segment. + + + + + + + +WINS &smbmdash; The Windows Inter-networking Name Server + + +Use of WINS (either Samba WINS or MS Windows NT Server WINS) is highly +recommended. Every NetBIOS machine registers its name together with a +name_type value for each of several types of service it has available. +It registers its name directly as a unique (the type 0x03) name. +It also registers its name if it is running the LanManager compatible +server service (used to make shares and printers available to other users) +by registering the server (the type 0x20) name. + + + +All NetBIOS names are up to 15 characters in length. The name_type variable +is added to the end of the name, thus creating a 16 character name. Any +name that is shorter than 15 characters is padded with spaces to the 15th +character. Thus, all NetBIOS names are 16 characters long (including the +name_type information). + + + +WINS can store these 16-character names as they get registered. A client +that wants to log onto the network can ask the WINS server for a list +of all names that have registered the NetLogon service name_type. This saves +broadcast traffic and greatly expedites logon processing. Since broadcast +name resolution cannot be used across network segments this type of +information can only be provided via WINS or via a statically configured +lmhosts file that must reside on all clients in the +absence of WINS. + + + +WINS also serves the purpose of forcing browse list synchronization by all +LMBs. LMBs must synchronize their browse list with the DMB (Domain Master +Browser) and WINS helps the LMB to identify its DMB. By definition this +will work only within a single workgroup. Note that the Domain Master Browser +has nothing to do with what is referred to as an MS Windows NT Domain. The +later is a reference to a security environment while the DMB refers to the +master controller for browse list information only. + + + +WINS will work correctly only if every client TCP/IP protocol stack +has been configured to use the WINS servers. Any client that has not been +configured to use the WINS server will continue to use only broadcast-based +name registration so WINS may never get to know about it. In any case, +machines that have not registered with a WINS server will fail name to address +lookup attempts by other clients and will therefore cause workstation access +errors. + + + +To configure Samba as a WINS server just add +yes to the &smb.conf; +file [global] section. + + + +To configure Samba to register with a WINS server just add +a.b.c.d +to your &smb.conf; file section. + + + +Never use both yes together +with a.b.c.d +particularly not using its own IP address. Specifying both will cause &nmbd; to refuse to start! + + + +WINS Server Configuration + + +Either a Samba Server or a Windows NT Server machine may be set up +as a WINS server. To configure a Samba Server to be a WINS server you must +add to the &smb.conf; file on the selected Server the following line to +the section: + + + + +yes + + + + +Versions of Samba prior to 1.9.17 had this parameter default to +yes. If you have any older versions of Samba on your network it is +strongly suggested you upgrade to a recent version, or at the very +least set the parameter to no on all these machines. + + + +Machines configured with yes will keep a list of +all NetBIOS names registered with them, acting as a DNS for NetBIOS names. + + + +It is strongly recommended to set up only one WINS server. Do not set the +yes option on more than one Samba +server. + + + +replicationWINS +To configure Windows NT/200x Server as a WINS server, install and configure +the WINS service. See the Windows NT/200x documentation for details. +Windows NT/200x WINS servers can replicate to each other, allowing more +than one to be set up in a complex subnet environment. As Microsoft +refuses to document the replication protocols, Samba cannot currently +participate in these replications. It is possible in the future that +a Samba-to-Samba WINS replication protocol may be defined, in which +case more than one Samba machine could be set up as a WINS server. +Currently only one Samba server should have the +yes parameter set. + + + +After the WINS server has been configured, you must ensure that all +machines participating on the network are configured with the address +of this WINS server. If your WINS server is a Samba machine, fill in +the Samba machine IP address in the Primary WINS Server field of +the Control Panel->Network->Protocols->TCP->WINS Server dialogs +in Windows 9x/Me or Windows NT/200x. To tell a Samba server the IP address +of the WINS server, add the following line to the section of +all &smb.conf; files: + + + + +<name or IP address> + + + + +where <name or IP address> is either the DNS name of the WINS server +machine or its IP address. + + + +This line must not be set in the &smb.conf; file of the Samba +server acting as the WINS server itself. If you set both the +yes option and the +<name> option then +nmbd will fail to start. + + + +There are two possible scenarios for setting up cross-subnet browsing. +The first details setting up cross-subnet browsing on a network containing +Windows 9x/Me, Samba and Windows NT/200x machines that are not configured as +part of a Windows NT Domain. The second details setting up cross-subnet +browsing on networks that contain NT Domains. + + + + + +WINS Replication + + +replicationWINS +Samba-3 permits WINS replication through the use of the wrepld utility. +This tool is not currently capable of being used as it is still in active development. +As soon as this tool becomes moderately functional, we will prepare man pages and enhance this +section of the documentation to provide usage and technical details. + + + + +Static WINS Entries + + +Adding static entries to your Samba WINS server is actually fairly easy. +All you have to do is add a line to wins.dat, typically +located in /usr/local/samba/var/locks or +/var/run/samba. + + + +Entries in wins.dat take the form of: + + +"NAME#TYPE" TTL ADDRESS+ FLAGS + + +where NAME is the NetBIOS name, TYPE is the NetBIOS type, TTL is the +time-to-live as an absolute time in seconds, ADDRESS+ is one or more +addresses corresponding to the registration and FLAGS are the NetBIOS +flags for the registration. + + + +A typical dynamic entry looks like this: + +"MADMAN#03" 1055298378 192.168.1.2 66R + + +To make it static, all that has to be done is set the TTL to 0, like this: + + +"MADMAN#03" 0 192.168.1.2 66R + + + + +Though this method works with early Samba-3 versions, there is a +possibility that it may change in future versions if WINS replication +is added. + + + + + + +Helpful Hints + + +The following hints should be carefully considered as they are stumbling points +for many new network administrators. + + + +Windows Networking Protocols + + +A common cause of browsing problems results from installing more than +one protocol on an MS Windows machine. + + + +Do not use more than one protocol on MS Windows clients. + + + +Every NetBIOS machine takes part in a process of electing the LMB (and DMB) +every 15 minutes. A set of election criteria is used to determine the order +of precedence for winning this election process. A machine running Samba or +Windows NT will be biased so the most suitable machine will predictably +win and thus retain its role. + + + +The election process is fought out so to speak over every NetBIOS network +interface. In the case of a Windows 9x/Me machine that has both TCP/IP and IPX +installed and has NetBIOS enabled over both protocols, the election will be +decided over both protocols. As often happens, if the Windows 9x/Me machine is +the only one with both protocols then the LMB may be won on the NetBIOS +interface over the IPX protocol. Samba will then lose the LMB role as Windows +9x/Me will insist it knows who the LMB is. Samba will then cease to function +as an LMB and thus browse list operation on all TCP/IP-only machines will +fail. + + + +Windows 95, 98, 98se, and Me are referred to generically as Windows 9x/Me. +The Windows NT4, 200x, and XP use common protocols. These are roughly +referred to as the Windows NT family, but it should be recognized that 2000 and +XP/2003 introduce new protocol extensions that cause them to behave +differently from MS Windows NT4. Generally, where a server does not support +the newer or extended protocol, these will fall back to the NT4 protocols. + + + +The safest rule of all to follow is: use only one protocol! + + + + + +Name Resolution Order + + +Resolution of NetBIOS names to IP addresses can take place using a number +of methods. The only ones that can provide NetBIOS name_type information +are: + + + + WINS &smbmdash; the best tool. + LMHOSTS &smbmdash; static and hard to maintain. + Broadcast &smbmdash; uses UDP and cannot resolve names across remote segments. + + + +Alternative means of name resolution include: + + +Static /etc/hosts &smbmdash; hard to maintain, and lacks name_type info. +DNS &smbmdash; is a good choice but lacks essential name_type info. + + + +Many sites want to restrict DNS lookups and avoid broadcast name +resolution traffic. The name resolve order parameter is of great help here. +The syntax of the name resolve order parameter is: + +wins lmhosts bcast host + +or + +wins lmhosts (eliminates bcast and host) + +The default is: + +host lmhost wins bcast + +where host refers to the native methods used by the UNIX system +to implement the gethostbyname() function call. This is normally +controlled by /etc/host.conf, /etc/nsswitch.conf and /etc/resolv.conf. + + + + + +Technical Overview of Browsing + + +SMB networking provides a mechanism by which clients can access a list +of machines in a network, a so-called . This list +contains machines that are ready to offer file and/or print services +to other machines within the network. Thus it does not include +machines that aren't currently able to do server tasks. The browse +list is heavily used by all SMB clients. Configuration of SMB +browsing has been problematic for some Samba users, hence this +document. + + + +MS Windows 2000 and later versions, as with Samba-3 and later versions, can be +configured to not use NetBIOS over TCP/IP. When configured this way, +it is imperative that name resolution (using DNS/LDAP/ADS) be correctly +configured and operative. Browsing will not work if name resolution +from SMB machine names to IP addresses does not function correctly. + + + +Where NetBIOS over TCP/IP is enabled, use of a WINS server is highly +recommended to aid the resolution of NetBIOS (SMB) names to IP addresses. +WINS allows remote segment clients to obtain NetBIOS name_type information +that cannot be provided by any other means of name resolution. + + + +Browsing Support in Samba + + +Samba facilitates browsing. The browsing is supported by &nmbd; +and is also controlled by options in the &smb.conf; file. +Samba can act as a local browse master for a workgroup and the ability +to support domain logons and scripts is now available. + + + +Samba can also act as a Domain Master Browser for a workgroup. This +means that it will collate lists from Local Master Browsers into a +wide area network server list. In order for browse clients to +resolve the names they may find in this list, it is recommended that +both Samba and your clients use a WINS server. + + + +Do not set Samba to be the Domain Master for a workgroup that has the same +name as an NT Domain. On each wide area network, you must only ever have one +Domain Master Browser per workgroup, regardless of whether it is NT, Samba +or any other type of domain master that is providing this service. + + + +nmbd can be configured as a WINS server, but it is not +necessary to specifically use Samba as your WINS server. MS Windows +NT4, Server or Advanced Server 200x can be configured as +your WINS server. In a mixed NT/200x server and Samba environment on +a Wide Area Network, it is recommended that you use the Microsoft +WINS server capabilities. In a Samba-only environment, it is +recommended that you use one and only one Samba server as the WINS server. + + + +To get browsing to work you need to run nmbd as usual, but will need +to use the option in &smb.conf; +to control what workgroup Samba becomes a part of. + + + +Samba also has a useful option for a Samba server to offer itself for +browsing on another subnet. It is recommended that this option is only +used for unusual purposes: announcements over the Internet, for +example. See in the +&smb.conf; man page. + + + + +Problem Resolution + + +If something does not work, the log.nmbd file will help +to track down the problem. Try a of 2 or 3 for finding +problems. Also note that the current browse list usually gets stored +in text form in a file called browse.dat. + + + +If it does not work, you should still be able to +type the server name as \\SERVER in filemanager, then +press enter and filemanager should display the list of available shares. + + + +Some people find browsing fails because they do not have the global + set to a valid account. Remember that the +IPC$ connection that lists the shares is done as guest and, thus, you must have a valid guest account. + + + +MS Windows 2000 and later (as with Samba) can be configured to disallow +anonymous (i.e., guest account) access to the IPC$ share. In that case, the +MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the +name of the currently logged-in user to query the IPC$ share. MS Windows +9x/Me clients are not able to do this and thus will not be able to browse +server resources. + + + +The other big problem people have is that their broadcast address, +netmask or IP address is wrong (specified with the option +in &smb.conf;) + + + + +Cross-Subnet Browsing + + +replicationbrowse lists +Since the release of Samba 1.9.17 (alpha1), Samba has supported the +replication of browse lists across subnet boundaries. This section +describes how to set this feature up in different settings. + + + +To see browse lists that span TCP/IP subnets (i.e., networks separated +by routers that do not pass broadcast traffic), you must set up at least +one WINS server. The WINS server acts as a DNS for NetBIOS names. This will +allow NetBIOS name-to-IP address translation to be completed by a direct +query of the WINS server. This is done via a directed UDP packet on +port 137 to the WINS server machine. The WINS server avoids the necessity +of default NetBIOS name-to-IP address translation, which is done +using UDP broadcasts from the querying machine. This means that machines +on one subnet will not be able to resolve the names of machines on +another subnet without using a WINS server. + + + +Remember, for browsing across subnets to work correctly, all machines, +be they Windows 95, Windows NT or Samba servers, must have the IP address +of a WINS server given to them by a DHCP server, or by manual configuration +(for Windows 9x/Me and Windows NT/200x/XP, this is in the TCP/IP Properties, under Network +settings); for Samba, this is in the &smb.conf; file. + + + +Behavior of Cross-Subnet Browsing + + +Cross-subnet Browsing is a complicated dance, containing multiple +moving parts. It has taken Microsoft several years to get the code +that achieves this correct, and Samba lags behind in some areas. +Samba is capable of cross-subnet browsing when configured correctly. + + + +Consider a network set up as in Cross-Subnet Browsing Example. + + + + Cross-Subnet Browsing Example. + browsing1 + + + +This consists of 3 subnets (1, 2, 3) connected by two routers +(R1, R2) which do not pass broadcasts. Subnet 1 has five machines +on it, subnet 2 has four machines, subnet 3 has four machines. Assume +for the moment that all machines are configured to be in the +same workgroup (for simplicity's sake). Machine N1_C on subnet 1 +is configured as Domain Master Browser (i.e., it will collate the +browse lists for the workgroup). Machine N2_D is configured as +WINS server and all the other machines are configured to register +their NetBIOS names with it. + + + +As these machines are booted up, elections for master browsers +will take place on each of the three subnets. Assume that machine +N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on +subnet 3. These machines are known as Local Master Browsers for +their particular subnet. N1_C has an advantage in winning as the +Local Master Browser on subnet 1 as it is set up as Domain Master +Browser. + + + +On each of the three networks, machines that are configured to +offer sharing services will broadcast that they are offering +these services. The Local Master Browser on each subnet will +receive these broadcasts and keep a record of the fact that +the machine is offering a service. This list of records is +the basis of the browse list. For this case, assume that +all the machines are configured to offer services, so all machines +will be on the browse list. + + + +For each network, the Local Master Browser on that network is +considered authoritative for all the names it receives via +local broadcast. This is because a machine seen by the Local Master +Browser via a local broadcast must be on the same network as the +Local Master Browser and thus is a trusted +and verifiable resource. Machines on other networks that +the Local Master Browsers learn about when collating their +browse lists have not been directly seen. These records are +called non-authoritative. + + + +At this point the browse lists appear as shown in the next example (these are +the machines you would see in your network neighborhood if you looked in it on a particular network right now). + + + + + Browse Subnet Example 1 + + + SubnetBrowse MasterList + + + + Subnet1N1_CN1_A, N1_B, N1_C, N1_D, N1_E + Subnet2N2_BN2_A, N2_B, N2_C, N2_D + Subnet3N3_DN3_A, N3_B, N3_C, N3_D + + +
+ + + +At this point all the subnets are separate, and no machine is seen across any of the subnets. + + + +Now examine subnet 2. As soon as N2_B has become the Local +Master Browser it looks for a Domain Master Browser with which to synchronize +its browse list. It does this by querying the WINS server +(N2_D) for the IP address associated with the NetBIOS name +WORKGROUP<1B>. This name was registered by the Domain Master +Browser (N1_C) with the WINS server as soon as it was started. + + + +Once N2_B knows the address of the Domain Master Browser, it +tells it that is the Local Master Browser for subnet 2 by +sending a MasterAnnouncement packet as a UDP port 138 packet. +It then synchronizes with it by doing a NetServerEnum2 call. This +tells the Domain Master Browser to send it all the server +names it knows about. Once the Domain Master Browser receives +the MasterAnnouncement packet, it schedules a synchronization +request to the sender of that packet. After both synchronizations +are complete the browse lists look as shown in following example: + + + + Browse Subnet Example 2 + + + + + + SubnetBrowse MasterList + + + + Subnet1N1_CN1_A, N1_B, N1_C, N1_D, N1_E, +N2_A(*), N2_B(*), N2_C(*), N2_D(*) + Subnet2N2_BN2_A, N2_B, N2_C, N2_D, N1_A(*), +N1_B(*), N1_C(*), N1_D(*), N1_E(*) + Subnet3N3_DN3_A, N3_B, N3_C, N3_D + + +
+ + +Servers with an (*) after them are non-authoritative names. + + + +At this point users looking in their network neighborhood on +subnets 1 or 2 will see all the servers on both, users on +subnet 3 will still only see the servers on their own subnet. + + + +The same sequence of events that occurred for N2_B now occurs +for the Local Master Browser on subnet 3 (N3_D). When it +synchronizes browse lists with the Domain Master Browser (N1_A) +it gets both the server entries on subnet 1, and those on +subnet 2. After N3_D has synchronized with N1_C and vica versa, +the browse lists will appear as shown in following example. + + + + Browse Subnet Example 3 + + + + + + + SubnetBrowse MasterList + + + + Subnet1N1_CN1_A, N1_B, N1_C, N1_D, N1_E, +N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*) + Subnet2N2_BN2_A, N2_B, N2_C, N2_D, N1_A(*), +N1_B(*), N1_C(*), N1_D(*), N1_E(*) + Subnet3N3_DN3_A, N3_B, N3_C, N3_D, N1_A(*), +N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*) + + +
+ + +Servers with an (*) after them are non-authoritative names. + + + +At this point, users looking in their network neighborhood on +subnets 1 or 3 will see all the servers on all subnets, while users on +subnet 2 will still only see the servers on subnets 1 and 2, but not 3. + + + +Finally, the Local Master Browser for subnet 2 (N2_B) will sync again +with the Domain Master Browser (N1_C) and will receive the missing +server entries. Finally, as when a steady state (if no machines +are removed or shut off) has been achieved, the browse lists will appear +as shown in example below. + + + + Browse Subnet Example 4 + + + + + + + SubnetBrowse MasterList + + + + Subnet1N1_CN1_A, N1_B, N1_C, N1_D, N1_E, +N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), +N3_C(*), N3_D(*) + Subnet2N2_BN2_A, N2_B, N2_C, N2_D, N1_A(*), +N1_B(*), N1_C(*), N1_D(*), N1_E(*), N3_A(*), N3_B(*), +N3_C(*), N3_D(*) + Subnet3N3_DN3_A, N3_B, N3_C, N3_D, N1_A(*), +N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), +N2_C(*), N2_D(*) + + +
+ + +Servers with an (*) after them are non-authoritative names. + + + +Synchronizations between the Domain Master Browser and Local +Master Browsers will continue to occur, but this should remain a +steady state operation. + + + +If either router R1 or R2 fails, the following will occur: + + + + + + Names of computers on each side of the inaccessible network fragments + will be maintained for as long as 36 minutes in the network neighborhood + lists. + + + + + + Attempts to connect to these inaccessible computers will fail, but the + names will not be removed from the network neighborhood lists. + + + + + + If one of the fragments is cut off from the WINS server, it will only + be able to access servers on its local subnet using subnet-isolated + broadcast NetBIOS name resolution. The effects are similar to that of + losing access to a DNS server. + + + + + + + + +Common Errors + + +Many questions are asked on the mailing lists regarding browsing. The majority of browsing +problems originate from incorrect configuration of NetBIOS name resolution. Some are of +particular note. + + + +How Can One Flush the Samba NetBIOS Name Cache without Restarting Samba? + + +flush name cache +Samba's nmbd process controls all browse list handling. Under normal circumstances it is +safe to restart nmbd. This will effectively flush the Samba NetBIOS name cache and cause it +to be rebuilt. This does not make certain that a rogue machine name will not re-appear +in the browse list. When nmbd is taken out of service, another machine on the network will +become the Browse Master. This new list may still have the rogue entry in it. If you really +want to clear a rogue machine from the list, every machine on the network will need to be +shut down and restarted after all machines are down. Failing a complete restart, the only +other thing you can do is wait until the entry times out and is then flushed from the list. +This may take a long time on some networks (perhaps months). + + + + + + Server Resources Can Not Be Listed + +My Client Reports This server is not configured to list shared resources + + + +Your guest account is probably invalid for some reason. Samba uses the +guest account for browsing in smbd. Check that your guest account is +valid. + + +Also see in the &smb.conf; man page. + + + + + I get an <errorname>`Unable to browse the network'</errorname> error + + This error can have multiple causes: +browsing problems + + + + There is no Local Master Browser. Configure &nmbd; + or any other machine to serve as Local Master Browser. + You cannot log onto the machine that is the local master + browser. Can you logon to it as a guest user? + There is no IP connectivity to the Local Master Browser. + Can you reach it by broadcast? + + + + +Browsing of Shares and Directories is Very Slow + + +slow browsing +There are only two machines on a test network. One a Samba server, the other a Windows XP machine. +Authentication and logons work perfectly, but when I try to explore shares on the Samba server, the +Windows XP client becomes unresponsive. Sometimes it does not respond for some minutes. Eventually, +Windows Explorer will respond and displays files and directories without problem. +display file and directory. + + + +But, the share is immediately available from a command shell (cmd, followed by +exploration with dos command. Is this a Samba problem or is it a Windows problem? How can I solve this? + + + +Here are a few possibilities: + + + + + Bad Networking Hardware + +bad hardware +WebClient + Most common defective hardware problems center around low cost or defective HUBs, routers, + Network Interface Controllers (NICs) and bad wiring. If one piece of hardware is defective + the whole network may suffer. Bad networking hardware can cause data corruption. Most bad + networking hardware problems are accompanied by an increase in apparent network traffic, + but not all. + + + + + The Windows XP WebClient + + A number of sites have reported similar slow network browsing problems and found that when + the WebClient service is turned off, the problem disappears. This is certainly something + that should be explored as it is a simple solution &smbmdash; if it works. + + + + + Inconsistent WINS Configuration + + This type of problem is common when one client is configured to use a WINS server (that is + a TCP/IP configuration setting) and there is no WINS server on the network. Alternately, + this will happen is there is a WINS server and Samba is not configured to use it. The use of + WINS is highly recommended if the network is using NetBIOS over TCP/IP protocols. If use + of NetBIOS over TCP/IP is disabled on all clients, Samba should not be configured as a WINS + server neither should it be configured to use one. + + + + + Incorrect DNS Configuration + + If use of NetBIOS over TCP/IP is disabled, Active Directory is in use and the DNS server + has been incorrectly configured. Refer DNS and Active Directory for more information. + + + + + + + -- cgit