Making Samba your Primary Domain Controller - Part Quarto

Last time we went over installing Samba on both Linux and FreeBSD. It was pretty simple. Configuring Samba, though, can be a bit tougher. I ran into a number of difficulties, all to do with the (rather cryptic) smb.conf configuration.

Samba is controlled by a single file -- smb.conf. Depending on which operating system you favour, you'll find it in either /etc/smb.conf (most Linux distros), /etc/samba/smb.conf, or /usr/local/etc/smb.conf (FreeBSD).

Configuring smb.conf
Remember that our goal is to use Samba as a primary domain controller. Below is a minimalist smb.conf configuration that will achieve this goal (at least in theory). We have a machine named Aragorn, in a Windows domain named middleearth. We are telling Samba to set up profiles for NT/2000/XP users, and specifying who is a domain admin. We're also telling Samba how to add users to the system. Note that in smb.conf, a comment is either a '#', or a semi-colon (';'). Anything preceded by either of those symbols is ignored. I strongly encourage you to put lots and lots of comments in. It will make life much easier if you have to go in and make a change.

[global]
; name our machine and workgroup
netbios name = aragorn
workgroup = middleearth
encrypt passwords = yes

; tell samba we are a PDC
domain master = yes
local master = yes
preferred master = yes
os level = 65

; we'll probably come back to these settings,
; but they'll do for now
security = user
domain logons = yes

; logon path tells Samba where to put Windows NT/2000/XP
; roaming profiles
logon path = \\%L\profiles\%u\%m
logon script = logon.bat

logon drive = O:
; logon home is used to specify home directory and
; Windows 95/98/Me roaming profile location
;logon home = \\%L\%u\.win_profile\%m

time server = yes

; Use the names of all users in the Windows NT/2000/XP
; Administrators group who log on to the domain
domain admin group = root tcs susand

; this works on Centos Linux -- YMMV
add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u

; share a directory for everyone
[public]
 path = /samba/shares/public
 public = yes
 only guest = yes
 writable = yes
 printable = no

; make one private to tcs
[tcs]
 comment = tcs's stuff
 path = /samba/shares/private/tcs
 valid users = tcs
 public = no
 writable = yes
 printable = no
 create mask = 0765

This might seem a bit cryptic, but it actually makes sense. There are some oddities specific to this file, though, so let's go through this section a bit. First, note that we begin with a [global] tag. As you might expect, this simply states that everything that comes after this tag prior to the next one is "global" in nature. We begin in this section by setting the NetBIOS name of the Samba server. The NetBIOS name is used in UNCs that appear later in smb.conf. The next two lines are a bit odd. We appear to be naming a workgroup -- but although it reads "workgroup", we are actually setting the name of our domain. For a workgroup, using encrypted passwords is optional; when using a domain, they are required, so we'll encrypt our passwords.

The next four lines set up our Samba machine to handle browsing services. This line:

domain master = yes

