NetBIOS and WINS – 2000Trainers.com

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.

Pages: 1234567

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 company.com will answer a query for server12.company.com. 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 west.company.com domain, it would first try resolving server3.west.company.com (notice is automatically appends the domain name since you didn’t use an FQDN). If this fails, it will then attempt server3.company.com (appending the suffixes of the parent domain – company.com). 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 wins.company.com, 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 server3.west.company.com followed by server3.wins.company.com. 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 consistency of WINS databases in environments where WINS replication is used. In effect, it allows you to manually tombstone records that you wish to have invalidated (not deleted) in WINS, such that the information will be replicated to all other WINS servers. This feature exists because a deleted record (one removed from the WINS database entirely) could be re-replicated to a server, since other servers would think that the record was still valid. The tombstoned record would then replicate and cause that record to be tombstoned on other WINS servers, and so on. The record would eventually be deleted from the WINS database once the tombstone lifetime expires.

Verify Database Consistency – Be careful with this one. WINS in Windows 2000 has a feature available called ‘Verify Database Consistency’ which allows you to verify that the information found in a given WINS database is correct and up-to-date. In effect, the feature forces the local WINS server to check all records replicated from other WINS servers and compare them with the current local versions found on the WINS server that owns the record. The local WINS server will then update the information as necessary. The problem with this command is that it is very resource intensive in large environments – it is suggested that it only be down in periods of low activity, such as after working hours.

Database Backup – In order to have the WINS database backed up automatically, you need to specify a backup path on the server’s General property tab. Once provided, the database will be backed up to this location every 3 hours. You can also specify that the database be backed up automatically when the WINS service stops (as it would on shutdown, for example). The General tab is shown below.

Persistent Connections – Another new feature in Windows 2000, WINS replication partners can now maintain (and do by default) persistent connections with one another. That means that less time and resources are used on the WINS server, since the necessary connection is always established between partners. This can be turned off via the Replication Partners properties (see the screen shot in the WINS replication section)

WINS Users Group – This group is created after WINS is installed, and membership allows a user read-only access to information stored in the WINS console, a useful feature for first-line network support.

Configuring WINS Clients

WINS client settings can be configured manually, or dynamically using the proper DHCP options (044 to assign server addresses, 046 to set the node type). WINS settings are set up by access the WINS tab in the advanced TCP/IP properties.

Note that unlike in NT 4 where you could only enter addresses for a primary and secondary server, in Windows 2000 you can configure the client with a list of up to 12 WINS servers to use in order of preference. Note that the client can be enabled or disabled from using an LMHOSTS file for lookup, and can also be enabled/disabled for NetBIOS over TCP/IP. As a best practice, you should ensure that all client applications run properly before disabling NetBIOS over TCP/IP.

WINS Replication

You should recall from NT 4 that you could configure WINS servers to replicate information to one another, giving multiple WINS servers a more complete view of the network. This functionality still exists, with the ability to configure replication manually, as well as automatically. The automatic partner configuration can be set on a WINS server and uses multicast traffic (address 224.0.1.24) to find and communicate with other WINS servers. By default, these servers will become push/pull partners of one another, and will replicate via ‘pull’ every 2 hours. The upside of using automatic configuration is that it is simple, but the downside is that you may want a higher degree of control. Also understand that all of your routers must support forwarding multicasts in order for this to work. Turned off by default, you can configure the WINS server to use multicasts via the Replication Partners properties Advanced tab.

The more traditional way of configuring WINS replication is manually, by making systems push/pull partners. These relationships can be one-way, or two-way, whichever best meets your needs.

Push partner – a push partner is configured notify its pull partner of changes to the WINS database after a certain number of changes. The push partner is simply a messenger – it tells the pull partner ‘I have changes’, and the pull partner grabs the changes. Push partner parameters are generally set in LAN environments where bandwidth is not a big issue.

Pull partner – a pull partner is configured to obtain changes from configured push partners as a function of time. That is, the pull partner can be configured to obtain changes at a certain time interval that is convenient for our network. For example, you might configure pull parameters in a WAN environment with limited bandwidth to replicate at midnight.

Remember the key – push partners get configured according to number of database changes; pull partners as a function of time. Configure for push in LAN environments and pull in WAN environments as a general rule. To have WINS servers replicate fully with one another, they must be push/pull partners of each other (since replication is set up one-way – pull obtaining changes from push – by default).

WINS Registration

Note that WINS is not installed on a Windows 2000 Server by default – you will need to add the service by accessing Windows Components via Add/Remove programs in Control Panel. As was the case in NT 4, systems configured to use WINS will register their NetBIOS name to IP address mapping when they start up. The actual process consists of a name registration, with a client renewing the registration once half the TTL (time to live assigned by the WINS server) for the registration has expired. If the name a client attempts to register is already in the database, the WINS server sends a challenge to the host who has the name registered to see whether the host is active. If not, the name registration will succeed. If the other client is active, the registration will fail since machine must have unique NetBIOS names. In the same way, a client will ‘unregister’ itself in WINS upon a proper shutdown. Note that when this happens, the entry is not immediately removed from the WINS database – instead, the entry is ‘tombstoned’ and marked for extinction, a process that allows the name release to be replicated to other WINS servers. Ultimately, the record is removed from WINS once the extinction timeout period has passed.

