Skip to main content

If you don't have an IBM ID and password, register here.

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. This profile includes the first name, last name, and display name you identified when you registered with developerWorks. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

Using Samba as a PDC

Tom Syroid is a contract writer for Studio B Productions, a literary agency based in Indianapolis, IN specializing in computer-oriented publications. Topics of interest/specialty include *NIX system security, Samba, Apache, and Web database applications based on PHP and MySQL. He has experience administering and maintaining a diverse range of operating systems including Linux (Red Hat, OpenLinux, Mandrake, Slackware, Gentoo), Windows (95, 98, NT, 2000, and XP), and AIX (4.3.3 and 5.1). He is also the co-author of Outlook 2000 in a Nutshell (O'Reilly & Associates) and OpenLinux Secrets (Hungry Minds). Tom lives in Saskatoon, Saskatchewan with his wife and two children. Hobbies include breaking perfectly good computer installations and then figuring out how to fix them, gardening, reading, and building complex structures out of Lego with his kids. Questions, comments, and errata submissions are welcome; you can either e-mail the author directly (dwcomments@syroidmanor.com.

Summary:  Open-source Samba turns a UNIX or Linux system into a file and print server for Microsoft Windows network clients. Tom Syroid dishes up a juicy tutorial that shows you how to configure Samba as the primary domain controller on an xSeries server.

Date:  03 Apr 2002
Level:  Introductory

Comments:  

Building and configuring a Samba PDC

Server-side configuration

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 smb.conf file
  • 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.


Installing Samba

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-common-xxxxx.rpm; samba-server-xxxxx.rpm; and 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.


Building from source

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 /usr/local/samba/lib.

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.d called 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.


Building from source: A checklist

The following checklist should get anyone unfamiliar with building from source up and running with minimal fuss and frustration:

  1. If you have an existing Samba installation (in other words, from a RH RPM package), go to /etc/init.d and 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".
  2. Remove any existing Samba installations.
  3. 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.
  4. I prefer to build all source code under /usr/local/src, so this location is used for reference--substitute as desired. Copy the tar.gz file to /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 ./configure from 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 /usr/local/samba, then --prefix= and xxxdir= options are not necessary.
  5. Type ./configure --help to 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.
  6. Once you've achieved an error-free configuration, type make.
  7. To copy the binaries to his final resting place, type make install.
  8. 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.cache file before re-running the ./configure command. 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


Introducing smb.conf

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 /usr/local/samba/lib and /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.


Basic server settings

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.com, but 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 phoenix.syroidmanor[.com]. The 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.


PDC and master browser settings

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.


Security settings

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.


Roaming profiles

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.


The [homes] share

The [homes] (Caution! That's "homes", not "home") share is one of three special sections within Samba's configuration file (the other two are [global] and [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 netlogon option

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

The [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 = option in 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.

The final cut

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.

2 of 8 | Previous | Next

Comments



Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=105868
TutorialTitle=Using Samba as a PDC
publish-date=04032002
author1-email=dwcomments@syroidmanor.com
author1-email-cc=

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).

My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).