looks like it is telling Samba to act as a PDC. After all, it has the word "master" and the word "primary" -- sounds important. In fact, all this line does is tell Samba to act as a domain "master browser," which handles browsing services for the domain across multiple subnets (in conjunction with the built in WINS service, which we'll get to in awhile), if necessary. These lines,

local master = yes
preferred master = yes
os level = 65

simply tell Samba to participate in browser elections and allow itself to win. To be safe, the "preferred master" and "os level" lines are there so as to ensure that Samba wins the elections.

This section,

security = user
domain logons = yes

tells Samba to handle the actual domain logons. We set security to "user" so that Samba will require a username and password (always a good thing). This is actually the default setting for Samba, and the only reason we're including it explicitly is to avoid confusion.

"domain logons" is what tells Samba we want this server to handle domain logons (finally!). To support roaming profiles inWindows NT/2000/XP clients, we have to supply Samba with a "logon path":

logon path = \\%L\profiles\%u\%m
logon script = logon.bat

The value following "logon path" refers to a share held on the Samba server where the profiles are kept. The variables %L and %u are replaced with the name of the server and the username of the logged on user, respectively (this is done automatically, by Samba, while it runs. Don't try to manually edit the file to put in your own values -- just use %L and %u).

If you put those entries into your smb.conf (and make the changes appropriate for our system, of course), you will have a functional, if bare bones, PDC running. Next time I'll go through fine tuning this and adding some additional bells and whistles.

Making Samba your Primary Domain Controller - Part Trois

Last time around we went over the basic choices for hardware/operating system for a Samba installation. In case you're curious, here is the hardware I'm using. Yes, it's elderly, but remember this is a test, and if this particular system ever sees use, it'll be on a home network. For a production environment, I'll use something newer, faster, and with a warranty.

• Compaq Proliant 800 (tower)
• Dual PIII 800Mhz processors
• 1 gig RAM
• 120 gigs storage (SCSI drives, hardware RAID)
• additional 300 gigs storage (IDE drive)
• FreeBSD 6.2
• Samba 3.0.24d

Although hardly cutting edge in terms of hardware, this is more than adequate for a small network with few users. Naturally, if this ever went into production, it would require a failover machine of some sort. There are many solutions, and I'll eventually get around to writing about that particular topic as well.

Installation of Samba on FreeBSD
This is trivial. First, update "ports". To do this, as root, change to the ports directory:
cd /usr/ports
Assuming you have your ports configuration file in your home directory, and it's named "ports-supfile", execute this command:

cvsup -g -L 2 ~/ports-supfile

Wait a bit. If it's been quite some time since you last updated ports, what a while. When it's done, execute these commands:

cd net/samba3
make
make install clean

I strongly encourage you to get a cup of coffee at this point. Or possibly take a nice, long nap. My installation took several hours. This is because it had to download the necessary components (including the ldap client) and compile everything. Of course, I was also rebuilding world at the same time (BSD aficionados will understand that reference) so I suppose it was my own fault.

Installation on Linux
For my CentOS installation of Samba, things were equally uncomplicated. CentOS, like many distros, uses the yum package manager. As root, I simply executed a search for the appropriate packages:

yum search samba

and got this result:

samba.i386 3.0.10-1.4E.9 base
Matched from:
samba
The Samba SMB server.
Samba is the protocol by which a lot of PC...

Yep, that's the one I'm looking for. Like ports, yum takes care of all the dependencies and so forth, so a simple...

yum install samba

...takes care of everything. Samba is now installed.

Purists will insist that Samba should be installed from source, and I suspect they are right. In fact, with very few exceptions, I usually install everything from source so I can fine tune it for my own needs. If you feel that this is the route for you with respect to Samba, then details for the various configurations options for doing so are available at http://www.samba.org.

Next time I'll get to the specifics of configuring smb.conf and adding users.

Making Samba your Primary Domain Controller - Part Deux

As promised, here is the continuation of my post on making Samba your Primary Domain Controller. Before you actually begin the installation, it's a good idea to try and work out some of the gritty details. How many users will there be? What operating system should you use? For example, if you have several hundred potential users, putting everything on that dusty old Pentium II with a single 10BaseT card in it is probably not such a great idea -- particularly if it's your phone that rings when network problems crop up.

Hardware Recommendations
Hardware requirements, as always, depend on the load to be handled. Since this is our single point of entry into network services, if the PDC goes down, then users can't access the network. This is bad. However, if you are going to have a relatively small number of users, re-purposing older gear might be a viable option for you. If this is the case for you, then you might want to keep a few rules of thumb in mind:

• Processor: A pair of Celerons or Durons will hold up better under load than a single Pentium class processor. If you have an old 2 way (or 4 way, or whatever) machine kicking around, give it a hard look. It might be a viable candidate for this.
  
• Memory: Processor speed is only one factor to bear in mind; memory is equally important. Max out your RAM.
• Disk: The disk subsystem also plays a major role. Samba acts as a file server. File servers read from and write to the disk, and they do it a lot. Get the fastest drive you can afford. You won't regret it.
• Network interface card: do you have an old 10 Base T card in there? Get rid of it, and spend a few bucks on at least a 100BaseT card. You won't regret it at all.

Operating System requirements
Samba runs on just about anything, including your toaster. It's supported on Linux, Unix, BSD, Mac OSX, Netware, AmigaDOS... well, you get the idea. This is largely a matter of taste. I've always been a fan of BSDs, so I chose FreeBSD. For fun, I did a simultaneous installation on CentOS as well.

Installation
First check to see if you have it installed already. Note these innocuous words of wisdom directly from the Samba site (emphasis added):

As always with Linux, there are two ways to install an application: RPM, or compile from source. (OK, there are three: Debian's apt-get. As I don't speak Debian, I'll leave that to the Debian Linux gurus.) RPM is easier, compile from source gives more control. Whichever method you choose, be sure to remove any existing Samba installations first.

Please, make certain you do not have Samba installed. If you do, remove it. If you happen to be running some version of Linux (an RPM based distro such as RedHat, CentOS, etc.) you can check by executing this command as root:

rpm -qa | grep amba

Yes, I left the "S" off, and no, that's not a typo. Sometimes it's installed as Samba-XX.rpm, and sometimes as samba-xx.rpm.

Which Version?
Samba 3.0 adds native connectivity with Microsoft's Active Directory, support for Microsoft's version of Kerberos, SAM (Security Accounts Manager) replication, and lots of other nifty features. It's the way to go. Older versions also support PDC functionality, but hey, that's yesterday's news. The latest version is faster, more stable, and more functional. It's a no brainer.

Next time, I'll take you through the actual installation and smb.conf configuration.

Making Samba your Primary Domain Controller - Part One

My Samba installation went so well that I've decided to improve our network at the office a bit. We are a small company, but there are enough of us to make a primary domain controller a good idea. I did a bit of browsing around the 'net to see how this is done in Samba, only to discover that all of the necessary instructions seem to be for Samba 2; I'm using Samba 3. "Oh well," I say to myself, "how much different can it be?"

Before we get into the ugly details, a bit of background is in order. First, what is a Primary Domain Controller (PDC)?

Domain Controller
A PDC is actually a pretty good idea. The goal is to store a user's log on information in one place, and allow them to access different services in the domain without needing multiple authentications. Samba makes an excellent PDC. It supports roaming profiles, domain logon from all Windows clients, Windows system policies, name services, master browser, and user-level security for Windows 9x/ME clients (assuming you actually have any of those; do you? Shame on you).

What does this mean? Well, if a Windows user logs on from any machine on your network, their profile goes with them, and they'll have access to only those things that they ought to have access to, and their desktop will look just like they expect it to. This is generally a good thing, and saves lots of pointless calls for help to the sysadmin.

This is of less value to a Mac, BSD, or Linux user, but let's face it -- Windows dominates in the business world, and will for some time to come. If this is the case on your network, then Samba as a PDC might serve very well for you.

A word of caution: just as was the case with Connor McLeod, "in the end, there can only be one." Don't try this if you have a PDC on your network already. Bad things will happen. Your network might blow up. Ethernet cables will melt. Your hair will fall out. Avoid the heartache, and instead try this on a test network, get it working fine, and then use your shiny new Samba PDC as a drop in replacement for whatever you're using now.

So how do you do this? From what I can find on the 'net it looks fairly painless. The steps are as follows:

1) Install Samba.
2) Edit smb.conf, the Samba configuration file.
3) Add machines and users.

