Samba makes a fine file and print server for Windows clients, as described in the previous chapter. Samba's capabilities go further than that, though; the software can also take on many of the ancillary roles on a NetBIOS LAN. Many of these duties are associated with NT domain controllers. Domain controllers are basically centralized logon databases for systems on a NetBIOS network; servers consult the domain controller when asked to authenticate users. This topic is first up in this chapter. A couple of additional roles that are often associated with domain controllers, but can exist even in a nondomain configuration, are described next: providing NetBIOS name resolution services and collecting browse lists for delivery to clients. Finally, this chapter concludes with a look at configuring Windows clients to use these features of a Samba server.

Tip

A domain controller can serve as an authentication tool for both Windows and Linux clients. In fact, you can use a Linux computer running Samba as an authentication server for other Linux computers. To do so, you must configure the Samba domain controller features, as described in Section 5.1; the Linux client configuration is described in Chapter 7.

Linux can make an excellent NT domain controller on a Windows network for many of the same reasons that Linux is an excellent platform for other network roles: Linux is reliable, less vulnerable to security problems than Windows, and low in cost. Samba is also more flexible than Windows in certain domain control details; you can set many options individually that aren't available or that are linked to other options in Windows. On the other hand, Linux and Samba don't yet implement full Active Directory (AD) domain controller support, only the older NT domain support. (Linux can function on an AD network, but it can't function as an AD controller.)

Enabling Domain Controller Functions

Samba's domain control features enable it to provide authentication services for Windows 9x/Me, Windows NT/200x/XP, Linux, and various other operating systems. Used in this way, the domain controller client (which may itself be a server to other computers) uses the account database on the domain controller to authenticate users. In order to support this functionality, Samba requires that you set a few smb.conf parameters. This part of the domain controller configuration isn't the tough part, though; you must also maintain an encrypted password database for your users and also keep machine trust accounts , which enable Samba to authenticate the machines that are asking for authentication services. Many domain controllers also deliver a few special share types, which you might want to configure on your domain controller.

The Role of a Domain Controller

An NT domain controller serves as a backend for authentication requests directed at an SMB/CIFS server, as illustrated by Figure 5-1. Samba servers can actually take on the role of the NT domain controller, the SMB/CIFS server (a.k.a. the domain member server ), or both systems. Linux or other Samba-using systems can also function as SMB/CIFS clients, as described in Chapter 6.

Figure 5-1 most accurately depicts one of two major authentication methods supported by NT domain controllers and Samba. Specifically, this figure depicts pass-through authentication , which is used by Windows 9x/Me domain members and Samba file servers when you set security=Server in their smb.conf files. Even in this case, Figure 5-1 presents a simplified view of the exchanges involved. Windows NT/200x/XP computers and Samba servers configured with security=Domain use a more complex arrangement, known as NetLogon authentication , in which the domain member server contacts the domain controller and obtains enough information from the domain controller to authenticate users itself, using data from the domain controller, rather than a local password file. Both systems look the same to SMB/CIFS clients. In fact, from the client's point of view, these systems are also indistinguishable from one in which servers use local authentication databases.

Not all Windows networks use domain configurations. Simpler networks use workgroup configuration, which are essentially NT domains without domain controllers. Workgroups are easier to configure, but they're missing some of the features provided by domain controllers, such as the ability to use a central authentication database and to store local user configurations on a central server.

The advantage of a domain configuration, at least in terms of authentication, is that you need to maintain a user password database only on one system. Consider a network with half a dozen SMB/CIFS servers. If your users had to maintain separate passwords on all these servers, they'd either never change them or they'd forget all the different passwords. Your system administration task would also be more difficult in this case, because you'd need to explicitly create and delete accounts on all six servers. In a domain configuration, though, only one password database needs to be maintained, which greatly simplifies administration and users' own account maintenance tasks.

Tip

Samba domain member server computers must maintain local Linux user accounts as well as Samba passwords (or defer to a domain controller for the latter). Thus, the administration benefits of a domain configuration are somewhat lower for Samba than for Windows SMB/CIFS servers—at least, unless you take additional steps. As described in Chapter 7, you can configure Linux to use an NT domain controller for the Linux account database. This can be more effort to set up but will reduce long-term administrative effort if your network hosts several Samba servers or if you want to integrate Linux and Windows accounts into one system. Alternatively, you can point the global add userscript parameter to a script that creates an account for users who are authenticated by the domain controller but who don't already have local accounts. For instance, setting adduserscript=useradd-m%u in the [global] section of smb.conf may do the trick, although you may want to write a script that does more than this.

Frequently, the domain controller serves as a file and print server, in addition to functioning as a domain controller. This part of the Samba domain controller configuration is described in Chapter 4. It also delivers other NetBIOS functions on the LAN; specifically, it typically functions as a NetBIOS name server and as a domain master browser. These duties are described in Section 5.2 and Section 5.3.

Domain Controller Parameters

In order to function as a domain controller, Samba must be configured with certain options set in its smb.conf file's [global] section.

security=User

This parameter, described in Chapter 3, sets the local authentication system. Because the domain controller serves as an authentication tool for other servers, user-level security is appropriate for the domain controller. Setting this parameter incorrectly causes the domain controller to function incorrectly.

encryptpasswords=Yes

You must tell Samba to use encrypted passwords; if you don't, it won't be able to parse the encrypted password exchange initiated by domain member servers. On a domain controller, this setting also requires you to maintain a local encrypted password database, as described in the next section.

passdbbackend

This parameter specifies how Samba is to store its password database. The default value, smbpasswd, is simple and easy to administer compared to the alternatives, but it tends to be slow. This speed problem is extremely minor for networks with a few dozen, or even over a hundred, users. If your network has many hundreds or thousands of users, though, you may want to look into alternatives, such as tdbsam and ldapsam. These alternatives also support additional features, such as the ability to deliver time-based restrictions on user access. These alternatives require additional configuration, though, and such configuration is beyond the scope of this book.

domainlogons=Yes

This parameter is the defining one for a domain controller; it tells Samba to accept remote logon requests. The default value is No, so be sure to change it on your domain controller. Conversely, be sure not to change it on domain member servers and clients.

In addition to setting these parameters, you should be sure not to set the password server parameter. This parameter tells a Samba domain member server where the domain controller is, so it isn't needed for a domain controller. In fact, setting it can cause confusion because you're telling Samba to do two contradictory things—function as a domain controller and function as a domain member server.

Tip

Because most domain controllers also take on name server and master browser duties, you must also set smb.conf parameters related to these functions, as described later in this chapter.

Maintaining the Password Database

Fortunately, maintaining the password database on a domain controller isn't much different from maintaining a password database on an isolated Samba server that uses local (user-level) authentication. This task is described in more detail in Chapter 3.

One point that deserves reiteration is that Samba's password database, whether for an isolated server or a domain controller, relies upon corresponding entries in an underlying Linux account database. Thus, you must maintain both Linux and Samba accounts on the system, and they must match. Normally this means that the usernames must be identical for both systems, although you can use the username map parameter and the mapping file to which it points to link together dissimilar usernames. This requirement also exists on Samba domain member servers, although you can use Winbind on them so that the domain controller provides the basis for the Linux accounts, if you like. (This topic is covered in Chapter 7.) Alternatively, domain member servers can set the add user script to add accounts automatically when the user authenticates and no matching Linux account exists. Windows servers can use the domain controller exclusively, as described in the Section 5.1.6.

Perhaps the toughest challenge in maintaining the password database relates to actual maintenance—adding and deleting users, enabling users to change their passwords, and so on. This task, although easy on a user-by-user basis, can become a time-consuming chore on larger networks. Fortunately, several procedures can help minimize the effort required to handle this task:

Adding users

If you add users on a regular basis, you can write a simple shell script that adds both Linux and Samba accounts at once. Something as simple as Example 5-1 might serve well. This example requires you to type users' passwords twice, though, at least if they should have access to the server system both through Samba and through some other means. A more complex script can disable the Linux account for non-Samba logins, prompt for a password and deliver it to both useradd and smbpasswd, or otherwise work in a way that's suitable for your network.

Example 5-1. Sample script for adding Linux and Samba users

#!/bin/bash
useradd -m $1
passwd $1
smbpasswd -a $1

Deleting users

As with adding users, you should be sure to delete both the Samba and the Linux accounts when you do this. If you forget to delete the Linux account, users who should no longer have access to the server might be able to get in. A simple script that calls userdel and smbpasswd with appropriate options can help on this score.

Changing user passwords

You can enable users to change their passwords several ways. One grants users shell access to the Linux domain controller, in which case they can call smbpasswd themselves. If users shouldn't have shell access to the server, access to another Linux system can do as well; passing the -r parameter and a machine name causes smbpasswd to change the password on the specified remote system. Setting users' login shells to smbpasswd is another way to let them change their passwords; they can log in using Secure Shell (SSH), Telnet, or even console access, and they'll immediately be prompted to change their passwords. The Samba Web Administration Tool (SWAT) is another way to enable users to change their passwords. When users access this server with a web browser, they can change their Samba passwords. SWAT doesn't support encryption, though, which is a potentially important limitation.

Synchronizing Linux and Samba passwords

Keeping Linux and Samba passwords synchronized can be a tricky proposition. Setting the global Samba unixpasswordsync parameter to Yes can help. This setting requires one of two additional options, though. One is the pampasswordchange parameter, which should be set to Yes. Instead of setting pampasswordchange=Yes, you can set passwdprogram to specify the local password-changing program, and set passwdchat to a chat script that controls the password-changing exchange.

When creating or modifying Linux accounts, remember to consider Linux groups. Depending on your shares' security settings and your overall server security policy, you may need to specify particular groups for your users. This detail is highly site-specific, though. If you don't specify a group, chances are the group will be either users or a group created specifically for the user you've added, depending on your Linux distribution.

Configuring Machine Trust Accounts

As noted earlier, Samba supports two methods of interacting with domain member servers: pass-through authentication and NetLogon authentication. (Technically, systems that use pass-through authentication aren't domain member servers, but they fill the same role in the network as a whole, so I don't try to draw a distinction in this chapter.) Windows 9x/Me servers and Linux servers configured with security=Server use pass-through authentication. If your network contains nothing but such servers, you can safely skip this section. Windows NT/200x/XP servers and Samba servers configured with security=Domain, though, use the NetLogon authentication method. This method requires that servers have accounts on the domain controller. Thus, to support such servers, you must create appropriate accounts, which are known as machine trust accounts.

Tip

Technically, machine trust accounts are required only by servers; however, many Windows NT/200x/XP systems configured as clients try to use these accounts when you log onto them. Thus, you may need to create these accounts for all your Windows systems.

Like ordinary user accounts, machine trust accounts must exist both in the underlying Linux account database and in Samba. The Samba-side accounts are created in a semiautomated way once certain Samba options are set, though.

Typically, you create a special Linux group to hold the Linux-side machine trust accounts. For instance, you might call the group trust:

# groupadd trust

You should then create Linux-side accounts for all the domain member servers and any clients that you expect to require such accounts. These accounts are named after the computers' NetBIOS names, but they are in lowercase and with dollar signs ($) appended to the names. For instance, you'd create an account called tulip$ for the computer whose NetBIOS name is TULIP. These accounts would be members of the machine trust group you created. They can also be non-login accounts, so they can be configured to refuse logins. A command to add such an account might look like this:

# useradd -g trust -d /tmp -s /bin/false tulip$

This command creates a new account (tulip$) in the test group (-g test) using the /tmp directory as the account's home directory (-d /tmp) and /bin/false as the default shell (-s /bin/false). Some of these parameters, such as setting the default shell to /bin/false, provide an extra measure of security. Of course, you may want to tweak these options for your local system's requirements.

If you must add many machine trust accounts, you can streamline the process by placing the command in the [global] section of smb.conf, using the addmachinescript parameter:

add machine script = useradd -g trust -d /tmp -s /bin/false %u

This parameter enables Samba to create a machine trust account itself when a machine attempts to join the domain. The joining machine must present appropriate authentication first, though—presumably indicating that you or another authorized administrator is sitting at its console.

Once you add the Linux-side machine trust accounts, you should configure an administrative user. You can either add root to the list of Samba user accounts (a potentially risky proposition), or you can specify an administrative user with the adminusers parameter in the [global] section of smb.conf: adminusers=linnaeus. This user then has root privileges when accessing the server.

Tip

For added security, comment out the adminusers line when you don't need it, and specify an account you don't normally use for this purpose. That way, the risks of system compromise due to a compromise of this account are minimized. You can reduce the risk of using the root account if you employ that approach, using different Samba and Linux passwords for root.

Once these tasks are accomplished, Samba begins accepting domain member server requests to be added to the domain. This process is described in Section 5.1.6, for Windows systems, and in Chapter 7, for Linux systems.

Common Domain Controller File Shares

NT domain controllers can and often do function as ordinary file and print servers, in addition to handling domain logons. If you want to configure home shares, file-exchange shares, and the like, consult Chapter 4. However, a couple of shares are common to domain controllers: domain logon shares and roaming profile shares. The former deliver domain logon scripts to clients, enabling you to provide consistent environments to all domain members. The latter enable you to store user desktop settings (icon placement, theme selections, and so on) on the domain controller, which can help provide users with consistent settings in environments in which users frequently move from one physical computer to another.

Tip

The roaming profile share is optional. Although some documentation refers to the netlogon share as required, in practice, the domain controller can function without one. These shares both provide functionality that's important for some domains, though.

Configuring domain logon shares

A domain logon script is a Windows script (a.k.a. a batch file) that the Windows client retrieves and runs automatically when a user logs onto the computer. Clients retrieve these scripts from a share called NETLOGON , so if you want to use this feature, you must create this share:

This share definition is fairly ordinary; it's a typical read-only file share, but with a user appointed with write privileges. The unusual feature of the share is actually defined in the [global] section of smb.conf, with a pointer to the logon script's filename:

logon script = LOGON.BAT

This line tells Samba to deliver the LOGON.BAT file from the NETLOGON share to clients when they log on. Note that you can use Samba's variables to deliver different logon scripts to different clients. For instance, specifying LOGON-%a.BAT tells Samba to deliver files with the clients' OS codes in the filenames, such as LOGON-Win95.BAT for Windows 9x/Me systems or LOGON-Win2K.BAT for Windows 2000 systems.

What should go in domain logon scripts, though? Anything you want. These scripts are Windows batch files, so you can run any command accessible on all the Windows client computers (or on any network share accessible to them). A simple example might set the systems' clocks and open users' home directories:

NET TIME \\TULIP /SET /YES
NET USE M: \\TULIP\HOMES /YES
EXPLORER M:

This example uses the NET command on Windows to set the time and mount the HOMES share from the TULIP server, then launch the Windows EXPLORER file manager on the share. You can do more or less, though; it's up to you.

Configuring roaming profiles

Normally, Windows stores users' preferences for user interface settings like icon placement and window themes on the local hard disk. This configuration works perfectly well on networks whose users generally have their own systems, such as office workers who have their own offices or cubicles. In other environments, though, users may regularly move from one computer to another—for instance, in a college computer center. In such cases, roaming profiles are handy. These enable users to store their personalized settings on the domain controller, so that they appear on whatever client they use, even if a user has never used a particular computer before.

Unfortunately, roaming profiles work slightly differently for Windows 9x/Me as opposed to Windows NT/200x/XP systems. (They're also completely unavailable for Windows XP Home systems, which technically can't participate in domains, although they can treat a domain as a workgroup.) To support Windows 9x/Me systems, Samba uses the global logonhome parameter, which typically points to a subdirectory of the user's home directory:

logon home = \\%L\%U\.roamingprofile

This parameter specifies a Windows-style share locator (note the backslashes in the path). In this example, %L expands to the server's own name, and %U expands to the user's username; thus, this example should point to the .roamingprofile subdirectory in the user's home directory.

Windows NT/200x/XP requires a somewhat different definition. This is provided by a global parameter called logon path:

logon path = \\%L\PROFILES\%U\%a

This definition requires that a share called PROFILES exist on your server. The logon path includes the %a variable, which expands to the OS name, because Windows NT, 2000, and XP profiles aren't interchangeable. The profile share can be a fairly ordinary file-storage share, but for security purposes, it's best to set createmode and directorymode to fairly restrictive values:

The share directory itself (/usr/share/samba/profiles in this example) must be writeable to all users; if it's not, users can't create their roaming profiles. In theory, you can point Windows NT/200x/XP systems to a subdirectory of users' home shares; however, Windows NT/200x/XP doesn't always completely disconnect from shares when users log out, which can complicate such an arrangement.

Configuring Windows Clients and Servers as Domain Members

Configuring Samba as a domain controller won't do any good unless you also configure computers as members of the domain. In theory, only domain member servers need to be so configured; however, in practice, clients may need to be configured in this way, too. Precisely how you accomplish this goal varies with the OS you're using. In particular, Windows 9x/Me and Windows NT/200x/XP have different domain membership requirements and options.

Tip

Samba servers can also join domains, as described in Chapter 3. To use a domain controller as a way to control non-Samba access to a Linux system, consult Chapter 7.

Activating Windows 9x/Me domain membership

Ordinarily, when a Windows 9x/Me system is configured to use a workgroup, it presents a logon screen with a two-field logon prompt, as shown in Figure 5-2. This logon screen provides no real security, though; clicking Cancel bypasses the logon screen and gives you full local access to the computer. This screen merely provides a way for Windows to cache your username and password for network accesses. Switching to a domain configuration won't change this lack of security.

Configuring Windows 9x/Me systems as just described doesn't improve security or change the system's logon procedures. It does, however, tell the Windows client to use a domain logon script, if you've configured your domain controller to provide one. It also enables the client to use roaming profiles, although extra configuration steps are required to actually use them.

Double-click the Passwords item in the Control Panel. Windows displays the Passwords Properties dialog box.

Click the User Profiles tab in the Passwords Properties dialog box.

Click the Users Can Customize Their Preferences... radio button in the Passwords Properties dialog box. This action tells Windows to store different desktops for each user. In a domain configuration in which the domain controller supports roaming profiles, these are stored on the domain controller.

Click OK. Windows informs you that it must reboot. Do so.

When Windows starts up again and you log on, the system tells you that you haven't logged on before. Click Yes to tell Windows to create the roaming profile.

Ordinarily, Windows 9x/Me assigns passwords to any drives you share, using share-level security. Once you've configured a Windows 9x/Me system as a member of a domain, though, you can tell it to defer to the domain controller for authenticating its share access:

Open the Network icon in the Control Panel. The result is the Network dialog box.

Click the Access Control tab in the Network dialog box.

Click the User-Level Access Control radio button.

Enter the name of your domain in the "Obtain List of Users and Groups From" field.

Click Yes in the warning dialog box. You'll then be asked to restart the computer. Do so.

After making this change, you'll need to redo your sharing configuration. The changes add the ability to specify user-based access control, so you can grant or deny access to the share to particular users.

Activating Windows NT/200x/XP domain membership

Windows 9x/Me systems use the pass-through authentication protocol, whereas Windows NT/200x/XP uses NetLogon authentication. For this reason, Windows NT/200x/XP systems require that you prepare a machine trust account on the domain controller, as described in the earlier Section 5.1.4, before you add the computer to the domain. (Windows XP Home doesn't support domain configurations, though, so you can't configure it this way. You can only treat a domain as if it were a workgroup from Windows XP Home.) Once you've created domain trust accounts on the domain controller, you can add a computer to the domain as follows:

Log onto the Windows system as Administrator. Don't open any shares on the domain controller.

Open the System object in the Control Panel. Windows should display the System Properties dialog box.

Click the tab called Network Identification or Computer Name, depending on the version of Windows you're running.

Click the Properties or Change button. Windows should display the Identification Changes or Computer Name Changes dialog box shown in Figure 5-5.

Figure 5-5. Windows NT/200x/XP lets you set the computer's name and its workgroup or domain affiliation in a single dialog box

If it's not already set, enter the computer's NetBIOS name in the "Computer name" field.

Click Domain in the "Member of area," and enter the name of the NT domain. If the computer is configured as a member of a workgroup of the same name as the domain you enter, Windows may complain. If this happens, try changing the workgroup name to a fictitious one, reboot, and start again.

Click OK in the Identification Changes dialog box. Windows opens a dialog box asking for a username and password.

Enter the username of the administrative user you specified with adminusers on the Samba domain controller, along with the associated password. After you do this, you should see a message welcoming you to the domain and a notice that you must reboot the computer.

Dismiss the dialog boxes, and reboot the computer.

After you've made these changes and rebooted, Windows displays a new three-field logon window similar to the one shown in Figure 5-4. (Some versions of Windows NT/200x/XP differ in certain details; in fact, some hide the third logon field in an advanced options area.) Unlike the Windows 9x/Me logon screen, the Windows NT/200x/XP logon screen provides real security; you can't simply click Cancel to gain access to the computer without a password. You may want to bypass the domain authentication, though, and use the system's local account database. This is particularly handy when performing administrative tasks as the Administrator. To do so, select the computer's name rather than the domain name in the new Log On To field at the bottom of the logon prompt.

Windows should automatically use the domain controller for authentication when users try to access shares on a Windows NT/200x/XP server; thus, you shouldn't need to reconfigure the system to use the domain controller, as you do with Windows 9x/Me systems. Recent versions of Windows NT/200x/XP also use roaming profiles by default in a domain configuration. If you want to reconfigure a client to use local profiles instead, follow these steps:

Right-click My Computer on the desktop or in the Start menu and select Properties from the resulting context menu. The System Properties dialog box should appear in response.

In Windows 2000, select the User Profiles tab. In Windows 2003 or XP, select the Advanced tab and then click the Settings button in the User Profiles area. The result is a User Profiles dialog box or tab, as shown in Figure 5-6.

Figure 5-6. The Windows NT/200x/XP User Profiles selection dialog

Double-click the line for the account you want to modify. (Figure 5-6 shows just one account, for Administrator on NESSUS.) A Change Profile Type dialog box appears, enabling you to select a roaming or a local profile.

Click the profile type you want to set in the Change Profile Type dialog box, and then click OK in all the open dialog boxes.

Enabling NBNS Functions

Name resolution—converting computer names into IP addresses—is a problem that must be solved with any networking system. NetBIOS supports several methods of name resolution. One of these, the use of a NetBIOS Name Server (NBNS) system, is often associated with running a domain controller, although you don't need a domain configuration to use NBNS. Naturally, Samba can function as an NBNS system. Doing so requires setting just a couple of Samba options; the rest is fairly automatic, from Samba's perspective. Client configuration may be another matter, though; you must know how to tell clients to use the NBNS system.

The Role of the NBNS System

NetBIOS and Samba support several methods of name resolution, as described in Chapter 3. The simplest of these to configure is broadcast name resolution , in which computers needing to contact other computers broadcast the names, and the so-named computers respond to these broadcasts. Windows systems use broadcast name resolution by default. Broadcasts work well on small networks with just one subnet, but in a multisubnet configuration, broadcasts are typically blocked at the routers between subnets. Thus, other methods are used in such situations.

One type of solution to this problem is to use an NBNS computer. The NBNS system fills a role similar to that of a DNS server, but the NBNS system is specific to NetBIOS name resolution. It listens for name registrations from clients, caches them, and then delivers those names to other clients who ask for them. Because clients are told where to find NBNS systems, broadcasts aren't needed in NBNS-based name resolution. This means that NBNS is a superior name resolution system when a network spans multiple subnets.

NBNS-based name resolution is designed to work in a conceptually similar way to broadcast name resolution, in that clients register the names they want to use. Unlike a DNS server (described in Chapter 15), there's no need to explicitly tell an NBNS system about the names or IP addresses it's to share. If your network uses the Dynamic Host Configuration Protocol (DHCP) to deliver IP addresses to computers, they may change from time to time. An NBNS system automatically tracks these changes.

Tip

You can configure Linux to use an NBNS system or broadcast NetBIOS name resolution (instead of or, more commonly, in addition to DNS) even for non-Samba name resolution. This can be a convenient way to get name resolution working on a network on which IP addresses are likely to change from time to time. This topic is covered in Chapter 6.

Defining Samba NBNS Functions

Because the name resolution features of SMB/CIFS, including NBNS functions, were designed to work fairly automatically, Samba provides relatively few options related to these features. Only one option is required to activate NBNS features, although a few more will help fine-tune the operation:

winssupport

This global Boolean parameter controls NBNS functions. (Microsoft refers to the NBNS features as the Windows Internet Name Service, or WINS, hence the parameter name.) This option defaults to No; setting it to Yes causes Samba to function as an NBNS system.

winsproxy

This global Boolean parameter tells Samba whether it should respond to broadcast name resolution requests on behalf of its NBNS clients. The default value is No, which is usually fine, but sometimes setting it to Yes improves the reliability of name resolution; try that if you're having problems.

dnsproxy

Ordinarily, the NetBIOS and DNS name spaces are logically distinct, although most administrators prefer to use the same names for specific computers in both spaces to avoid confusion. If you specify dnsproxy=Yes (the default is No), though, Samba configured as an NBNS system will perform DNS lookups on any names it can't resolve using its NBNS name cache. This practice can improve reliability in some cases, but it can also slow down lookups, particularly if the DNS server is slow. This feature only works for lookups of file and print servers, though, not for lookups of other types of systems, such as domain controllers.

Warning

If you set winssupport=Yes, be sure not to set the winsserver parameter (described in Chapter 3). This parameter tells Samba what computer to refer to as an NBNS system. Ordinarily, an NBNS system automatically uses itself in this role, so specifying both parameters will likely result in malfunctions.

Overall, the NBNS system only needs to have winssupport=Yes set; additional options just tweak the operation of the server. You should set this option on one server only; configuring multiple servers as NBNS systems is likely to cause confusion unless they can communicate with one another, which Samba doesn't support—at least as of the early 3.0.x versions. If two different clients are configured to use two different NBNS servers, they won't be able to locate each other via these servers, and possibly not at all if they aren't configured to use broadcasts as fallback or if they aren't on the same subnet.

Delivering NBNS Information via DHCP

Just as with DNS, the clients of NBNS systems must know how to contact their servers. Also just as with DNS, this task is accomplished by giving the clients the IP addresses of their servers. You can do this by entering the information on each client manually, but if your network uses DHCP, a simpler solution is to deliver the information via DHCP. (Even in this case, some client configuration may be necessary.)

Tip

In Linux, you specify the NBNS system using Samba's winsserver parameter, as described in Chapter 3. This is true even if you use DHCP to configure the Linux system.

DHCP server configuration

If your network uses DHCP for assigning IP addresses to Windows systems, the simplest way to configure those systems to use your NBNS system is to deliver the information via DHCP. Doing so requires modifying your DHCP server's configuration, though. Chapter 15 describes DHCP configuration generally, so you should consult that chapter first if you need to get your DHCP system operational. This section assumes you're using the Internet Software Consortium's (ISC) DHCP server, which is the most common one on Linux systems. Its configuration file is usually called /etc/dhcpd.conf, although it's likely to be stored in /usr/local/etc if you compile it from source rather than install it via a package for your Linux distribution.

Tip

Don't confuse the ISC DHCP server, dhcpd, with the ISC DHCP client, dhcpcd. The one-letter difference in the daemons' names, and similar differences in their configuration filenames, can be easy to overlook.

The /etc/dhcpd.conf file is composed of several parts. At the top of the file are a series of global options. Chances are you'll include the NBNS options with these. The configuration file is likely to contain one or more declarations for particular subnets, which begin with the subnet keyword and include options for the subnet within lines delimited by curly braces ({ }). If you want to configure different NBNS servers for separate domains on different subnets, you can place the configuration options within these subnet declarations. In any event, to point DHCP clients at your NBNS system, add these lines:

option netbios-name-servers 192.168.1.1;
option netbios-node-type 8;

The first of these options specifies the IP addresses of your NetBIOS name servers. You would change the IP address as appropriate for your network, of course. Although the ISC DHCP server supports delivering multiple NBNS addresses (separated by commas), you're likely to deliver one only if you use Samba as an NBNS system, because Samba doesn't yet support exchanging NetBIOS name information with other Samba servers, so you're effectively limited to one NBNS system.

The netbios-node-type option specifies a code for the order in which the client attempts various lookup methods. Specifically, passing 1 as this value tells clients to use broadcasts alone; 2 means to use the NBNS system alone; 4 means to try broadcasts first and then to try the NBNS system if the broadcast fails; and 8 means to try the NBNS system and then to use broadcasts if the NBNS attempt fails. In most cases, 8 is the appropriate option.

Once you've made these changes, you need to restart the DHCP server. In most cases, passing restart to a SysV startup script, as in /etc/init.d/dhcpd restart, does the trick.

Windows client configuration

Unless they're told otherwise, Windows clients use broadcast name resolution by default. Even if you configure DHCP to deliver NBNS information to clients, Windows 9x/Me systems ignore this information by default, so you must make a change to such systems' configurations to have them use DHCP-provided information. Windows NT/200x/XP, though, uses DHCP-provided information by default. Thus, you may not need to change these clients' configurations if you configure a DHCP server to deliver NBNS information.

Tip

If your network is dominated by older Windows 9x/Me systems, you might think that using DHCP to deliver NBNS information is pointless because you must reconfigure clients to use this information. Using DHCP does have certain advantages, though. For one thing, you can't mistype the IP address on a client, so misconfiguration of individual systems is less likely. Another advantage of using DHCP is that you can easily change the configuration of all clients merely by changing the server, should the NBNS system's IP address ever change.

To set NBNS information in a Windows 9x/Me client, follow these steps:

Open the Control Panel, and double-click the Network icon. Windows should display a Network dialog box in which you can select various drivers, network stacks, and so on.

Click the WINS Configuration tab in the TCP/IP Properties dialog box. The result should resemble Figure 5-7.

Figure 5-7. Windows 9x/Me lets you disable an NBNS system, specify an NBNS system explicitly, or obtain the information from a DHCP server

If you don't want the client to obtain information from a DHCP server, click the Enable WINS Resolution radio button, enter the IP address for your NBNS system in the WINS Server Search Order box, and click Add.

If you want to have Windows obtain information from the DHCP server, click the "Use DHCP for WINS Resolution" radio button.

Click OK in the TCP/IP Properties dialog box and then in the Network dialog box.

Windows must be restarted for the changes to take effect, and it should prompt you to do so. After the restart, Windows should use your NBNS system for name resolution.

If you use Windows NT 4.0, the method of setting the NBNS system is similar to that in Windows 9x/Me, although there are a few differences. For instance, you must select the tab called WINS Address rather than WINS Configuration, and the field in which you enter an NBNS system's IP address is configured slightly differently.

Windows 200x and XP use a substantially different way to specify NBNS information. These OSs use the information delivered by the DHCP server by default, so you shouldn't need to adjust them if you use this method. If you must specify IP addresses explicitly, though, you can do so:

Open the Control Panel, and then open the Network and Dial-Up Connections (Windows 2000) or Network Connections (Windows XP) object in the Control Panel.

Right-click the Local Area Connections object. This action produces a context menu, in which you should select the Properties item. Windows should now display a Local Area Connection Properties dialog box.

In the Local Area Connection Properties dialog box, select the Internet Protocol (TCP/IP) component and click the Properties button. This action should bring up a new dialog box called Internet Protocol (TCP/IP) Properties.

In the Advanced TCP/IP Settings dialog box, click the WINS tab. The result should resemble Figure 5-8, although chances are no addresses will appear in the address list. (Some details are different in the Windows 2000 version of this dialog box; Figure 5-8 was taken on a Windows XP system.)

Assuming Master Browser Duties

Windows networks use a system known as the master browser to help maintain browse lists—lists of computers, the workgroups or domains to which they belong, and the types of services they offer. This may sound a lot like the duty of the NBNS system, but it's not quite the same. The master browser's list doesn't include mappings to IP addresses; it's used by clients to present lists of computers on the local network in network browsers.

In fact, there are two types of master browser: the domain master browser and the local master browser . The domain master browser is most often associated with networks that use an NT domain configuration, and in such configurations, the domain controller takes on this role. If you use a workgroup configuration, chances are you won't have a domain master browser. All NetBIOS networks have local master browsers, though. Samba provides configuration options that affect its ability to function in both roles.

The Role of the Master Browser

Master browsers maintain lists of computers and the services they offer. In this context, services refers to the types of SMB/CIFS duties they perform, such as file server, NBNS system, and so on. Master browsers don't maintain lists of the specific shares offered on particular servers; for that detail, clients must contact the servers themselves.

As mentioned earlier, two types of master browsers exist: local master browsers and domain master browsers. Domain master browsers normally also function as local master browsers. Both types deliver basically the same information, but domain master browsers add more methods of operation.

Local master browsers serve just one subnet on a LAN. The computers on a single subnet automatically determine which system is to function as the local master browser via an election , in which each computer broadcasts a set of credentials to the entire subnet, and the system with the best credentials claims victory. Because of this automatic selection system, you can't simply set a Samba parameter or two and be sure the system will become a local master browser. You can, however, set Samba parameters that will make it more or less likely to win—ideally, so likely to win that it's all but a sure thing, if that's what you desire. You can also tell Samba not to participate in elections, if you like. The next section describes configuring a system to win or lose local master browser elections.

Domain master browsers integrate information from local master browsers on multiple subnets, providing a way to enable browsing across subnets. They're usually part of an NT domain configuration, although you can configure a domain master browser in a workgroup. You must explicitly configure one computer as a domain master browser; they aren't selected through an election process. The Section 5.3.3 describes how to do this.

No client-side configuration is required to point clients at either type of master browser. Clients should be able to find local master browsers by using broadcasts. Domain master browsers can be found via any NetBIOS name lookup method.

Winning (or Not Winning) Local Master Browser Elections

The local master browser election process is designed to give local master browser status to the computer that's best able to handle this duty. Election criteria include the OS version, whether the computer is functioning as a domain controller, whether the computer is functioning as an NBNS system, and so on. The most important factor is the OS version, so adjusting this detail is a critical step in "rigging" an election that you want a Samba server to win. Several other factors are important as well, though. Overall, you should consider these global parameters:

localmaster

This Boolean parameter tells Samba whether it should participate in local master browser elections. The default value is Yes, so you should change this parameter only if you want to ensure that a server doesn't become the local master browser.

oslevel

This parameter sets the OS version. It takes an integer as a value, with higher values making the server more likely to win. OS levels for Microsoft OSs vary; for instance, Windows 9x/Me is 1, Windows 2000 Professional is 16, and Windows 2000 Server is 32—the highest value of any Microsoft OS, at least as of late 2004. Samba's default oslevel is 20, so Samba will win over Windows 9x/Me or Windows 2000 Professional by default, but it will lose against Windows 2000 Server. If you want Samba to acquire local master browser status, you should set this value to 33 or above. If your network contains only one Samba server, any value above 32 should work fine. Inexpertly managed Samba servers may have higher values set by mistake, though, so you may need to use a higher value. This may also be necessary to win against future versions of Windows or other OSs. The highest value this parameter accepts is 255.

domainlogons

This Boolean parameter is described earlier in this chapter, in Section 5.1.2. The local master browser election procedure gives an edge to domain controllers, but this factor is less important than the OS level.

winssupport

This Boolean parameter is also described earlier in this chapter, in Section 5.2.2. A domain master browser doesn't have to be an NBNS system, but the election criteria give these systems a slight edge.

preferredmaster

If this Boolean parameter is set to Yes, nmbd calls for an election whenever it's started, and periodically thereafter. This setting also gives the server a slight boost in the election. The default value is No.

Warning

Setting preferredmaster=Yes inappropriately can cause problems because master browser elections take time, during which browsing ceases to function. Therefore, you should be sure that you don't use this setting on a system unless you're reasonably sure it will win the election (by setting a high os level value).

browselist

The default for this Boolean parameter is Yes, which causes Samba to maintain a browse list for the network. Maintaining the browse list does no harm if the computer doesn't function as a master browser, so there's normally no need to change this option. If you do set it to No, the system won't participate in browser elections.

The oslevel parameter trumps all the others, aside from local master and browselist. That is, in a contest between computers with os level parameters set to say, 32 and 33, the system with oslevel=33 will win every master browser election, even if the other system is configured with domainlogons=Yes, winssupport=Yes, and preferredmaster=Yes. Overall, you can be fairly certain that a system will function as a local master browser if you set options like these in the [global] section of smb.conf:

local master = Yes
preferred master = Yes
os level = 64

If your network has some Samba systems with inappropriately high oslevel parameters, you may need to increase that value. (On the other hand, tracking down the offending systems and fixing their configurations may be a preferable solution.) If the computer also functions as a domain controller or NBNS system, you may need to set appropriate options for those functions, too. These settings shouldn't be necessary to have the system take on local master browser duties, though.

Configuring Samba Domain Master Browser Features

The domain master browser isn't elected by all the computers on the network; it's assigned by a network administrator. For this reason, Samba provides a parameter that tells Samba to take on this duty: domain master. This parameter is a global Boolean, and you should be careful about setting it. Don't set this parameter to Yes if you're not certain the system should be functioning as a domain master browser; do set it to Yes if the computer takes on this role.

Normally, the domain controller takes on domain master browser duties. Some workgroup configurations also use domain master browsers, even though they don't have domain controllers. This configuration can be helpful if your network spans multiple subnets, but you don't want to use a full domain configuration.

You should be sure to configure a domain master browser to win the local master browser election for its subnet, as described in the previous section. That section describes some options related to domain controller status as factors in browser elections; however, these factors are small ones, and they're completely irrelevant if two systems' OS levels don't match. Thus, you should be sure your domain controller has the highest os level parameter of any computer on the network.

Summary

Samba can take on many duties that are helpful or even necessary on Windows networks but that don't relate to sharing files or printers directly. Most of these duties are related to handling NT domain controller functions, and, in fact, functioning as a domain controller is one of these key functions. Related functions include handling NetBIOS name resolution as an NBNS system and becoming the local master browser or domain master browser. Using Linux as the operating system for any of these functions can help improve your network's overall reliability because of its excellent overall stability.