One of the more welcome features in Windows 2000 is the ability to change your IP address without a reboot. After doing so, you should ensure that you also reregister your name registration in WINS – a process accomplished by issuing the nbtstat –RR command.

LMHosts File

The LMHOSTS file is far from the most efficient solution to NetBIOS name resolution, but is of use in environments without WINS. Created on the same principal as the hostname-resolving HOSTS file, the LMHOSTS file is a plain text file that contains NetBIOS names in one column, followed by IP addresses in the other. A client can consult this file in trying to resolve a name to an address. Because the use of this file is associated with Microsoft B-node, it only makes sense to put mappings for remote hosts in this file – local hosts will always be found by the broadcast that happens prior to LMHOSTS consultation. By default, the LMHOSTS file can be found in the %systemroot%\system32\drivers\etc directory. You should also have an awareness of the optional tags that can be used with the file, as these provide additional functionality, as outlined below. Also note that you should place the most commonly used entries at the top of the LMHOSTS file, since the file is parsed from top to bottom.

Useful LMHOSTS file tags:

#PRE – Entries marked with the #PRE tag are pre-loaded into the NetBIOS name cache.

#DOM: – these entries designate domain controllers

#INCLUDE

– this entry marks the path to a centralized LMHOSTS file on the network. This can be a useful alternative to WINS (though still a great deal of work), but remember that the NetBIOS name-to-address mapping of the host with the centralized file must also be included in this LMHOSTS file.#MH – this entry designates that multiple entries exist for a name since the system is multihomed (has multiple network interfaces)

Note that Windows 2000 will use the LMHOSTS file by default, but this can be changed via the WINS tab in your Advanced TCP/IP settings. Consult the screen shot of the WINS tab later in the article to see the checkbox.

NetBIOS Name Resolution

Many people assume that NetBIOS name resolution is no longer necessary in Windows 2000 due to the heightened importance of DNS as the primary name resolution facility in the OS. Although Microsoft is certainly moving away from a reliance on NetBIOS as a network protocol, you simply cannot ignore the fact that programs exist that rely on NetBIOS. Yes, Windows 2000 does support resolving NetBIOS names in a variety of ways, including the use of DNS and related hostname-resolution techniques, but this is not necessarily efficient. Since so many products still use NetBIOS as their primary protocol, and since so many networks now run TCP/IP, it is still a good idea to run WINS on the network. If nothing else, it is impractical not to have it for the purpose of supporting downlevel clients such as Windows NT and Windows 98, who complete many important processes (such as logon) via NetBIOS.

A NetBIOS name is a 16-byte address that uniquely identifies a host on the network. This address is 15 characters long, with a 16th character that uniquely identifies a service that the system is running, such as the Server or Workstation services. A NetBIOS name is often referred to as a Computer name, although the line is blurring as Windows 2000 moves to a more integrated support of TCP/IP and DNS naming. Don’t forget that the purpose of WINS is mainly to resolve NetBIOS names to IP addresses. In the past, NetBIOS was the primary communication protocol used on Microsoft networks. The move to TCP/IP as the primary transport of choice has necessitated the ability to map NetBIOS names to IP addresses, and the ability to ‘piggyback’ NetBIOS over TCP/IP. However, WINS is not the only way to resolve these names to IP addresses. The official NetBIOS name resolution techniques in Windows 2000 include:

Local Broadcast – In this traditional method, a host will broadcast onto the local subnet trying to find the IP address associated with a given name. Obviously this method is restrictive, since it is limited in terms of reach on the network (as well as being inefficient)

NetBIOS Name Server – In most networks, a NetBIOS name server (such as WINS) is set up to handle name registration and queries directly. Clients systems (and servers) register their NetBIOS name to IP address mapping with WINS. When queried by a client, the NetBIOS name server replies with the requested IP address associated with the requested name.

NetBIOS Name Cache – Upon resolving a NetBIOS name to an IP address, the client stores this information in its NetBIOS name cache. By default, entries remain in cache for 600 seconds, and the cache holds only 16 names (configurable via the Registry). This makes the network more efficient, in that a client does not need to contact the network for every name resolution request. The reason for the low timeout is the fact that IP addresses may change due to the use of DHCP on the network. To view the NetBIOS name cache, use the nbtstat –c command.

LMHOSTS – This text file products a static way of mappings host names to IP addresses. A deeper look at LMHOSTS files follows later in this section.

Pages: 12