I need to Samba

I have to say that I really do like Samba. I rely on Samba to make my internal LAN (consisting of Windows NT and UNIX) work together. Generally Samba is a great thing. But a couple of weeks ago, I had a few Samba regrets.

I had all my important UNIX files shared through Samba, which allowed me to use freebox (my FreeBSD UNIX machine) as a central file store. And I had my NEC SuperScript 870 printer hooked up to freebox, and shared with my Windows NT clients. Everything was working wonderfully...so what was the problem?

After a bit of reflection I realized that while Samba was doing a lot of good things, I wanted it to do more. Primarily, I was unhappy that I had a decentralized security database: I needed to have two accounts, one on the Samba machine and one on NT as a local user (so that I could log in to the machine). I also needed to make sure that the usernames and passwords on these accounts matched up exactly. Since I'm the only one using my LAN, this was a minor inconvenience. But nevertheless, it made Samba seem like a bit of a hack. Not to mention the fact that the Windows NT Server has a centralized security model! (I figured Samba should be competitive here.) Sure, Samba worked. But could it work better?

Another thing I wasn't too happy about was that my NT user profiles were being stored on the NT machines. I knew that if I were using an NT Server, the profiles would be in "roaming" mode. This means they would get uploaded to the NT Server for safekeeping at the end of my session. If I logged in to another machine on the network, my profile would be downloaded. This assured a consistent desktop, regardless of the machine I logged in to. If I could get Samba working this way, profiles would be a lot easier to back up since they would be stored on the same machine that would be housing my new Ecrix VXA-1 tape drive. Then my IE bookmarks and desktop settings would get backed up properly along with my regular files. With these experimental features added to Samba, I'd have a totally centralized system with freebox at the helm, which was just what I wanted!

Back to top

I really need to Samba

I was not too optimistic at the start of my mission, simply because I had been following the domain controller support in Samba for a couple of years. Every six months or so I had the urge to get domain controller support working under Samba, and every time it failed. I knew that version 2.0.6's domain controller support didn't seem to work for me. I also knew that SAMBA_TNG, the alpha "next generation" version of Samba on CVS, was not ready for prime time. Thankfully, version 2.0.7 of Samba just came out (with lots of bug fixes). To increase the likelihood of getting domain controller support to work, I opted for Samba pre-2.0.8 from CVS, which was even tighter than 2.0.7.

Back to top

Those smb.conf options

I was ready to see how pre-2.0.8 performed. I loaded up my smb.conf into xemacs after downloading, compiling, and installing this latest Samba. In xemacs, I uncommented several finely tuned domain controller-related options that I had been saving for just such an occasion. After saving my changes, I started the new Samba daemons hoping for the best. What was the result?

In about 10 minutes, roaming profiles and domain logons were working without a hitch! I was amazed. It seemed too good to be true. So I used my network for a few days to see how it behaved, and Samba continued to work flawlessly! OK, mission accomplished. Now I'll explain how I did it.

Back to top

What did I do?

For those who may not be familiar with Windows domain controller terminology, I'll use the proper Microsoft terms. Using Samba, I set freebox up as the "primary domain controller" (PDC), controlling its own domain. The name of my domain is called "GENTOO". As PDC, freebox stores a centralized security database used to keep track of which machines are part of the domain and what user accounts are valid. In addition, freebox is also configured to store NT user profiles while keeping the most recent version of each user's profile in a central location. I should mention that I made my NT machines "join" the domain, so that they can access all of my domain's resources and use Samba's security database.

If I had needed multiple domain controllers in my domain, Samba would probably not have been up to the task. If I had needed Samba to be a BDC (backup domain controller), Samba would also most likely have failed. These functions are still in development for Samba. Fortunately, all I wanted or needed was for my UNIX machine to be the primary (and only) domain controller for my LAN. And this function of Samba pre-2.0.8 works. Now here's exactly how I got PDC functionality up and running.

Back to top

Downloading SAMBA_2_0

First I downloaded the most recent version of Samba from CVS. I used the SAMBA_2_0 branch, which contains the most recent bug-fixed version of Samba 2.0.x. Here's how to get SAMBA_2_0 from CVS:

Create a directory somewhere called "samba-cvs-2.0", and cd into it. Then, type:

$ cvs -d :pserver:cvs@cvs.samba.org:/cvsroot login

When you are asked for a password, type "cvs". Then type the following command to check out the sources:

$ cvs -d :pserver:cvs@cvs.samba.org:/cvsroot co -r SAMBA_2_0 samba

Whenever you want to update the sources to the most recent version on CVS, enter the "samba-cvs-2.0" directory and type:

$ cvs -d :pserver:cvs@cvs.samba.org:/cvsroot update -r SAMBA_2_0

After the sources are downloaded, you'll have a new directory called "samba". To compile Samba go into the "samba/source" directory and perform the usual steps (see one of my previous articles, Introduction to Samba, Part 2, if you need Samba compilation instructions). After compiling Samba, install it. Now we're ready to whip the smb.conf and the smbpasswd file into shape.

