Winning Edge

Although in recent years Microsoft has attempted to place more emphasis on DNS, the reality is, if you work on a network with Windows systems, it is almost impossible to escape the NetBIOS protocol system.

NetBIOS helps clients locate resources and find login servers. To do this, it normally broadcasts to UDP port 137. Besides flooding the network with broadcast traffic, this approach doesn't work on routed networks. Routers do not forward broadcasts, so the request stays in the network segment where it started.

The Windows implementation of the NetBIOS name server, WINS (Windows Internet Name Service), resolved the issue by dynamically maintaining a database of NetBIOS names. Clients don't need to broadcast to reserve and resolve names; instead, they send UDP packets to the WINS server (Figure 1). In all versions of Windows, the administrator needs to set the WINS server IP address in the advanced section of the Wins tab below the TCP/IP protocol property settings. Administrators with Samba define the WINS server address by setting the wins server = IP address parameter in the [global] section of smb.conf. Routers will forward targeted UDP packets to the WINS server, and the presence of it reduces broadcast traffic.

To benefit the users of free operating systems, Sernet, a service provider heavily involved with the Samba project, launched the Samba4Wins project [1]. Samba4Wins replaces a Microsoft WINS server at a functional level and is perfectly capable of replicating data to other servers. It's part of Samba 4, but all services that are not required for a running WINS server are deactivated, such as Active Directory integration. Until the final Samba 4 release, when Samba packages will replace the Samba4Wins application, admins can run the Samba4Wins daemon parallel to Samba 3.0.21 or newer. Although you can run a WINS server without Samba4Wins, it offers no free software option for replicating with other WINS servers, and many complex networks need this ability.

Preventing Flooding

Samba4Wins source and binary packages are available for Debian derivates and the major enterprise distributions RHEL 4, SLES 9, and SLES 10 [1]. The servers can run parallel to an existing Samba installation as separate smbd4wins daemons.

The samba4wins.conf configuration file is located in the /etc/samba4wins/ directory. The developers recommend launching the server with the default settings (i.e., an empty file). If you set log level = 4, you can monitor what is going on inside the server. The samba4wins.conf configuration file also supports a number of parameters from Samba 3 that you might be familiar with (see Listing 1). If you are running Samba4Wins parallel to Samba 3, you need to set the nbtd:disable_broadcast option to yes to prevent Samba4Wins from responding to broadcasts on UDP port 137.

01 [globals]
02 netbios name = winssrv-01
03 workgroup = dbsys
04 interfaces = eth0
05 bind interfaces only = yes
06 log level = 4

The configuration parameters for a WINS replication partner are stored in a Samba LDB database, wins_config.ldb, which the server expects to find in the /var/lib/samba4wins/private/ directory. If you want to check or modify the entries in the database, use the ldbedit tool, which will open the database contents in your favorite editor so you can set the replication partners for your WINS server. To allow this, type:

cd /var/lib/samba4wins/private
ldbedit -H wins_config.ldb -a

The -H option passes in the LDB URL that the tool will connect with – a local file in this case. The -a at the end of the line tells the tool to edit all the records in the database. Incidentally, WINS uses LDIF syntax just like an LDAP server. LDIF (LDAP Data Interchange Format) is a text format for displaying LDAP directory content. The wins_config.ldb database on WinsSRV-02,

dn: CN=WinsSRV-01,CN=PARTNERS
objectClass: wreplPartner
address: 192.168.1.100

tells the WINS database to synchronize with a machine called WinsSRV-01 with IP address 192.168.1.100. The CN= PARTNERS name component tells the server to use the entry as a replication partner. Of course, you need to add similar replication entries on WinsSRV-01:

dn: CN=WinsSRV-02,CN=PARTNERS
objectClass: wreplPartner
address: 192.168.1.200

In this minimal configuration, both WINS servers act as pull and push partners (i.e., synchronization is bidirectional). The samba 4wins-1.0.7- HOWTO.txt file on the download server has other useful information (e.g., on networking, load balancing, and timeouts) and more configuration options. The ldbsearch command lets you save the final configuration:

cd /var/lib/samba4wins/private
 ldbsearch -H wins_config.ldbobjectClass=\*> /backup/wins_config-backup.ldif

The command searches the wins_config.ldb database for records that match the objectClass=* condition and redirects the output to a file called /backup/wins_config-backup.ldif. The ldbadd command (Listing 2) lets you restore the LDIF-formatted configuration backup to the LDB database.

01 cd /var/lib/samba4wins/private
02 ldbadd -H wins_config.ldb < \
03 /backup/winssrv-01_backup.ldif
04 Added 1 records with 0 failures

Through use of the same approach, you can back up the WINS database in /var/lib/samba4wins/wins_config.ldb (see Listing 2). After completing the configuration and starting the daemon on both servers – by typing /etc/init.d/smbd4wins start or samba4wins, depending on your distribution – you can monitor replication via TCP port 42 with the Wireshark sniffer (see Figure 2). The tool includes the Winsrepl dissector, which visualizes the protocol [2].

Winning Names

The nmblookup diagnostics tool helps you query the two WINS databases. Figure 3 shows the tool querying the server at 192.168.1.100 for the name sabaki. (Incidentally, Samba's NetBIOS tools are not case sensitive.) To test the replicated database, run the nmblookup against the second WINS server.

If everything is working properly, the results should be identical, apart from the fact that the server IPs will differ. The ldbsearch referred to earlier also returns registered names in LDIF format. Users can either retrieve all entries by querying for objectClass=winsRecord or enter an appropriate query to restrict the search to specific resource types.

Resource Types

The resource type is the 16th byte in a NetBIOS name. In Windows, the resource type is typically represented as a hexadecimal sequence, often following the name and enclosed in angle brackets. This suffix lets applications reserve names without getting in each other's way. For example, the 0x03 suffix stands for a message service. If a machine offers file or print services, the client can use the NetBIOS name registered with the 0x20 type field to set up a connection to the server. For more details on resource types, refer to the Microsoft Knowledge Base [3].

If you prefer, you can also search the LDB for name records by specifying the name=NetBIOS name option. This option supports typing the NetBIOS name in capital letters (Listing 3).

01 01 # record 1
02 02 dn: name=SABAKI,type=0x20
03 03 type: 0x20
04 04 name: SABAKI
05 05 objectClass: winsRecord
06 [...]
07 10 expireTime: 20090120004152.0Z
08 11 versionID: 6
09 12 winsOwner: 192.168.1.100
10 13 address: 192.168.1.83;winsOwner:192.168.1.100;expireTime:20090120004152.0Z;
11 14 distinguishedName: name=SABAKI,type=0x20
12 [...]

Samba4Wins signals the end of Redmond's monopoly on WINS server replication and the end of the Linux administrator's fear of relying on a single WINS server.