Large Scale Samba Installations

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.Installation and VerificationTo 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
TerminologyIf 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:

• --with-codepagedir
• --with-krb4-base
• --with-msdfs
• --with-ssl

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 FilePreparing the ClientA 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 domainIt'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
domainYou 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:

• The following error occurred attempting to
  join the domain "MYDOMAIN": The network path was not
  found. Ironically, this is usually a Windows XP specific
  error where it apparently attempts to contact your PDC from a stale
  (and incorrect) gateway/route entry in the registry. Change your IP
  address, subnet and gateway to something different, and then change
  it back again. This usually removes any stale entries. It's unclear
  why this happens, but this behavior can be verified by a packet
  sniffer.
• The following error occurred attempting to
  join the domain "MYDOMAIN": No mapping between account names and
  security IDs was done. This obscure error reportedly has
  been fixed by using lower-case names for the workstation name in
  /etc/passwd and smbpasswd and on the Windows XP client.
• The following error occurred attempting to
  join the domain "MYDOMAIN": Access is denied. There isn't
  a machine account entered in smbpasswd for the computer you're
  attempting to have join the domain, or the machine account is
  currently disabled. It's also possible that you're trying to join
  the domain using an account name other than root, which is
  required.
• The following error occurred attempting to
  join the domain "MYDOMAIN": Logon failure: unknown user name or bad
  password. Either root doesn't exist in the smbpasswd
  database or you've typed in an incorrect password.
• A domain controller for the domain
  "MYDOMAIN" could not be contacted. You've typed in a
  domain name, but it's not the one your Samba server is using. You
  want to use the value of the workgroup parameter from smb.conf as
  the name of your domain. Another possibility is nmbd is not running
  on your server and therefore can't answer NetBIOS name
  queries.

Case Study #3: Accessing Samba resources across multiple
subnets via NFSIf 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 SSHOne 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

ConclusionThese 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.ResourcesThe
Unofficial Samba HOWTO by David LechnyrSMB/CIFS
by The Root by ledinSMB
HOWTO by David WoodImplementing CIFS
by Christopher R. HertelJust
what is SMB? by Richard SharpeDavid 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.

email: david@lechnyr.com