I did see some references to Windows XP being a pain, and the Professional edition requiring a registry patch to work with Samba, but those were email messages made some time ago. From the silence on the topic for the past couple of years, I can only conclude one of two things: either Samba is not being used as a PDC by anyone now, or it works fine. I'm hoping for the latter.

I should also note that you can use your Samba PDC in a variety of other ways, although I have not personally tried some of these. For example, I found reference to using Samba as a member of an Active Directory domain (update: this is natively supported in Samba 3.0x), and there are a number of other suggestions in this article. A lot of information is dated, and needs to be tested, but I plan on trying a few different things.

In part II, I'll cover the installation and configuration.

Yes, it was the caffeine

It turns out that caffeine deprivation is not a good thing. Following copious quantities of Jamaican Blue Mountain bean, I successfully mounted Trolius (my new Samba server) on the network as a master browser. It worked, and I have no idea what I did differently. This is why I usually write things down as I do them.

The next step is to relocate this machine to a remove location, connect to the network at the office using OpenVPN, and start experimenting with rdiff-backup. Hopefully I'll have some time to do that over the weekend.

It's good to be back to coffee. I don't think I'll try giving it up again...

Irritations with Samba

I've been drinking less coffee lately, and that might go a long way towards explaining why I had such trouble trying to configure Samba last night. This should have been a trivial exercise, but my forehead is sore from banging it against the wall so much.

