One of Samba's strengths is you can use it to blend your mix of Windows and Linux machines without needing a separate Windows NT/2000 Server. In this article, we describe some recommended methods for accomplishing a large scale Samba installation. Our focus includes the integration of Windows 2000 and XP Professional, two of the more popular clients currently used with Samba.

To start with, we need to download the current stable version of Samba. As most prepackaged binaries are geared to work on a wide range of hardware, we're going to build Samba from scratch so we can benefit from using code specific to our architecture. It's important to verify that the source code hasn't been tampered with. We can do this by verifying the file's PGP signature and using the main Samba Distribution Key, all of which can be found at www.samba.org. Go ahead and download the samba-2.2.8.tar.gz, samba-2.2.8.tar.asc and samba-pubkey.asc files.

Sidebar: Important Terminology

If you don't have gpg on your system, you'll need to fetch it from www.gnupg.org and install it. To verify our package, we need to import the main Samba Distribution Key and verify the PGP signature of our Samba package:

$ gpg --import samba-pubkey.asc
$ gzip -d samba-2.2.8.tar.gz
$ gpg --verify samba-2.2.8.tar.asc

If you receive a message saying "Good signature from Samba Distribution Verification Key", then all is well. Ignore any warnings about trust relationships as they typically don't exist on all systems. Our next step is to install Samba itself. If you have an Intel Pentium Pro or higher, use -march-i686. If you're not short on memory for compiling programs, use -O2 to increase the optimization of the Samba binaries. If neither of these make sense to you, skip the entire CFLAGS statement. We're also going to specify explicitly the location where the Samba man pages should be installed rather than have them reside in /usr/local/samba/man/.

$ tar xf samba-2.2.8.tar
$ cd samba-2.2.8/source/
$ CFLAGS="-O2 -march=i686" ./configure \
     --mandir=/usr/man

Regardless of the configuration options you decide to use, the following options are being removed from the upcoming Samba 3.0 release and therefore should be avoided:

Once you're done with the initial configuration, you can make and install Samba with:

$ make
# make install
# ln -s /usr/local/samba/bin/* /usr/sbin/

Although Samba provides SWAT, a Web-based graphical tool to build your smb.conf configuration file, we're going to get our hands dirty and create this file by hand (see Listing 1).

Listing 1. Sample Samba Configuration File

A common mistake made when configuring Windows 2000/XP Professional is not using unique names for the computer, user and domain. Even without introducing Samba into the mix, Windows can be confused by non-unique names. Therefore, it's best to have a naming convention for your network in mind ahead of time. For the following Case Studies, we assume the following are true of our example client:

Computer Name:  pc-lab15
User Name: fred
Domain: mydomain

Case Study #1: Windows 2000/XP non-domain member accessing Samba domain

It's not necessary to have your workstations join your Samba domain in order for them to access its services. This is especially true of mobile users and those with laptops. This is also the easiest and most simple configuration to use.

On the Windows 2000/XP workstation, create a Local User and assign it a password. You can accomplish this by opening up a Command Prompt and typing NET USER fred * /ADD.

On your Samba box, create a system account with the same username and a Samba account with the same username/password to match:

# useradd -d /home/fred -g 100 -m fred
# smbpasswd -a fred

This method is effective because it requires minimal modifications to the client. One disadvantage is only users with a local account created for them on the Windows 2000/XP box are able to log in to this box; as a result, it's ideal only for single or dual-user workstations.

Case Study #2: Windows 2000/XP domain member accessing Samba domain

You might be interested in this option for many reasons, one of which is the ability for anyone to be able to log in to the Windows 2000/XP workstation without needing to create a duplicate account on the local workstation ahead of time. Additionally, password changes need occur only on the Samba box and not on the local workstation. One disadvantage of this method is it requires more initial client modifications. In short, if you have multiple users attempting to log on from the same workstation, you should configure it for domain logins.

Our first step is to add users to our Samba box using the same commands from Case Study #1. This time, however, we must create a "machine" account for the workstation so it can join our Samba domain:

# useradd -d /dev/null -g 100 -m pc-lab15$
# smbpasswd -m -a pc-lab15

Notice the use of the dollar-sign ($) when adding the account to the system's /etc/passwd file and the lack of it when adding the account to smbpasswd--this is intentional and necessary. The dollar-sign denotes that this is not a normal user account.

Additionally, if you haven't yet created a root account in smbpasswd, it's important to do so. Otherwise, you won't be able to allow any workstations to join your Samba domain. The account name must be root for this to work, so enter smbpasswd -a root.

Our next few steps involve modifications on the client-end of the coin. If you're running Windows XP, you need to add the following to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters, and then reboot in order to allow it to join a Samba domain:

"requiresignorseal"=dword:00000000
"signsecurechannel"=dword:00000000

The next steps apply to both Windows 2000/XP. It's important not to log on with an account that only has Administrative rights to the workstation, but one that does not exist in Samba's smbpasswd. Usually, the default account of Administrator works nicely. Drop into a command prompt and clear any lingering network connections that might interfere with our next few steps using NET USE * /DELETE /YES.

Next, right-click on My Computer and choose Properties. Select the Computer Name tab and then click Change.

Figure 1. Assigning a Domain Change on Windows XP

You're asked to enter the name and password of an account with permission to join the domain. To join a Samba domain, you must enter the username root with its corresponding password from smbpasswd--not the system password.

Figure 2. Authorizing a Domain Change on Windows XP

After a minute of seeming inactivity, you are welcomed to the new domain and asked to reboot. Make sure to select the new domain when logging in, and you're set.

If you can't join your Samba domain, chances are you're seeing one of the following error messages:

Case Study #3: Accessing Samba resources across multiple subnets via NFS