Back to top

Whipping smbpasswd into shape

Before we touch smbpasswd, you'll want to set smb.conf's workgroup= setting (in the [global] section) to the name of the NT domain you want to create. You'll also want to ensure that your Samba configuration is running in encrypted mode (using the "encrypt passwords=yes" option). After making these changes, restart Samba, verify it is working, and proceed.

First you need to get Samba's security database ready for domain operation. So make a list of all the Windows NetBIOS machine names that will be members of your domain. My list looks like this:

		ntbox   Windows NT Workstation 
		kompressor  Windows NT Workstation

Now add the name of your Samba PDC to this list. This is extremely important! My list now looks like this:

		ntbox   Windows NT Workstation 
		kompressor  Windows NT Workstation 
		freebox   Samba PDC

For each machine name listed in this list, you'll need to perform the following steps. First, create a standard UNIX account for the name of the machine with a "$" appended. Here's an excerpt from my /etc/passwd file after I've performed this step:

ntbox$:*:1005:65534:Trust Account:/nonexistent:/sbin/nologin 
freebox$:*:1006:65534:Trust Account(necessary in Samba 2.0):/nonexistent:/sbin/nologin 
kompressor$:*:2009:65534:Trust Account:/nonexistent:/sbin/nologin

Notice that the accounts have "$" appended to their names. Also notice that these accounts do not have home directories and are not login accounts. This is what you'll want on your system. These accounts will allow these machines to be part of the domain. And yes, with Samba 2.0 the PDC has to be a member of its own domain. This requirement has been removed in SAMBA_TNG, but in our situation your Samba box must also have an account in /etc/passwd. If you're using Linux, you can use the useradd command as follows:

# useradd -s /bin/false -d /nonexistent -c "Trust Account" ntbox\$ 
# useradd -s /bin/false -d /nonexistent -c "Trust Account" kompressor\$ 
# useradd -s /bin/false -d /nonexistent -c "Trust Account" freebox\$

Notice the use of the "\" before the "$", which prevents bash from misinterpreting the "$".

OK, now it's time to get smbpasswd set up correctly. You'll need to create Samba machine accounts for every workstation and the PDC by typing:

# smbpasswd -a -m freebox 
# smbpasswd -a -m kompressor 
# smbpasswd -a -m ntbox

Then we need to have our PDC join its own domain. Type:

# smbpasswd -j GENTOO (replace this with your NT domain name)

The name of your domain is set by the workgroup= parameter in smb.conf. Now the security settings are ready. It's time to get smb.conf set up properly.

Back to top

Setting up smb.conf

First some general rules. As mentioned earlier, Samba must be running in encrypted password mode. You won't be able to use share-level security, but user, server, or domain security settings will work fine. My domain controller is configured to also be the local master browser (for more information on setting up Samba to be the local master browser, see Introduction to Samba, Part 2.

Now, add the following options to the [global] section:

		domain logons=yes 
		logon path = \\%L\profiles\%U.pds 
		logon home = \\%L\%U 
		logon drive = m:

As you may have guessed, the first option enables domain logons. The second logon path= option is a bit more complicated. It tells Samba where to look for NT user profiles. In this case, it will look in \\PDC\profiles\username.pds. This means that we'll need to create a profiles share, which we'll do in a few minutes. The last two options specify what share to attach as the "logon drive", and what drive letter to attach it to. You can leave these last two settings out if you don't want any automatic home drive mapping to take place.

Now it's time to add the two new shares "profiles" and "netlogon". Add the following lines to your smb.conf:

[profiles] 
     comment = User profiles 
     path = /usr/local/profiles 
     create mode = 0600 
     directory mode = 0700 
     writeable = yes 
     browseable = yes 
# next line is a great way to secure the profiles 
     force user = %U 
# next line allows administrator to access all profiles 
     valid users = %U administrator 

[netlogon] 
     comment = The domain logon service 
# there is nothing in /usr/local/netlogon right now, 
# just an empty directory. 
      path = /usr/local/netlogon 
      writeable = no 
      locking = no

The above lines should be entered almost exactly as they appear. The only thing you'll need to do is customize both path= options to your liking. The profiles path will store the NT user profiles. The netlogon path is a good place to place any logon scripts you may need. Set the permissions on the profiles path so that any user can create files in the directory (0777). The netlogon path does not need any special permissions. Set the permissions as you like.

Back to top

Getting the PDC going

Now it's time to restart Samba. After restarting, you should configure all your Windows machines to join your new domain. All should go well. Any new users you create will be set up with proper roaming profiles. Changing an existing static profile to a roaming profile involves visiting the User Profiles tab of the NT System control panel and copying your profile over to your Samba server. When you log out and log back in you will be asked whether to use the local or roaming profile. Select the roaming profile. Now you're in business. If you receive some form of error message (root, for example), go into the profiles directory and make sure that the username.pds directory and all its contents are owned by the proper user. After fixing permissions, the user profile should be fully operational. When logging in to NT, remember to choose the domain you just joined in the Windows NT Login dialog. Otherwise you'll be logging in to the local machine. Everything should work smoothly. Enjoy your new PDC!