As a side note, I need to get softer walls.

The installation of Samba on FreeBSD is trivial. Just type:

cd /usr/ports/net/samba
make install clean

Wait a bit, and suddenly you have samba installed. The startup scripts are, as usual, in:

/usr/local/etc/rc.d

and the configuration files are in:

/usr/local/etc/samba.

Nothing unusual there.

The next step is to modify the sample configuration file (smb.conf). I copied it (to save the original) and opened it up. Wow. There are a lot of options in there. I decided to try something simple at first, just to get it working. I had formatted the filesystem to leave a large (750 gig) partition mounted as /archive. That was where I planned to have rdiff-backup store everything. Why not make that mount as a Windows fileserver? That should be easy.

Using the existing smb.conf file as a starting point, I examined some of the sample entries. Here's the one I went with:

;[public]
; path = /usr/somewhere/else/public
; public = yes
; only guest = yes
; writable = yes
; printable = no

This seemed simple enough, so I changed it to this (removing the semicolons, which are comment markers):

[Archive]
path = /archive
public = yes
writable = yes

That looked easy enough. I made the change, entered some simple stuff at the top (server name, etc.) and started the process. Typing ps ax | grep smb showed that the process was running, so I fired up a Windows laptop, typed this in the address bar of a window:

\\trolius.local\Archive

(trolius.local being the name of the box I am working on, obviously). Lo and behold, the server mounted! Great. Well, that was easy. Just to be sure that things were working as expected, I opened the "My Network Places" icon on my desktop, and browsed the local network.

No server.

And it's still not there. And I can't figure out why. I think I'll purchase some coffee and try again. Caffeine solves so many problems...

Step one complete...

I took the time necessary to do a clean install of FreeBSD 6.1 on my dual processor Compaq last evening. It was, as is usually the case with FreeBSD, a very painless process.

The only thing that was a bit annoying was setting up the SMP part of the kernel. By default, FreeBSD does not use a kernel that supports multiple processors. Fortunately, this is a simple thing to do (although it did take quite a while to compile).

Tonight I hope to start experimenting with Samba, and see how much it's changed since I last gave it any consideration. I'll also install rdiff-backup, as (if things go well) I'll need it fairly soon anyway.

Replacing a Windows Fileserver

We have been using an elderly Pentium II with an ancient install of Windows NT Server as our primary backup and file server for quite some time now. I was considering simply retiring the box, and replacing it with a newer machine with Windows Server 2003 (some variation thereof), when it occurred to me that reading about the open source alternative, Samba, has been on my to do list for quite some time.

Why make Microsoft any richer, when there is a free alternative out there?

This would also give me a chance to try out rdiff-backup, a rather nifty open source back up solution with point-in-time recovery (i.e. restore this file/directory/whatever to the condition it was last Tuesday at 11:23 AM). That would be very, very helpful in my line of work.

The Goal: use existing hardware and free software to create a fully functional Windows compatible file server and turf the elderly NT server solution. At the same time, design and implement a set-and-forget, point-in-time recovery capable backup strategy that will regularly poll live servers and our internal network and back everything up.

I'm going to start reading now. I'll keep you posted.