SAMBA Configuring NetBIOS Support in Linux

Many people are under the misimpression that simply having a network protocol such as TCP/IP in common is sufficient for two operating systems to communicate. The fact is that nothing is further from the truth. Although a common protocol is required, that is only part of the picture. Let’s look at a simple example – the web.

In order to browse a web site you must have a network/transport layer protocol in common. This protocol provides connectivity and routing functionality, but it does not allow to applications to communicate. In order for a web client, such as Netscape to browse a web server such as Apache, there must be a common application layer protocol. In this case, the application layer protocol is HTTP. HTTP provides the basic set of commands for retrieving and posting information on the web, but it does not actually transport the data. That is provided by the lower layer protocols. File sharing is no exception. In order to browse the file system of a remote system, there must be a common application layer protocol. On Windows systems, this protocol is the Server Message Block (SMB) protocol.

Windows provides a SMB client built into all Windows Operating Systems, and hidden in the functionality of Explorer. This client is managed via the Workstation Service and the Client for Microsoft Networks. Windows also provides an SMB server in the form of File and Print Sharing for Microsoft Networks and the Server Service. If any of these components is uninstalled or disabled, then SMB, and thus file sharing, functionality is not available.

The common Open Source alternative/supplement to the Client for Microsoft Networks, and File and Print Sharing for Microsoft Networks is Samba. Samba provides a Server and Client component that when installed, allow a Linux computer to appear in “My Network Places” and expose shares, as well as connect to and work with shares based on Windows.

Integrating DNS and WINS

Since many networks running NT 4.0 relied on WINS as their primary name resolution facility, Microsoft provided a non-standard method for integrating DNS with WINS. This involved configuring a DNS server with special WINS-related records that would then be used to extend name resolution beyond the records known to DNS. In a nutshell, if configured with the address of a WINS server (using the non-standard WINS record), the DNS server would attempt to query WINS for any records not found in the DNS zone database file. It would do this by reformatting the request as a NetBIOS query, and the WINS server would respond if a match was found. This provided many companies with an efficient way to create a type of dynamic DNS in NT 4, since clients whose IP addresses were not in DNS (since they used DHCP) could still be found via DNS, since WINS is updated dynamically.

This same functionality still exists in Windows 2000, even though dynamic DNS now exists. Remember that non-Windows 2000 clients still do not use dynamic DNS, and many companies have large WINS implementations that work quiet well, and as such, might wish to continue using this rather than switching to DHCP-initiated client updates. Before looking at how integration between WINS and DNS should be handled, remember that a DNS query is resolved by a DNS server that is authoritative for the zone within which a DNS domain exists. That is, a name server whose zone is responsible for the domain will answer a query for The reason that I mention this is because the placement of the WINS records will differ based on a company’s DNS implementation.

For example, imagine that my company has set up DNS to support Active Directory, and my implementation is such that only records for domain controllers appear in DNS. If I configure my single DNS forward lookup zone with a WINS record pointing to my WINS server, this WINS server will be queried if the associated host record is not found in DNS. While this works fine for a single forward lookup zone, it becomes more complex when my company has many domains in its DNS implementation (perhaps because of a large multi-domain AD design). In cases like these, you might want every forward lookup zone to be configured to do WINS resolution, and this might involve a great deal of administration. For this reason, Microsoft recommends creating a separate Active Directory domain strictly for the purpose of WINS resolution. At first glace this may not may sense, so let me explain. In the Advanced TCP/IP properties of a system (on the DNS tab, as shown below), you can control the order in which domains are searched for the purpose of name resolution. By default, the suffix for the domain in which the local system exists is searched, followed by parent domains. For example, imagine you typed ping server3. If the client system from which the command was issued was in the domain, it would first try resolving (notice is automatically appends the domain name since you didn’t use an FQDN). If this fails, it will then attempt (appending the suffixes of the parent domain – If this also fails to resolve the name, resolution fails.

Consider what would happen if you were to create a separate DNS domain just for WINS resolution, however. You might create a special domain within your DNS structure called, and have this be the second domain appended in a search to resolve a hostname.

Now, if a client were to attempt to ping an unqualified hostname, like server3, it would first attempt to query followed by The idea is that if an answer could not be found in subdomain ‘west’, it would then attempt subdomain ‘wins’. The forward lookup zone for subdomain ‘wins’ would only need to be configured with 1 (or more) WINS records (and WINS-R records in the associated reverse lookup zone), pointing to the appropriate WINS servers where clients and servers are registered. This setup is best when you have many domains and/or subdomains, where client DNS properties are set to query their own domain first, followed by the special ‘wins’ domain second, thereby making use of the existing WINS facility for resolution.

WINS Features and Functions

WINS in Windows 2000 still behaves very much like WINS in Windows NT. The section provides an overview of some old functionality you may have forgotten about, as well as some of the new functions that you should be aware of.

WINS Proxy – Just like in NT 4, you can configure a Windows 2000 system as a WINS proxy. A WINS proxy is a system that listens for NetBIOS broadcasts on the network and forwards those broadcasts to a WINS server for resolution. WINS proxies are used when a subnet contains systems that use NetBIOS but do not support WINS, allowing these systems to use NetBIOS naming and communicate across a TCP/IP internetwork. Like in NT 4, a WINS proxy is configured via a registry setting, so you’ll need to add the setting EnableProxy with a value of 1 to the path HKLM\System\CurrentControlSet\Services\NetBT\Parameters

Burst Handling – At certain times during the day, WINS servers may take on a heavy load of registrations, such as when people boot up their PCs when they get into the office at around 9am, or after a network failure. WINS in Windows 2000 has the ability to handle these high-impact times using burst handling (this also existed in NT versions with SP 3 and above). Turned on by default, the WINS server handles requests normally until the burst-queue reaches 500 requests (the medium setting). After it reaches 500 queued registration requests (which can be changed via the WINS console as shown below), the server begins responding positively to clients immediately with a TTL of 5 minutes for the first 100 clients above 500, increasing the TTL by an additional 5 minutes for every 100 clients thereafter. This basically forces the clients to fully reregister with the WINS server once the load had decreased on the server.

Manual Tombstoning – The manual tombstoning feature in Windows 2000 exists to help ensure the co