Building and configuring a Samba PDC
This section covers server-side details of building and configuring a PDC using Samba. When building and configuring the PDC it is important to pay attention to details. When a project fails to work as advertised, nine times out of ten it's human error: a missing compile-time option, a spelling mistake in the configuration file, a permission bit set incorrectly, etc. The message here is to be methodical.
The following general steps are required to bring a Samba PDC online:
- Build/install Samba (if not already installed)
- Configure the
- Create the required directories on the server (if logon scripts or roaming profiles are to be used)
- Create the user and machine accounts
- Test the configuration and start the daemons
The final step is to configure the individual clients and join them to the domain; this is discussed in the next section, Client Configuration.
The first step is to ensure Samba is installed on your system. If not, you need to install it. The easiest way to check this (again, we're assuming Redhat 7.2 in this tutorial) is to type:
rpm -qa | grep samba
which will either produce a list of Samba-related RPM packages installed, or generate a blank line.
If Samba is installed, note the version number. When building a Samba domain controller, experience suggests using at least version 2.2.2. Better yet, use the latest stable code, which at the time of this writting is 2.2.3a. A lot of work has been done on domain controller functionality in the last two or three revisions. In addition, print functionality has been seriously reworked, the LDAP backend is now stable enough to be considered "production" capable, and scores of small bugs have been eradicated. All-in-all, version 2.2.3a is a stable, refined, and well-tested release.
If you plan to install or upgrade, there are two ways to go about it: compile from source, or install a pre-built RPM package. We'll take a look at the compile from source option in the next panel.
When installing via RPM, there are a couple caveats to keep in mind.
First, Redhat split their binary Samba RPM's into three parts:
samba-manual-xxxxx.rpm, where the x's represent the release version. The Samba team also builds binary packages for a variety of platforms (see http://us1.samba.org/ftp/Binary_Packages), but he chose to create a single installation RPM for Redhat distributions. So to ensure everything gets upgraded properly, uninstall any existing Samba packages before installing a new version! (
rpm -e samba).
Second, if you have an existing configuration file that you want to keep, back it up somewhere safe. It is possible to lose a valued configuration file to an installation gone awry.
Type man rpm for an explanation of the various options available for installing RPMs. The command
rpm -ivh samba-package should serve most needs.
Many administrators like to build all key server programs (for example, Apache, BIND, Samba, and so forth) from source. The reason is simple: building from source means you can tailor a program's features and components to your needs. You also know exactly what you've got on your system in terms of "clean, untouched" source code. Building Samba on a Redhat distribution can get a little tricky, however, due to variances in directory/file placements. The folks at RH designate /usr as the base installation directory. This means user-accessible utilities go in /usr/bin, and administrator utilities go in /usr/sbin; configuration files are placed in
/etc/samba. A default Samba configuration (meaning built from source with no configuration options), on the other hand, uses
/usr/local/samba as the base. So binaries are installed in
/usr/local/samba/bin, secure binaries go in
/usr/local/samba/sbin, and, rather unintuitively, Samba's configuration files end up in
The "gotcha" comes when someone unfamiliar with the above conventions installs Samba from source without uninstalling the Redhat version. He end up with two different versions on his system, and cannot figure out why -- after installing a shiny new Samba release -- his old version is still running. The old version is invoked because:
- The old version is on the "path"; the new version is not.
- The old version (RH built) is automatically started by a script in
/etc/init.dcalled samba (on some installations, this file may be called smb); an installation from source does not always create or correct the paths in the script.
TIP: You can determine Samba's version by typing
/usr/local/samba/bin/smbd -V (or the path to wherever your Samba binaries reside).
So when building from source the first decision that must be made is: Where will Samba reside?
There's nothing wrong with installing Samba in the
/usr/local tree; you just have to remember it's there, and remember to type the full path when running one of the program's utilities (or add the file locations to the path). The latter is really not a big issue, as once Samba is configured, started, and running, it just goes, and goes, and goes...
On the other hand, if your policy is to keep all program files in the bin/sbin directories, that too is possible. The next panel contains a step-by-step checklist for building Samba from source, plus an example
./configure command to do just that.
The following checklist should get anyone unfamiliar with building from source up and running with minimal fuss and frustration:
- If you have an existing Samba installation (in other words, from a RH RPM package), go to
/etc/init.dand copy the file samba (or smb) to a safe place for future reference. Also, as noted earlier in the tutorial, make a copy of your existing
smb.conf"just in case".
- Remove any existing Samba installations.
- Download the source tarball from your favorite Samba site. The latest stable release is always called
samba-latest.tar.gz. See the Resources section for the requisite URLs.
- I prefer to build all source code under
/usr/local/src, so this location is used for reference--substitute as desired. Copy the
/usr/local/src(or better yet, download the tarball directly there) and type tar
xvzf samba-latest.tar.gz. CD to the source directory (
/usr/local/src/samba/source). Note that many applications are configured to
./configurefrom the unzipped root directory (
/usr/local/src/samba). This is not the case with Samba, which is a common mistake made by people unfamiliar with the program. If you're comfortable with Samba installing under
--prefix= and xxxdir= optionsare not necessary.
./configure --helpto see Samba's configuration options. Below is a Redhat configure option recipe. The directory placement options shown will put Samba in the same locations as a Redhat built RPM.
- Once you've achieved an error-free configuration, type
- To copy the binaries to his final resting place, type make
- A word of caution: If you ever have to return and reconfigure Samba with different options, be sure to delete the
/usr/local/src/samba/source/config.cachefile before re-running the
./configurecommand. If you don't, Samba will configure itself using the previous option-set.
That's it! You should now have a functional Samba installation. Now to configure it to do something...
Listing 1. Samba installation
./configure \ --prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --libexecdir=/usr/libexec \ --datadir=/usr/share/samba \ --sysconfdir=/etc/samba \ --localstatedir=/usr/local/samba/var \ *** CHECK THE ABOVE *** --libdir=/usr/lib \ --with-lockdir=/var/locks/samba \ --with-swatdir=/usr/share/samba/swat \ --with-codepagedir=/etc/samba/codepages \ --with-configdir=/etc/samba \ --with-smbwrapper \ --with-automount \ --with-smbmount \ --with-pam \ --with-pam_smbpass \ --with-winbind
The power and flexibility of Samba is controlled by a single configuration file,
smb.conf. As noted earlier in this section,
smb.conf's location is dependent on the program location options used when the program was built. Two typical locations for smb.conf are
/etc/samba. The first thing anyone new to Samba should do is: (a) make a copy of
smb.conf so you always have a "clean" original; and (b) print it out and READ IT!
smb.conf is extensively documented, and a goldmine of valuable information for novices and seasoned veterans alike.
The structure and layout of
smb.conf is extremely simple. It consists of two main sections: [global] contains option statements that apply "globally" to the program, and a "shares" section. Each share begins with the name of the share enclosed in square brackets (for example, [homes]) and a list of option statements that apply to that share. Here's an important note to file away for future reference: Every Samba option statement has a default value. So specifying a different value in the global section overrides the default for the server as a whole, and specifying a value in a shares section overrides both the global option and the server's default option (if different).
A simple example is in order. By default (for example, the global default option) Samba allows anyone who passes the authentication process--typically a valid username/password combination--access to a listed share. An administrator can, however, restrict user access to a share by using the valid users = option. For example:
Listing 2. An example
[homes] comment = Home Directories valid users = tom, leah, suzie, bilbrey read only = No browseable = No
The above share can only be accessed by the users tom, leah, suzie, and bilbrey, effectively overriding any other options (implied or otherwise) specified in the [global] section of the configuration file.
Enough theory. Let's move on to the fun stuff--configuring a Samba domain controller.
Too many admins create initial configuration files that are six- or seven-page, and find themselves pulling out copious quantities of hair if their configurations fail to provide the expected results. All of this leads to an unnecessarily complex six- or seven-page. As you're about to see, a "basic" configuration that provides domain authentication, a logon script option, roaming profiles, and a few basic shares, is really quite simple to build. So in the spirit of keeping it simple, we're going to put our smb.conf file together in small, discrete pieces. This allows you to see which options do what, and digest the process in chewable chunks. The completed, fully functional
smb.conf can be downloaded from the Resources section.
Rather than mess around deleting and editing the six or seven page configuration file installed with Samba, we're going to start with a blank slate and add the following domain/machine options:
Listing 3. Domain/machine options
# /etc/samba/smb.conf # samba configuration file # last updated: 2/28/2002 by tms [global] ;basic server settings workgroup = syroidmanor netbios name = phoenix server string = Samba PDC running %v socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192
Comments begin with a hash (
#) or semicolon (
;) and are ignored; so too is whitespace. For those who don't already, providing liberal comments in your configuration files is an excellent habit to get into (especially when you make configuration changes; note the change and why it was made). The workgroup option, in the case of a domain controller, sets the domain name the controller will serve. Yes, I could have used
syroidmanor works and it's less typing for both user and admin. The netbios option is the host name. So the FQDN (Fully Qualified Domain Name) of this system is
server string provides a description that appears next to the share when browsing your "Network Neighborhood" from a Windows client. Next we need to tell Samba this machine is the PDC. Finally, the
socket options setting controls TCP/IP performance. The settings shown are known to work well with Linux-based systems. If you're using another OS, consult one of the documentation references listed at the end of this tutorial.
First, a word of caution: There can be only ONE PDC on the network. Having more than one PDC on a network will cause you no end of head-scratching and unexplained weirdness--don't go there.
To our existing smb.conf file we add the following options to the global section:
Listing 4. smb.conf file -- Global section
[global] ... ;PDC and master browser settings os level = 64 preferred master = yes local master = yes domain master = yes ...
To quote from O'Reilly & Associates' seminal title Using Samba (Eckstein, Collier-Brown, and Kelly; see the Resources section for more details): ...one machine in each subnet always keeps a list of the currently active machines. This list is called the browse list and the server that maintains it is called the local master browser. As machines come on and off the network, the local master browser continually updates the information in the browse list and provides it to any machine that requests it." Given that local master browser could itself become unavailable, election are called on a routine basis to determine who's authority is absolute (that is, which machine holds the most accurate local master browse list). The winner of an election is determined by a number of factors: election protocol (meaningless at this point in time), os level, the preferred master setting, the time online, and finally, alphabetically according to the machine's NetBIOS name. The first three settings in the above configuration ensure this machine is always consulted first regarding the current browse list. The
domain master option is the "switch" that tells Samba to be the primary domain controller.
The next step is to add some security and logging options:
Listing 5. Security and logging options
[global] ... ;security and logging settings security = user encrypt passwords = yes domain logons = yes log file = /var/log/samba/log.%m log level = 2 max log size = 50 hosts allow = 127.0.0.1 192.168.1.0/255.255.255.0
Samba supports four security options: share, user, server, and domain. The security option must be set to user on a Samba PDC. For an explanation of the other security modes, see page 164 of the previously referenced Using Samba title. The
encrypt passwords = yes option is also mandatory for a PDC. We'll touch briefly on the implications of this setting in the Client Configuration section of this tutorial. The
domain logons option simply tells Samba to support domain logons on this machine (versus authenticating via the PDC and then sending the client to another machine for logon scripts, home directories, etc.). The next option determines where log files are kept; %m is a substitution variable. It is replaced with the netbios name of the connecting machine (see Using Samba. Acceptable variables range from 1 to 10. Running a log level above 3 is not recommended unless very detailed debugging information is required; a high logging option will slow your system dramatically and produce copious output. In order to keep log files under control (filling your /var partition has very "ungood" consequences), we set
max log size = 50. This constrains each log file to a maximum of 50 kilobytes; when the file reaches this size, new entries displace the oldest entries. Last but not least, we ensure that only machines from our internal 192.168.1 subnet can connect to the server. Don't forget to add the localhostentry, especially if you plan to use SWAT.
Next up, we're going to add support for roaming profiles. A local profile consists of all the files and settings (Desktop, application configuration files not stored in the registry, Internet cache files, etc, etc, etc.) stored on the user's machine under
C:/Documents and Settings/username. With roaming profiles (or just profiles) enabled, these settings are stored on the local machine in a different folder (for example
C:/Documents and Settings/tom.SYROIDMANOR) and on logout, saved to a directory on the PDC. When the user logs back in, the server settings are then restored to the local host. The point of all this fanciness is to allow a user to logon to the domain from any machine on the network, and have their saved Desktop settings, Start Menu, and various configuration settings appear like magic. There is one caveat to profiles: They can consume a LOT of bandwidth synchronizing the required files. If your network is already stretched thin, roaming profiles are definitely not a good idea. First, let's populate our configuration file, then we'll explain what the various options do.
Listing 6. Configuration file
[global] ... ;user profiles and home directory logon home = \\%L\%U\.profile logon drive = H: logon path = \\%L\profiles\%U ... #===Shares=== [homes] comment = Home Directories browseable = no writeable = yes [profiles] path = /home/samba/profiles writeable = yes browseable = no create mask = 0600 directory mask = 0700
The most important point to note with the above global option block is that the directories referenced must be accompanied by a matching share (in this case, profiles). And ensure you spell the global reference and the share name the same. A common error is to spell one "profile" and one "profiles". When this occurs, users are denied access to the PDC. In addition, the directories must exist and must have the appropriate permissions set on them. Directory creation and permissions are detailed later in this section.
As you can see, the logon path = option uses variable substitution and pairs with the
[profiles] share. Assuming my username is tom and I'm trying to connect to the PDC named phoenix, the logon path line would substitute out as \\phoenix\profiles\tom (%L = the Samba server's netbios name = phoenix; %U = the username requesting the share = tom). The profiles name in the proceeding references the
[profiles] share. Putting it all together, we come up with the following: "When user tom tries to log into phoenix, his profile can be found in the
/home/samba/profiles/tom directory (for a first-time logon, Samba will create the tom directory). For security we make the
[profiles] share non-browseable (hidden to anyone browsing Network Neighborhood), writeable (mandatory if a user's profile is to be updated/kept in sync), we set the create mask to 0600 (rwx-xxx-xxx--only the user can read/write the files there), and we force any directories created to 0700 (rwx-xxx-xxx--directories must be executable if he is to be navigated).
One other thing to be aware of: Windows NT/2000 clients implement profiles differently than Windows 9x/ME clients, hence the two different approaches to the "logon" path. The logon home is Win9x/ME specific; Win9x/ME restricts profiles to the user's home directory. The logon path is Windows NT/2000 specific, and has no such restrictions. Having both option in your configuration file simply broadens its applicability. Of course, if you have no Win9x clients on site, feel free to delete as appropriate.
Next, we're going to look at the special
[homes] share and how it works.
[homes] (Caution! That's "homes", not "home") share is one of three special sections within Samba's configuration file (the other two are
[printers]). If a client attempts to connect to a share that doesn't exist, and the
[homes] share is present in smb.conf, Samba assumes the user is trying to connect to their home directory. The program then searches its user database (smbpasswd; stay tuned for more on this topic) for a username and password combination the same as the user requesting the invalid share. If found, the username is substituted into the logon home option statement. Using our friend tom as an example, the global option would expand to
\\%L\%U, which in turn translates to
\\phoenix\tom. If no share called
[tom] exists, Samba creates one using the path = option supplied in the
[homes] share and assigns the share the Windows drive letter... Yep, you guessed it... H: (per the global option logon drive = H:; this can be any drive letter not already in use on the client machine). If no path = statement exists under
[homes], /home/username is assumed. Pretty smart program, wouldn't you say?
We have one more global/shares option pairing to consider: netlogon.
The final piece we're going to add to smb.conf (well, at least for now... ) is the logon script option. Like the [homes] and [profile] shares, there are two pieces to the puzzle:
Listing 7. Netlogon option
[global] ... logon script = netlogon.bat ... # === shares === ... [netlogon] path = /home/netlogon read only = yes write list = tom
[netlogon] share is administrative tool used primarily for globally updating client machines with items like registry patches, anti-virus updates, program updates, etc. Anything you want to "push" out to the client, can be done via netlogon. In addition, you can use the share to enforce a system policy on a client or clients or perhaps backup a select group of files every time the user logs on. Creating scripts to run from netlogon is beyond the scope of this tutorial, but you'll find plenty of information on the Samba.org site and by searching Google with the string "samba scripting".
Here's how netlogon works: Any time a user logon onto the PDC and the
logon script = option and
[netlogon] share are present, Samba goes to the indicated path and executes the file referenced by logon script. Once again, some brief caveats are in order:
- The file referenced by logon script can be called anything as long as Windows recognizes it as an executable file.
- If the file referenced is not found, Samba continues on its merry way and connects the user to the requested share(s).
- Be sure to set the UNIX-side permissions to executable.
- To delegate responsibility for scripts in the netlogon share, create an "admin" group and add this group to the
write list = optionin the form:
write list = @admin(the '@' notation signifies a group).
- Be sure to test your scripts thoroughly in a non-production environment. Trashing the registry on 600 client machines is not a good career move.
Below, for reference, is the fully assembled Samba PDC configuration file:
Listing 8. Samba PDC configuration file
# /etc/samba/smb.conf # samba configuration file # last updated: 2/28/2002 by tms [global] ;basic server settings workgroup = syroidmanor netbios name = phoenix server string = Samba PDC running %v socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192 ;PDC and master browser settings os level = 64 preferred master = yes local master = yes domain master = yes ;security and logging settings security = user encrypt passwords = yes log file = /var/log/samba/log.%m log level = 2 max log size = 50 hosts allow = 127.0.0.1 192.168.1.0/255.255.255.0 ;user profiles and home directory logon home = \\%L\%U\ logon drive = H: logon path = \\%L\profiles\%U logon script = netlogon.bat # ==== shares ==== [homes] comment = Home Directories browseable = no writeable = yes [profiles] path = /home/samba/profiles writeable = yes browseable = no create mask = 0600 directory mask = 0700 [netlogon] comment = Network Logon Service path = /home/netlogon read only = yes browseable = no write list = tom
Next is the topic of authentication: adding user and machine accounts to the domain controller.