When we first asked for suggestions for inclusion in the Samba HOWTO documentation,
someone wrote asking for example configurations and lots of them. That is remarkably
difficult to do without losing a lot of value that can be derived from presenting
many extracts from working systems. That is what the rest of this document does.
It does so with extensive descriptions of the configuration possibilities within the
context of the chapter that covers it. We hope that this chapter is the medicine
that has been requested.
The information in this chapter is very sparse compared with the book “Samba-3 by Example”
that was written after the original version of this book was nearly complete. “Samba-3 by Example”
was the result of feedback from reviewers during the final copy editing of the first edition. It
was interesting to see that reader feedback mirrored that given by the original reviewers.
In any case, a month and a half was spent in doing basic research to better understand what
new as well as experienced network administrators would best benefit from. The book “Samba-3 by Example”
is the result of that research. What is presented in the few pages of this book is covered
far more comprehensively in the second edition of “Samba-3 by Example”. The second edition
of both books will be released at the same time.
So in summary, the book “The Official Samba-3 HOWTO & Reference Guide” is intended
as the equivalent of an auto mechanic's repair guide. The book “Samba-3 by Example” is the
equivalent of the driver's guide that explains how to drive the car. If you want complete network
configuration examples, go to Samba-3 by
Example.
Features and Benefits
Samba needs very little configuration to create a basic working system.
In this chapter we progress from the simple to the complex, for each providing
all steps and configuration file changes needed to make each work. Please note
that a comprehensively configured system will likely employ additional smart
features. These additional features are covered in the remainder of this document.
The examples used here have been obtained from a number of people who made
requests for example configurations. All identities have been obscured to protect
the guilty, and any resemblance to unreal nonexistent sites is deliberate.
Description of Example Sites
In the first set of configuration examples we consider the case of exceptionally simple system requirements.
There is a real temptation to make something that should require little effort much too complex.
??? documents the type of server that might be sufficient to serve CD-ROM images,
or reference document files for network client use. This configuration is also discussed in ???, ???. The purpose for this configuration
is to provide a shared volume that is read-only that anyone, even guests, can access.
The second example shows a minimal configuration for a print server that anyone can print to as long as they
have the correct printer drivers installed on their computer. This is a mirror of the system described in
???, ???.
The next example is of a secure office file and print server that will be accessible only to users who have an
account on the system. This server is meant to closely resemble a workgroup file and print server, but has to
be more secure than an anonymous access machine. This type of system will typically suit the needs of a small
office. The server provides no network logon facilities, offers no domain control; instead it is just a
network-attached storage (NAS) device and a print server.
The later example consider more complex systems that will either integrate into existing MS Windows networks
or replace them entirely. These cover domain member servers as well as Samba domain control (PDC/BDC) and
finally describes in detail a large distributed network with branch offices in remote locations.
Worked Examples
The configuration examples are designed to cover everything necessary to get Samba
running. They do not cover basic operating system platform configuration, which is
clearly beyond the scope of this text.
It is also assumed that Samba has been correctly installed, either by way of installation
of the packages that are provided by the operating system vendor or through other means.
Standalone Server
A standalone server implies no more than the fact that it is not a domain controller
and it does not participate in domain control. It can be a simple, workgroup-like
server, or it can be a complex server that is a member of a domain security context.
As the examples are developed, every attempt is made to progress the system toward greater capability, just as
one might expect would happen in a real business office as that office grows in size and its needs change.
Anonymous Read-Only Document Server
The purpose of this type of server is to make available to any user
any documents or files that are placed on the shared resource. The
shared resource could be a CD-ROM drive, a CD-ROM image, or a file
storage area.
The file system share point will be /export.
All files will be owned by a user called Jack Baumbach.
Jack's login name will be jackb. His password will be
m0r3pa1n of course, that's just the example we are
using; do not use this in a production environment because
all readers of this document will know it.
Procedure 2.1. Installation Procedure: Read-Only Server
Example 2.1. Anonymous Read-Only Server Configuration
# Global parameters
[global]
workgroup = MIDEARTH
netbios name = HOBBIT
security = share
[data]
comment = Data
path = /export
read only = Yes
guest ok = Yes
Add user to system (with creation of the user's home directory):
Test the configuration file by executing the following command:
root# testparm
Alternatively, where you are operating from a master configuration file called
smb.conf.master, the following sequence of commands might prove
more appropriate:
Note any error messages that might be produced. Proceed only if error-free output has been
obtained. An example of typical output that should be generated from the above configuration
file is shown here:
Load smb config files from /etc/samba/smb.conf
Processing section "[data]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
[Press enter]
# Global parameters
[global]
workgroup = MIDEARTH
netbios name = HOBBIT
security = share
[data]
comment = Data
path = /export
read only = Yes
guest only = Yes
Start Samba using the method applicable to your operating system platform. The method that
should be used is platform dependent. Refer to Starting Samba
for further information regarding the starting of Samba.
Configure your MS Windows client for workgroup MIDEARTH,
set the machine name to ROBBINS, reboot, wait a few (2 - 5) minutes,
then open Windows Explorer and visit the Network Neighborhood.
The machine HOBBIT should be visible. When you click this machine
icon, it should open up to reveal the data share. After
you click the share, it should open up to reveal the files previously
placed in the /export directory.
The information above (following # Global parameters) provides the complete
contents of the /etc/samba/smb.conf file.
Anonymous Read-Write Document Server
We should view this configuration as a progression from the previous example.
The difference is that shared access is now forced to the user identity of jackb
and to the primary group jackb belongs to. One other refinement we can make is to
add the user jackb to the smbpasswd file.
To do this, execute:
root# smbpasswd -a jackb
New SMB password: m0r3pa1n
Retype new SMB password: m0r3pa1n
Added user jackb.
Addition of this user to the smbpasswd file allows all files
to be displayed in the Explorer Properties boxes as belonging to jackb
instead of to User Unknown.
The complete, modified smb.conf file is as shown in ???.
Example 2.2. Modified Anonymous Read-Write smb.conf
# Global parameters
[global]
workgroup = MIDEARTH
netbios name = HOBBIT
security = SHARE
[data]
comment = Data
path = /export
force user = jackb
force group = users
read only = No
guest ok = Yes
Anonymous Print Server
An anonymous print server serves two purposes:
It allows printing to all printers from a single location.
It reduces network traffic congestion due to many users trying
to access a limited number of printers.
In the simplest of anonymous print servers, it is common to require the installation
of the correct printer drivers on the Windows workstation. In this case the print
server will be designed to just pass print jobs through to the spooler, and the spooler
should be configured to do raw pass-through to the printer. In other words, the print
spooler should not filter or process the data stream being passed to the printer.
In this configuration, it is undesirable to present the Add Printer Wizard, and we do
not want to have automatic driver download, so we disable it in the following
configuration. ??? is the resulting smb.conf file.
Example 2.3. Anonymous Print Server smb.conf
# Global parameters
[global]
workgroup = MIDEARTH
netbios name = LUTHIEN
security = share
printcap name = cups
disable spoolss = Yes
show add printer wizard = No
printing = cups
[printers]
comment = All Printers
path = /var/spool/samba
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = No
The above configuration is not ideal. It uses no smart features, and it deliberately
presents a less than elegant solution. But it is basic, and it does print. Samba makes
use of the direct printing application program interface that is provided by CUPS.
When Samba has been compiled and linked with the CUPS libraries, the default printing
system will be CUPS. By specifying that the printcap name is CUPS, Samba will use
the CUPS library API to communicate directly with CUPS for all printer functions.
It is possible to force the use of external printing commands by setting the value
of the printing to either SYSV or BSD, and thus the value of
the parameter printcap name must be set to something other than
CUPS. In such case, it could be set to the name of any file that contains a list
of printers that should be made available to Windows clients.
Note
Windows users will need to install a local printer and then change the print
to device after installation of the drivers. The print to device can then be set to
the network printer on this machine.
Make sure that the directory /var/spool/samba is capable of being used
as intended. The following steps must be taken to achieve this:
The directory must be owned by the superuser (root) user and group:
root# chown root.root /var/spool/samba
Directory permissions should be set for public read-write with the
sticky bit set as shown:
root# chmod a+twrx /var/spool/samba
The purpose of setting the sticky bit is to prevent who does not own the temporary print file
from being able to take control of it with the potential for devious misuse.
Note
On CUPS-enabled systems there is a facility to pass raw data directly to the printer without
intermediate processing via CUPS print filters. Where use of this mode of operation is desired,
it is necessary to configure a raw printing device. It is also necessary to enable the raw mime
handler in the /etc/mime.conv and /etc/mime.types
files. Refer to ???.
Secure Read-Write File and Print Server
We progress now from simple systems to a server that is slightly more complex.
Our new server will require a public data storage area in which only authenticated
users (i.e., those with a local account) can store files, as well as a home directory.
There will be one printer that should be available for everyone to use.
In this hypothetical environment (no espionage was conducted to obtain this data),
the site is demanding a simple environment that is secure enough
but not too difficult to use.
Site users will be Jack Baumbach, Mary Orville, and Amed Sehkah. Each will have
a password (not shown in further examples). Mary will be the printer administrator and will
own all files in the public share.
This configuration will be based on user-level security that
is the default, and for which the default is to store Microsoft Windows-compatible
encrypted passwords in a file called /etc/samba/smbpasswd.
The default smb.conf entry that makes this happen is
passdb backend = smbpasswd, guest. Since this is the default,
it is not necessary to enter it into the configuration file. Note that the guest backend is
added to the list of active passdb backends no matter whether it specified directly in Samba configuration
file or not.
Procedure 2.2. Installing the Secure Office Server
Configure the Samba smb.conf file as shown in ???.
Initialize the Microsoft Windows password database with the new users:
root# smbpasswd -a root
New SMB password: bigsecret
Reenter smb password: bigsecret
Added user root.
root# smbpasswd -a jackb
New SMB password: m0r3pa1n
Retype new SMB password: m0r3pa1n
Added user jackb.
root# smbpasswd -a maryo
New SMB password: secret
Reenter smb password: secret
Added user maryo.
root# smbpasswd -a ameds
New SMB password: mysecret
Reenter smb password: mysecret
Added user ameds.
Install printer using the CUPS Web interface. Make certain that all
printers that will be shared with Microsoft Windows clients are installed
as raw printing devices.
Start Samba using the operating system administrative interface.
Alternately, this can be done manually by executing:
root# nmbd; smbd;
Both applications automatically execute as daemons. Those who are paranoid about
maintaining control can add the -D flag to coerce them to start
up in daemon mode.
root# smbclient -L localhost -U%
Domain=[MIDEARTH] OS=[UNIX] Server=[Samba-3.0.20]
Sharename Type Comment
--------- ---- -------
public Disk Data
IPC$ IPC IPC Service (Samba-3.0.20)
ADMIN$ IPC IPC Service (Samba-3.0.20)
hplj4 Printer hplj4
Server Comment
--------- -------
OLORIN Samba-3.0.20
Workgroup Master
--------- -------
MIDEARTH OLORIN
The following error message indicates that Samba was not running:
root# smbclient -L olorin -U%
Error connecting to 192.168.1.40 (Connection refused)
Connection to olorin failed
Connect to OLORIN as maryo:
root# smbclient //olorin/maryo -Umaryo%secret
OS=[UNIX] Server=[Samba-3.0.20]
smb: \> dir
. D 0 Sat Jun 21 10:58:16 2003
.. D 0 Sat Jun 21 10:54:32 2003
Documents D 0 Fri Apr 25 13:23:58 2003
DOCWORK D 0 Sat Jun 14 15:40:34 2003
OpenOffice.org D 0 Fri Apr 25 13:55:16 2003
.bashrc H 1286 Fri Apr 25 13:23:58 2003
.netscape6 DH 0 Fri Apr 25 13:55:13 2003
.mozilla DH 0 Wed Mar 5 11:50:50 2003
.kermrc H 164 Fri Apr 25 13:23:58 2003
.acrobat DH 0 Fri Apr 25 15:41:02 2003
55817 blocks of size 524288. 34725 blocks available
smb: \> q
By now you should be getting the hang of configuration basics. Clearly, it is time to
explore slightly more complex examples. For the remainder of this chapter we abbreviate
instructions, since there are previous examples.
Domain Member Server
In this instance we consider the simplest server configuration we can get away with
to make an accounting department happy. Let's be warned, the users are accountants and they
do have some nasty demands. There is a budget for only one server for this department.
The network is managed by an internal Information Services Group (ISG), to which we belong.
Internal politics are typical of a medium-sized organization; Human Resources is of the
opinion that they run the ISG because they are always adding and disabling users. Also,
departmental managers have to fight tooth and nail to gain basic network resources access for
their staff. Accounting is different, though, they get exactly what they want. So this should
set the scene.
We use the users from the last example. The accounting department
has a general printer that all departmental users may use. There is also a check printer
that may be used only by the person who has authority to print checks. The chief financial
officer (CFO) wants that printer to be completely restricted and for it to be located in the
private storage area in her office. It therefore must be a network printer.
The accounting department uses an accounting application called SpytFull
that must be run from a central application server. The software is licensed to run only off
one server, there are no workstation components, and it is run off a mapped share. The data
store is in a UNIX-based SQL backend. The UNIX gurus look after that, so this is not our
problem.
The accounting department manager (maryo) wants a general filing system as well as a separate
file storage area for form letters (nastygrams). The form letter area should be read-only to
all accounting staff except the manager. The general filing system has to have a structured
layout with a general area for all staff to store general documents as well as a separate
file area for each member of her team that is private to that person, but she wants full
access to all areas. Users must have a private home share for personal work-related files
and for materials not related to departmental operations.
Example Configuration
The server valinor will be a member server of the company domain.
Accounting will have only a local server. User accounts will be on the domain controllers,
as will desktop profiles and all network policy files.
Example 2.5. Member Server smb.conf (Globals)
# Global parameters
[global]
workgroup = MIDEARTH
netbios name = VALINOR
security = DOMAIN
printcap name = cups
disable spoolss = Yes
show add printer wizard = No
idmap uid = 15000-20000
idmap gid = 15000-20000
winbind use default domain = Yes
printing = cups
Example 2.6. Member Server smb.conf (Shares and Services)
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[spytfull]
comment = Accounting Application Only
path = /export/spytfull
valid users = @Accounts
admin users = maryo
read only = Yes
[public]
comment = Data
path = /export/public
read only = No
[printers]
comment = All Printers
path = /var/spool/samba
printer admin = root, maryo
create mask = 0600
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = No
Do not add users to the UNIX/Linux server; all of this will run off the
central domain.
Join the domain. Note: Do not start Samba until this step has been completed!
root# net rpc join -Uroot%'bigsecret'
Joined domain MIDEARTH.
Make absolutely certain that you disable (shut down) the nscd
daemon on any system on which winbind is configured to run.
Start Samba following the normal method for your operating system platform.
If you wish to do this manually, execute as root:
root# nmbd; smbd; winbindd;
Configure the name service switch (NSS) control file on your system to resolve user and group names
via winbind. Edit the following lines in /etc/nsswitch.conf:
passwd: files winbind
group: files winbind
hosts: files dns winbind
Set the password for wbinfo to use:
root# wbinfo --set-auth-user=root%'bigsecret'
Validate that domain user and group credentials can be correctly resolved by executing:
For the remainder of this chapter the focus is on the configuration of domain control.
The examples that follow are for two implementation strategies. Remember, our objective is
to create a simple but working solution. The remainder of this book should help to highlight
opportunity for greater functionality and the complexity that goes with it.
A domain controller configuration can be achieved with a simple configuration using the new
tdbsam password backend. This type of configuration is good for small
offices, but has limited scalability (cannot be replicated), and performance can be expected
to fall as the size and complexity of the domain increases.
The use of tdbsam is best limited to sites that do not need
more than a Primary Domain Controller (PDC). As the size of a domain grows the need
for additional domain controllers becomes apparent. Do not attempt to under-resource
a Microsoft Windows network environment; domain controllers provide essential
authentication services. The following are symptoms of an under-resourced domain control
environment:
Domain logons intermittently fail.
File access on a domain member server intermittently fails, giving a permission denied
error message.
A more scalable domain control authentication backend option might use
Microsoft Active Directory or an LDAP-based backend. Samba-3 provides
for both options as a domain member server. As a PDC, Samba-3 is not able to provide
an exact alternative to the functionality that is available with Active Directory.
Samba-3 can provide a scalable LDAP-based PDC/BDC solution.
The tdbsam authentication backend provides no facility to replicate
the contents of the database, except by external means (i.e., there is no self-contained protocol
in Samba-3 for Security Account Manager database [SAM] replication).
Note
If you need more than one domain controller, do not use a tdbsam authentication backend.
Example: Engineering Office
The engineering office network server we present here is designed to demonstrate use
of the new tdbsam password backend. The tdbsam
facility is new to Samba-3. It is designed to provide many user and machine account controls
that are possible with Microsoft Windows NT4. It is safe to use this in smaller networks.
Example 2.7. Engineering Office smb.conf (globals)
[global]
workgroup = MIDEARTH
netbios name = FRODO
passdb backend = tdbsam
printcap name = cups
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/groupmod -A %u %g
delete user from group script = /usr/sbin/groupmod -R %u %g
Create user accounts on the system using the appropriate tool
provided with the operating system. Make sure all user home directories
are created also. Add users to groups as required for access control
on files, directories, printers, and as required for use in the Samba
environment.
Assign each of the UNIX groups to NT groups by executing this shell script
(You could name the script initGroups.sh):
#!/bin/bash
#### Keep this as a shell script for future re-use
# First assign well known groups
net groupmap add ntgroup="Domain Admins" unixgroup=ntadmins rid=512 type=d
net groupmap add ntgroup="Domain Users" unixgroup=users rid=513 type=
net groupmap add ntgroup="Domain Guests" unixgroup=nobody rid=514 type=d
# Now for our added Domain Groups
net groupmap add ntgroup="Designers" unixgroup=designers type=d
net groupmap add ntgroup="Engineers" unixgroup=engineers type=d
net groupmap add ntgroup="QA Team" unixgroup=qateam type=d
Create the scripts directory for use in the
[NETLOGON] share:
root# mkdir -p /var/lib/samba/netlogon/scripts
Place the logon scripts that will be used (batch or cmd scripts)
in this directory.
The above configuration provides a functional PDC
system to which must be added file shares and printers as required.
A Big Organization
In this section we finally get to review in brief a Samba-3 configuration that
uses a Lightweight Directory Access (LDAP)-based authentication backend. The
main reasons for this choice are to provide the ability to host primary
and Backup Domain Control (BDC), as well as to enable a higher degree of
scalability to meet the needs of a very distributed environment.
The Primary Domain Controller
This is an example of a minimal configuration to run a Samba-3 PDC
using an LDAP authentication backend. It is assumed that the operating system
has been correctly configured.
The Idealx scripts (or equivalent) are needed to manage LDAP-based POSIX and/or
SambaSamAccounts. The Idealx scripts may be downloaded from the
Idealx Web site. They may also be obtained from the Samba tarball. Linux
distributions tend to install the Idealx scripts in the
/usr/share/doc/packages/sambaXXXXXX/examples/LDAP/smbldap-tools directory.
Idealx scripts version smbldap-tools-0.9.1 are known to work well.
Example 2.9. LDAP backend smb.conf for PDC
# Global parameters
[global]
workgroup = MIDEARTH
netbios name = FRODO
passdb backend = ldapsam:ldap://localhost
username map = /etc/samba/smbusers
printcap name = cups
add user script = /usr/local/sbin/smbldap-useradd -m '%u'
delete user script = /usr/local/sbin/smbldap-userdel %u
add group script = /usr/local/sbin/smbldap-groupadd -p '%g'
delete group script = /usr/local/sbin/smbldap-groupdel '%g'
add user to group script = /usr/local/sbin/smbldap-groupmod -m '%u' '%g'
delete user from group script = /usr/local/sbin/smbldap-groupmod -x '%u' '%g'
set primary group script = /usr/local/sbin/smbldap-usermod -g '%g' '%u'
Obtain from the Samba sources ~/examples/LDAP/samba.schema
and copy it to the /etc/openldap/schema/ directory.
Set up the LDAP server. This example is suitable for OpenLDAP 2.1.x.
The /etc/openldap/slapd.conf file.
<title>Example slapd.conf File</title>
# Note commented out lines have been removed
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
database bdb
suffix "dc=quenya,dc=org"
rootdn "cn=Manager,dc=quenya,dc=org"
rootpw {SSHA}06qDkonA8hk6W6SSnRzWj0/pBcU3m0/P
# The password for the above is 'nastyon3'
directory /var/lib/ldap
index objectClass eq
index cn pres,sub,eq
index sn pres,sub,eq
index uid pres,sub,eq
index displayName pres,sub,eq
index uidNumber eq
index gidNumber eq
index memberUid eq
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default sub
Create the following file initdb.ldif:
# Organization for SambaXP Demo
dn: dc=quenya,dc=org
objectclass: dcObject
objectclass: organization
dc: quenya
o: SambaXP Demo
description: The SambaXP Demo LDAP Tree
# Organizational Role for Directory Management
dn: cn=Manager,dc=quenya,dc=org
objectclass: organizationalRole
cn: Manager
description: Directory Manager
# Setting up the container for users
dn: ou=People, dc=quenya, dc=org
objectclass: top
objectclass: organizationalUnit
ou: People
# Set up an admin handle for People OU
dn: cn=admin, ou=People, dc=quenya, dc=org
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}0jBHgQ1vp4EDX2rEMMfIudvRMJoGwjVb
# The password for above is 'mordonL8'
Load the initial data above into the LDAP database:
root# slapadd -v -l initdb.ldif
Start the LDAP server using the appropriate tool or method for
the operating system platform on which it is installed.
Install the Idealx script files in the /usr/local/sbin directory,
then configure the smbldap_conf.pm file to match your system configuration.
The smb.conf file that drives this backend can be found in example LDAP backend smb.conf for PDC. Add additional stanzas
as required.
Add the LDAP password to the secrets.tdb file so Samba can update
the LDAP database:
root# smbpasswd -w mordonL8
Add users and groups as required. Users and groups added using Samba tools
will automatically be added to both the LDAP backend and the operating
system as required.
Backup Domain Controller
??? shows the example configuration for the BDC. Note that
the smb.conf file does not specify the smbldap-tools scripts they are
not needed on a BDC. Add additional stanzas for shares and printers as required.
Example 2.10. Remote LDAP BDC smb.conf
# Global parameters
[global]
workgroup = MIDEARTH
netbios name = GANDALF
passdb backend = ldapsam:ldap://frodo.quenya.org
username map = /etc/samba/smbusers
printcap name = cups
logon script = scripts\logon.bat
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 33
preferred master = Yes
domain master = No
ldap suffix = dc=quenya,dc=org
ldap machine suffix = ou=People
ldap user suffix = ou=People
ldap group suffix = ou=People
ldap idmap suffix = ou=People
ldap admin dn = cn=Manager
ldap ssl = no
ldap passwd sync = Yes
idmap uid = 15000-20000
idmap gid = 15000-20000
printing = cups
Decide if the BDC should have its own LDAP server or not. If the BDC is to be
the LDAP server, change the following smb.conf as indicated. The default
configuration in Remote LDAP BDC smb.conf
uses a central LDAP server.
Configure the NETLOGON and PROFILES directory as for the PDC in ???.