Large Scale Samba Installations

How to install and set up various scenarios for Samba and Windows2000/XP Professional.

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 Verification

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:

  • --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 File

Preparing the Client

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:

  • 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 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
______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Huge installation for a huge number of shares

Olivier Gaspard's picture

Hi,

Is this kind of Samba installation can support easily more than 2000 shares ??

In my firm, we have lot of problems with Samba to share this number of directory... Is it possible to have a stable Samba with this numbers of sharing?

Tanks, Olivier G.

This didn't work on my system

Anonymous's picture

This didn't work on my system.
# useradd -d /home/fred -g 100 -m fred

Instead I used the information from the Suse Howto:

# useradd -g machines -d /var/lib/nobody -s /bin/false mymachine$

regards

Re: Large Scale Samba Installations

Anonymous's picture

>The documentation found on the subject says to setup an
>entry in LMHOSTS file in the form of:
>
>127.0.0.1 sambaserver #pre
>
>checking the status of the cache with NBTSTAT -c after
>doing a NBTSTAT -R does not show the entry
>for "sambaserver"
>
>If I put any other IP address instead of the loopback
>address (or the interface's own IP address), the entry
>shows up in the cache.
>
>When trying to connect to the remote share, the command
>fails with "error 53 network name not found".
>
>...
>any ideas?

Yes.

See: http://lists.samba.org/archive/samba/2004-May/085358.html

The lack of an nbtstat -c entry is not the problem.

Re: Large Scale Samba Installations

Anonymous's picture

Hi,

I'm trying to connect to a share on a linux box from a
win98 (or win2k) machine through an SSH tunnel.

The documentation found on the subject says to setup an
entry in LMHOSTS file in the form of:

127.0.0.1 sambaserver #pre

checking the status of the cache with NBTSTAT -c after
doing a NBTSTAT -R does not show the entry
for "sambaserver"

If I put any other IP address instead of the loopback
address (or the interface's own IP address), the entry
shows up in the cache.

When trying to connect to the remote share, the command
fails with "error 53 network name not found".

With a sniffer, I can see my win98 machine doing several
name resolution requests (one to the DNS and a few to the
broadcast address) which tells me that the lmhosts file is
not looked into.

any ideas?

regards

Re: Large Scale Samba Installations

Anonymous's picture

>The documentation found on the subject says to setup an
>entry in LMHOSTS file in the form of:
>
>127.0.0.1 sambaserver #pre
>
>checking the status of the cache with NBTSTAT -c after
>doing a NBTSTAT -R does not show the entry
>for "sambaserver"
>
>If I put any other IP address instead of the loopback
>address (or the interface's own IP address), the entry
>shows up in the cache.
>
>When trying to connect to the remote share, the command
>fails with "error 53 network name not found".
>
>...
>any ideas?

Yes.

See: http://lists.samba.org/archive/samba/2004-May/085358.html

The lack of an nbtstat -c entry is not the problem.

Re: Large Scale Samba Installations

Anonymous's picture

I can see Samba Server on my XP. However I cannot get any service.
It says that the permission is wrong.

Could you help me?

Re: Large Scale Samba Installations

Anonymous's picture

is your firewall up on xp it could be that (worked for me)

Re: Large Scale Samba Installations

Anonymous's picture

FINALLY an article that really is useful in today's corporate environment! Well done!!! Keep more of this type of material coming!

Re: Large Scale Samba Installations

Anonymous's picture

What the heck is with installing the man pages under /usr/man?
;-)

Re: Large Scale Samba Installations

Anonymous's picture

Note that before you join Win2K/XP workstation into a Samba domain, you must take a decision about kind of user profile - roaming or local. In case of roaming profile you must store them in different places for each OS (or your Win2K profile will be overwritten with WinXP profile): Add to smb.conf

[global]
logon home = //SERVER/PROFILESHARE/%U/%a

Unfortunately, the latest Samba release - 2.2.8a detect WinXP as Win2K (see https://bugzilla.samba.org/show_bug.cgi?id=224). You must use cvs version of Samba (2.2.9pre) or 3.0.0

Re: Large Scale Samba Installations

Anonymous's picture

In your multitier example, instead of running Samba over NFS with all of the security problems that NFSv2 and v3 would introduce, Samba mounted over the new Linux CIFS VFS to Samba could be used instead (the CIFS VFS and Samba now support CIFS packet signing - much faster than SSL encrypting everything and more secure than NFSv2 and v3)

Re: Large Scale Samba Installations

Anonymous's picture

FYI - there's no problem with using obscurity to help prevent breakins. The problem is "security through obscurity" is when people have obscurity, but they _think_ they have security. Using both is a great idea, and using obscurity is better than nothing at all. The problem is when you think you are secure when in fact you are only obscure. As long as your decision is well thought out, there is no problem.

Re: Large Scale Samba Installations

Anonymous's picture

The title of this article is not very fitting. What does this have to do with Large Scale Samba Installations? It should talk more about the infrastructure and off-loading tasks to various servers. Furthermore, it should have some talk about LDAP integration.