A note about user profiles. Unfortunately Internet Explorer defaults to saving its cache file inside a user's profile. This generally has the result that IE bloats the profile to 64 MB. To correct this, follow these steps:

1. Log in to Windows as the particular user.
2. Start Internet Explorer and go to the Tools menu.
3. Select the Internet Options menu item.
4. In the General Tab, click the "Delete Files" button.
5. Then click the Temporary Internet Files Settings button.
6. Reduce "The amount of disk space to use" to a reasonable value, like 4 MB.
7. To enhance browsing performance, configure the Squid proxy cache on your UNIX machine. Now your LAN's cache will be centrally located, bigger and shared among all machines.

You may find that when you log in to a local NT machine as MYDOMAIN/Administrator, you can't perform any local administration tasks. To solve this problem, log in to the particular NT machine as MACHINENAME/Administrator (using the local administrator account). Then fire up User Manager and add "GENTOO/Domain Admins" to the Local "Administrator" group. After adding Domain Admins, this account will show up as "Account Unknown", but it will still work. Now you can log on as MYDOMAIN/Administrator and still perform local administration tasks.

Back to top

Samba_TNG preview

The SAMBA_TNG branch is where significant progress is being made on the domain controller code. It's not yet ready for prime time, but you may be interested in checking it out for testing purposes or to help the developers debug the code. You can check out the SAMBA_TNG code by logging in to CVS as normal:

$ cvs -d :pserver:cvs@cvs.samba.org:/cvsroot login

When you're asked for a password, type "cvs". Then, type the following command to check out the sources:

$ cvs -d :pserver:cvs@cvs.samba.org:/cvsroot co -r SAMBA_TNG samba

CVS updates work in the usual manner.

$ cvs -d :pserver:cvs@cvs.samba.org:/cvsroot update -r SAMBA_TNG

SAMBA_TNG is designed to eventually have full domain controller support. This means that BDC (backup domain controller), trust relationships, and Active Directory are all being worked on. Developers are also putting significant effort in getting all NT administration tools fully functional so that they can be used to remotely manage a Samba system.

Back to top

Changes in Samba_TNG

One of the biggest changes in SAMBA_TNG is the increase of daemons (around ten) from only smbd and nmbd. Each daemon is specialized to perform one specific task: network browsing, logon requests, exporting the SAM database via LDAP, etc. The idea behind this design change is that it allows Samba to be more modular. It enables daemons from different versions of Samba to be mixed and matched with each other for customized functionality. And if you don't need certain functions, you can disable the corresponding daemon.

Other additions are the tools: rpcclient, net, samedit, regedit, and others. These command-line programs interact with Windows NT or SAMBA_TNG systems using Microsoft protocols. The Samba team is trying its best in this area to create tools so that UNIX administrators do not need to directly log in to a Windows NT machine to administrate it. Eventually all necessary tasks will be performed remotely using the appropriate command-line tool.

Resources

• Always be sure to read the WHATSNEW.txt file in the main samba directory
  
  
• Amiga Samba mailing list
  
  
• frgpasswrd, a password synchronization utility to set Samba and shadow passwords concomitantly
  
  
• Gentoo Project
  
  
• GnoSamba, a GUI tool for configuring Samba
  
  
• KNetmon, a front end for the Samba and smbsf packages
  
  
• A line of Samba clothes from Nerdgear
  
  
• linuxdoc.org
  
  
• The main Samba Web site
  
  
• Samba by Ed Weinberg
  
  
• SambaLink/Q, a version-independent editor for the smb.conf file
  
  
• Samba Notes for Redhat: This site provides the latest, but not quite finished version of the notes, covering Samba 2 on Red Hat 6, and an older version, covering Samba 1 on Red Hat 5.x
  
  
• Samba/iX: Samba/iX is a suite of programs that allow an HP e3000 running MPE/iX operating system to provide service using Microsoft's Server Message Block (SMB)
  
  
• SMB Mode for Emacs helps edit Samba's configuration file smb.conf
  
  
• IBM learning services offers a 2-day hands-on course on Samba
  
  
• The SWAT main page
  
  
• Read Samba Unleashed , by Steve Litt, with contributions from Daniel Robbins
  
  
• Using Samba from O'Reilly Publishing is a comprehensive guide to Samba administration, including such recent additions as integration with Windows NT domains and the SWAT graphic configuration tool
  
  
• The Kernel Cousin Samba on Linuxcare
  
  
• xSMBrowser, a Samba browsing utility that supports both WINS and Broadcast networks
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• I need to Samba
• I really need to Samba
• Those smb.conf options
• What did I do?
• Downloading SAMBA_2_0
• Whipping smbpasswd into shape
• Setting up smb.conf
• Getting the PDC going
• Samba_TNG preview
• Changes in Samba_TNG
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Linux on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers