one size fits all:
stretching NetBIOS to fit the enterprise

by Christopher R. Hertel
<crh@nts.umn.edu>

(with thanks to Dan Shearer and the rest of the Samba Team) Chris Hertel is a network design engineer at the University of Minnesota. He has recently been added to Samba Team.

At the University of Minnesota the Network Design team of the Networking and Telecommunications Services Department is collaborating with the Samba Team on a set of enhancements to Samba's NetBIOS nameserver. The nameserver is critical to running CIFS over TCP/IP because it translates NetBIOS names into IP addresses so that CIFS clients can locate services on separate LANs.

[Editor's Note: The NetBios name service was originally specified in RFC 1001 and 1002. Microsoft's implementation is called WINS for "Windows Internet Name Server."]

Microsoft-compatible networks at the University of Minnesota are typically supported at the departmental level by local LAN administrators. Like small islands in a large sea, these CIFS LANs are cut off from one another. Each may have its own naming standards, security conventions, domain controllers, browse lists, workgroups, etc.

A while back, we realized that the first step toward unifying these CIFS islands was to provide a university-wide NetBIOS name service. Initially, the idea of installing such a service in a large, hostile, Internet-connected network was daunting at best. In addition to security and management concerns, we had doubts about the scalability of NetBIOS and Microsoft-compatible networking in general.

One particular issue was the desire among the LAN administrators and their users that the NetBIOS machine names would match the DNS Domain names. This correlation is assumed by CIFS implementations and is typically not a problem on smaller networks. At the University of Minnesota, however, there are 200 DNS subdomains that contain a few thousand duplicate hostnames (e.g., ethel.xx.umn.edu and ethel.yy.umn.edu). These duplications are not a problem in the hierarchical DNS because the names are in separate subdomains. Unfortunately, NetBIOS was not designed for large networks. NetBIOS nameservers expect all names to be unique, so it appeared that name collisions would be inevitable.

To resolve these issues, we knew that our NetBIOS name service would need capabilities beyond those in existing implementations. That meant writing our own code, which made Samba the logical choice. The software was robust, the installed base was large, the source code was available, and so were the authors! We found working with the Samba team to be easy and productive, and we soon came up with a list of enhancements that would benefit both the university and the Samba user community.

1. Performance tuning of Samba's name database. We needed a name database that would be capable of handling a large number of entries and thousands of transactions per minute. To achieve this goal, we wrote a new database module that makes better use of memory and is much faster. The code also allows alternative database modules to be added so that the nameserver can be adapted to meet different needs.
2. Access filters. The lack of access filters is a common security hole in NetBIOS nameservers. Without them, anyone on the network can query or add entries to the name list. (In our case, "the network" is the entire Internet.) The access filters are designed to allow or deny query or registration access based on IP address, DNS domain, or combinations of these and other criteria.
3. External references. An LMhosts file can be used to prime the name list with static entries. This is useful, but it means creating and maintaining a file that must be loaded every time the NetBIOS nameserver starts. We will supplement the LMhosts file by allowing Samba to use external sources as references. These might include databases, directory services, the DNS, or even other NetBIOS nameservers.
4. Replication. The university is made up of several campuses located across the state. We plan to deploy NetBIOS nameservers at strategic locations and replicate the names that are collected by each server. In this way, we will maintain a single set of NetBIOS names across the entire university. Client systems will be able to access the whole list from their local NetBIOS nameserver. Database replication will reduce traffic across WAN links, reduce delays, and provide database redundancy in the case of a network outage.

These features will give us the tools that we need for the creation of a university-wide service. For example, using access filters, external references, and a strict naming convention, we will be able to prevent name collisions in our NetBIOS namespace. Although our enhancements are designed to meet our own needs, they are general enough to be useful to any Samba administrator. Because we are working directly with the Samba Team, our code will be reviewed and merged into Samba, will continue to be enhanced, and will receive the same high-level support. There is a plan to get the database improvements into the next full release (1.9.18). Filters would be next, but have not been completed yet.