If you're like me, running Microsoft file and printing services across different subnets sends shivers down your spine. While some claim this next option is security through obscurity, I find that encapsulating SMB via NFS make it harder for someone to monitor any traffic between subnets. One common solution in the past has been to compile Samba with SSL support; however, this option is being left out of the upcoming Samba 3.0 release and hasn't seen much work in this part of the source code for some time. To set things up, you need to install two Samba servers, one to act as the primary file sharing system and the secondary server to act as a traffic conduit. For specific details on NFS functionality, see the Network Administrator's Guide and the NFS-HOWTO--both are available at www.tldp.org). This example assumes your primary server has an IP address of 10.1.1.1/24 and your secondary server has an IP address of 10.2.1.1/24.

Figure 3. Kernel Options for Enabling NFS

On your primary Samba server, recompile the Linux kernel to run the kernel-based NFS server (see figure 3) and activate the NFS dæmons. Modify your /etc/exports file to list the directories you are sharing over Samba. Make sure to replace the fake IP addresses (below) with the actual IP address of your secondary Samba server. For example:

/projects      10.2.1.1(rw)
/home/public   10.2.1.1(rw)
/home/netlogon 10.2.1.1(rw)

On the secondary Samba server, enable NFS-client support in the kernel (CONFIG_NFS_FS, CONFIG_NFS_V3). If you experience problems with locking, setting posix-locking = no in your smb.conf file might alleviate things, even though it is contrary to the definition of POSIX locking. Update your /etc/fstab file to reflect the NFS filesystems to be mounted and mount the filesystems with mount -a -t nfs. Your /etc/fstab might look like:

10.1.1.1:/projects       /mnt/projects  nfs  defaults 0 0
10.1.1.1:/home/public    /mnt/public    nfs  defaults 0 0
10.1.1.1:/home/netlogon  /mnt/netlogon  nfs  defaults 0 0

Fire up Samba on the primary server, and on the secondary server make sure the Samba shares point to the mounted directories. For any users at the secondary site, make sure their systems and Samba username/passwords match, including the UID/GID bits in /etc/passwd. You can configure your secondary Samba server as in Case Study #1 or #2; either way works for this purpose. Fire up Samba on the secondary server and have your clients log in.

Case Study #4: Tunneling SMB with SSH

One of the most sought-after methods of encrypting SMB traffic is by tunneling it through SSH using a method known as port forwarding. It's a great way to secure remote traffic across multiple subnets. The main disadvantage is this only works with pure 32-bit Windows 2000/XP. It's also worth mentioning that running SMB without SSH over a 56k dial-up line still is slow to the point of frustration. If you don't have a high speed link or at least a lot of patience, you probably don't even want to deal with tunneling over SSH.

Name services or anything relying on UDP can't be forwarded over SSH due to a limitation in how SSH forwards ports (TCP only). So, we focus on port forwarding only TCP/port 139. Those interested in using direct hosted TCP/port 445 won't be disappointed either. As UDP tunneling is not available under SSH, your first step involves adjusting for this and the resulting lack of WINS/broadcast name resolution.

Windows provides two different files, HOSTS and LMHOSTS. The former is for hostname-to-IP address resolution (similar to DNS), and the latter is for NetBIOS-name-to-IP address resolution (similar to WINS). These files are provided as a "backup" in the case that DNS/WINS are not available. We can use this to our advantage, because we aren't able to tunnel our UDP traffic. Modify your %SYSTEMROOT%\ System32\drivers\etc\LMHOSTS file to include:

127.0.0.1     FAKENAME      #PRE

where FAKENAME is a bogus NetBIOS name that you use to refer to your Samba server. The #PRE statement tells Windows that this name should be cached into memory. This file is not be processed by Windows until you reboot or you issue NBTSTAT -R, which forces a reload of the NetBIOS name cache (note the uppercase-R).

Configure your client's SSH program to forward port 139/TCP on the localhost to port 139/TCP on the server and connect over SSH. Once done, open up a command prompt and issue any of the following commands:

NET VIEW \\127.0.0.1
NET VIEW \\FAKENAME
NET USE M: \\FAKENAME\public

One variation on this theme is to run direct hosted SMB traffic, which is Microsoft's new marketing term for SMB running only on TCP port 445. It's important to be aware that this method is available only with Windows 2000/XP clients. Using this method, you can avoid all the headaches with LMHOSTS and NetBIOS. Although this method is new and has yet to catch on, it appears to work quite well and fits nicely with SSH tunneling. In order to run Samba on a different port, you need to run it from inetd instead of as a dæmon. Modify your /etc/inetd.conf to include:

microsoft-ds  stream  tcp  nowait  root  
/usr/local/samba/bin/smbd  smbd

You also need to add the microsoft-ds service to your /etc/services file:

microsoft-ds     445/tcp

Fire up your SSH server and client, connect and tunnel port 445, as we did with port 139 above, and issue any of the following commands from a command prompt:

NET VIEW \\127.0.0.1
NET USE M: \\127.0.0.1\public

These are only a few of the more common approaches to large scale Samba deployment. Many more methods can be implemented, depending on your specific needs. Hopefully, this article has provided some initial blueprints to this end.

The Unofficial Samba HOWTO by David Lechnyr

SMB/CIFS by The Root by ledin

SMB HOWTO by David Wood

Implementing CIFS by Christopher R. Hertel

Just what is SMB? by Richard Sharpe

David Lechnyr is a network manager in the Human Resources Department of the University of Oregon. He holds a Master's Degree in Social Work along with his MCSE+I, CNE and CCNA certifications. He has been working with Linux for the past seven years and is the author of the Unofficial Samba HOWTO.