Introduction to Samba
The third major release of Samba, version 3.0.0, introduced numerous improvements from prior versions, including:
The ability to join an Active Directory domain by means of LDAP and Kerberos
Built in Unicode support for internationalization
Support for Microsoft Windows XP Professional client connections to Samba servers without needing local registry hacking
Two new documents developed by the Samba.org team, which include a 400+ page reference manual, and a 300+ page implementation and integration manual.
Samba is a powerful and versatile server application. Even seasoned system administrators must know its abilities and limitations before attempting installation and configuration.
What Samba can do:
Serve directory trees and printers to Linux, UNIX, and Windows clients
Assist in network browsing (with or without NetBIOS)
Authenticate Windows domain logins
Provide Windows Internet Name Service (WINS) name server resolution
Act as a Windows NT®-style Primary Domain Controller (PDC)
Act as a Backup Domain Controller (BDC) for a Samba-based PDC
Act as an Active Directory domain member server
Join a Windows NT/2000/2003 PDC
What Samba cannot do:
Act as a BDC for a Windows PDC (and vice versa)
Act as an Active Directory domain controller
The following is a brief introduction to the individual Samba daemons and services.
Samba is comprised of three daemons (smbd, nmbd, and winbindd). Two services (smb and windbind) control how the daemons are started, stopped, and other service-related features. Each daemon is listed in detail, as well as which specific service has control over it.
The smbd server daemon provides file sharing and printing services to Windows clients. In addition, it is responsible for user authentication, resource locking, and data sharing through the SMB protocol. The default ports on which the server listens for SMB traffic are TCP ports 139 and 445.
The smbd daemon is controlled by the smb service.
The nmbd server daemon understands and replies to NetBIOS name service requests such as those produced by SMB/CIFS in Windows-based systems. These systems include Windows 95/98/ME, Windows NT, Windows 2000, Windows XP, and LanManager clients. It also participates in the browsing protocols that make up the Windows Network Neighborhood view. The default port that the server listens to for NMB traffic is UDP port 137.
The nmbd daemon is controlled by the smb service.
The winbind service resolves user and group information on a server running Windows NT 2000 or Windows Server 2003. This makes Windows user / group information understandable by UNIX platforms. This is achieved by using Microsoft RPC calls, Pluggable Authentication Modules (PAM), and the Name Service Switch (NSS). This allows Windows NT domain users to appear and operate as UNIX users on a UNIX machine. Though bundled with the Samba distribution, the winbind service is controlled separately from the smb service.
The winbindd daemon is controlled by the winbind service and does not require the smb service to be started in order to operate. Winbindd is also used when Samba is an Active Directory member, and may also be used on a Samba domain controller (to implement nested groups and/or interdomain trust). Because winbind is a client-side service used to connect to Windows NT-based servers, further discussion of winbind is beyond the scope of this manual.
Connecting to a Samba Share
You can use Nautilus to view available Samba shares on your network. Select Places (on the Panel) => Network Servers to view a list of Samba workgroups on your network. You can also type smb: in the File => Open Location bar of Nautilus to view the workgroups.
As shown in Figure 19.1, “SMB Workgroups in Nautilus”, an icon appears for each available SMB workgroup on the network.
Figure 19.1. SMB Workgroups in Nautilus
Double-click one of the workgroup icons to view a list of computers within the workgroup.
Figure 19.2. SMB Machines in Nautilus
As you can see from Figure 19.2, “SMB Machines in Nautilus”, there is an icon for each machine within the workgroup. Double-click on an icon to view the Samba shares on the machine. If a username and password combination is required, you are prompted for them.
Alternately, you can also specify the Samba server and sharename in the Location: bar for Nautilus using the following syntax (replace
To query the network for Samba servers, use the findsmb command. For each server found, it displays its IP address, NetBIOS name, workgroup name, operating system, and SMB server version.
To connect to a Samba share from a shell prompt, type the following command:
If you see the smb:\> prompt, you have successfully logged in. Once you are logged in, type help for a list of commands. If you wish to browse the contents of your home directory, replace sharename with your username. If the -U switch is not used, the username of the current user is passed to the Samba server.
To exit smbclient, type exit at the smb:\> prompt.
Mounting the Share
Sometimes it is useful to mount a Samba share to a directory so that the files in the directory can be treated as if they are part of the local file system.
To mount a Samba share to a directory, create create a directory to mount it to (if it does not already exist), and execute the following command as root:
mount -t cifs -o
, // / /mnt/point/
This command mounts
Configuring a Samba Server
The default configuration file (/etc/samba/smb.conf) allows users to view their home directories as a Samba share. It also shares all printers configured for the system as Samba shared printers. In other words, you can attach a printer to the system and print to it from the Windows machines on your network.
19.4.1. Graphical Configuration
To configure Samba using a graphical interface, use the Samba Server Configuration Tool. For command line configuration, skip to Section 19.4.2, “Command Line Configuration”.
The Samba Server Configuration Tool is a graphical interface for managing Samba shares, users, and basic server settings. It modifies the configuration files in the /etc/samba/ directory. Any changes to these files not made using the application are preserved.
To use this application, you must be running the X Window System, have root privileges, and have the system-config-samba RPM package installed. To start the Samba Server Configuration Tool from the desktop, go to the System (on the Panel) => Administration => Server Settings => Samba or type the command system-config-samba at a shell prompt (for example, in an XTerm or a GNOME terminal).
Figure 19.3. Samba Server Configuration Tool
The Samba Server Configuration Tool does not display shared printers or the default stanza that allows users to view their own home directories on the Samba server.
Configuring Server Settings
The first step in configuring a Samba server is to configure the basic settings for the server and a few security options. After starting the application, select Preferences => Server Settings from the pulldown menu. The Basic tab is displayed as shown in Figure 19.4, “Configuring Basic Server Settings”.
Figure 19.4. Configuring Basic Server Settings
On the Basic tab, specify which workgroup the computer should be in as well as a brief description of the computer. They correspond to the workgroup and server string options in smb.conf.
Figure 19.5. Configuring Security Server Settings
The Security tab contains the following options:
Authentication Mode — This corresponds to the security option. Select one of the following types of authentication.
ADS — The Samba server acts as a domain member in an Active Directory Domain (ADS) realm. For this option, Kerberos must be installed and configured on the server, and Samba must become a member of the ADS realm using the net utility, which is part of the samba-client package. Refer to the net man page for details. This option does not configure Samba to be an ADS Controller. Specify the realm of the Kerberos server in the Kerberos Realm field.
The Kerberos Realm field must be supplied in all uppercase letters, such as EXAMPLE.COM.
Using a Samba server as a domain member in an ADS realm assumes proper configuration of Kerberos, including the /etc/krb5.conf file.
Domain — The Samba server relies on a Windows NT Primary or Backup Domain Controller to verify the user. The server passes the username and password to the Controller and waits for it to return. Specify the NetBIOS name of the Primary or Backup Domain Controller in the Authentication Server field.
The Encrypted Passwords option must be set to Yes if this is selected.
Server — The Samba server tries to verify the username and password combination by passing them to another Samba server. If it can not, the server tries to verify using the user authentication mode. Specify the NetBIOS name of the other Samba server in the Authentication Server field.
Share — Samba users do not have to enter a username and password combination on a per Samba server basis. They are not prompted for a username and password until they try to connect to a specific shared directory from a Samba server.
User — (Default) Samba users must provide a valid username and password on a per Samba server basis. Select this option if you want the Windows Username option to work. Refer to Section 184.108.40.206, “Managing Samba Users” for details.
Encrypt Passwords — This option must be enabled if the clients are connecting from a system with Windows 98, Windows NT 4.0 with Service Pack 3, or other more recent versions of Microsoft Windows. The passwords are transfered between the server and the client in an encrypted format instead of as a plain-text word that can be intercepted. This corresponds to the encrypted passwords option. Refer to Section 19.4.3, “Encrypted Passwords” for more information about encrypted Samba passwords.
Guest Account — When users or guest users log into a Samba server, they must be mapped to a valid user on the server. Select one of the existing usernames on the system to be the guest Samba account. When guests log in to the Samba server, they have the same privileges as this user. This corresponds to the guest account option.
After clicking OK, the changes are written to the configuration file and the daemon is restarted; thus, the changes take effect immediately.
Managing Samba Users
The Samba Server Configuration Tool requires that an existing user account be active on the system acting as the Samba server before a Samba user can be added. The Samba user is associated with the existing user account.
Figure 19.6. Managing Samba Users
To add a Samba user, select Preferences => Samba Users from the pulldown menu, and click the Add User button. In the Create New Samba User window select a Unix Username from the list of existing users on the local system.
If the user has a different username on a Windows machine and needs to log into the Samba server from the Windows machine, specify that Windows username in the Windows Username field. The Authentication Mode on the Security tab of the Server Settings preferences must be set to User for this option to work.
Also, configure a Samba Password for the Samba User and confirm it by typing it again. Even if you opt to use encrypted passwords for Samba, it is recommended that the Samba passwords for all users are different from their system passwords.
To edit an existing user, select the user from the list, and click Edit User. To delete an existing Samba user, select the user, and click the Delete User button. Deleting a Samba user does not delete the associated system user account.
The users are modified immediately after clicking the OK button.
Adding a Share
To create a Samba share, click the Add button from the main Samba configuration window.
Figure 19.7. Adding a Share
The Basic tab configures the following options:
Directory — The directory to share via Samba. The directory must exist before it can be entered here.
Share name — The actual name of the share that is seen from remote machines. By default, it is the same value as Directory, but can be configured.
Descriptions — A brief description of the share.
Writable — Enables users to read and write to the shared directory
Visible — Grants read-only rights to users for the shared directory.
On the Access tab, select whether to allow only specified users to access the share or whether to allow all Samba users to access the share. If you select to allow access to specific users, select the users from the list of available Samba users.
The share is added immediately after clicking OK.
Command Line Configuration
Samba uses /etc/samba/smb.conf as its configuration file. If you change this configuration file, the changes do not take effect until you restart the Samba daemon with the command service smb restart.
To specify the Windows workgroup and a brief description of the Samba server, edit the following lines in your smb.conf file:
workgroup = WORKGROUPNAME server string = BRIEF COMMENT ABOUT SERVER
Replace WORKGROUPNAME with the name of the Windows workgroup to which this machine should belong. The BRIEF COMMENT ABOUT SERVER is optional and is used as the Windows comment about the Samba system.
To create a Samba share directory on your Linux system, add the following section to your smb.conf file (after modifying it to reflect your needs and your system):
[sharename] comment = Insert a comment here path = /home/share/ valid users = tfox carole public = no writable = yes printable = no create mask = 0765
The above example allows the users tfox and carole to read and write to the directory /home/share, on the Samba server, from a Samba client.
Encrypted passwords are enabled by default because it is more secure to do so. To create a user with an encrypted password, use the command smbpasswd -a
Starting and Stopping Samba
To start a Samba server, type the following command in a shell prompt while logged in as root:
/sbin/service smb start
To set up a domain member server, you must first join the domain or Active Directory using the net join command before starting the smb service.
To stop the server, type the following command in a shell prompt while logged in as root:
/sbin/service smb stop
The restart option is a quick way of stopping and then starting Samba. This is the most reliable way to make configuration changes take effect after editing the configuration file for Samba. Note that the restart option starts the daemon even if it was not running originally.
To restart the server, type the following command in a shell prompt while logged in as root:
/sbin/service smb restart
The condrestart (conditional restart) option only starts smb on the condition that it is currently running. This option is useful for scripts, because it does not start the daemon if it is not running.
When the smb.conf file is changed, Samba automatically reloads it after a few minutes. Issuing a manual restart or reload is just as effective.
To conditionally restart the server, type the following command as root:
/sbin/service smb condrestart
A manual reload of the smb.conf file can be useful in case of a failed automatic reload by the smb service. To ensure that the Samba server configuration file is reloaded without restarting the service, type the following command as root:
/sbin/service smb reload
By default, the smb service does not start automatically at boot time. To configure Samba to start at boot time, use an initscript utility, such as /sbin/chkconfig, /usr/sbin/ntsysv, or the Services Configuration Tool program.
The Lightweight Directory Access Protocol (LDAP) is a set of open protocols used to access centrally stored information over a network. It is based on the X.500 standard for directory sharing, but is less complex and resource-intensive. For this reason, LDAP is sometimes referred to as "X.500 Lite." The X.500 standard is a directory that contains hierarchical and categorized information, which could include information such as names, addresses, and phone numbers.
Like X.500, LDAP organizes information in a hierarchal manner using directories. These directories can store a variety of information and can even be used in a manner similar to the Network Information Service (NIS), enabling anyone to access their account from any machine on the LDAP enabled network.
In many cases, LDAP is used as a virtual phone directory, allowing users to easily access contact information for other users. But LDAP is more flexible than a traditional phone directory, as it is capable of referring a querent to other LDAP servers throughout the world, providing an ad-hoc global repository of information. Currently, however, LDAP is more commonly used within individual organizations, like universities, government departments, and private companies.
LDAP is a client/server system. The server can use a variety of databases to store a directory, each optimized for quick and copious read operations. When an LDAP client application connects to an LDAP server, it can either query a directory or attempt to modify it. In the event of a query, the server either answers the query locally, or it can refer the querent to an LDAP server which does have the answer. If the client application is attempting to modify information within an LDAP directory, the server verifies that the user has permission to make the change and then adds or updates the information.
This chapter refers to the configuration and use of OpenLDAP 2.0, an open source implementation of the LDAPv2 and LDAPv3 protocols.
Why Use LDAP?
The main benefit of using LDAP is that information for an entire organization can be consolidated into a central repository. For example, rather than managing user lists for each group within an organization, LDAP can be used as a central directory accessible from anywhere on the network. And because LDAP supports Secure Sockets Layer (SSL) and Transport Layer Security (TLS), sensitive data can be protected from prying eyes.
LDAP also supports a number of back-end databases in which to store directories. This allows administrators the flexibility to deploy the database best suited for the type of information the server is to disseminate. Because LDAP also has a well-defined client Application Programming Interface (API), the number of LDAP-enabled applications are numerous and increasing in quantity and quality.
OpenLDAP includes a number of important features.
LDAPv3 Support — OpenLDAP supports Simple Authentication and Security Layer (SASL), Transport Layer Security (TLS), and Secure Sockets Layer (SSL), among other improvements. Many of the changes in the protocol since LDAPv2 are designed to make LDAP more secure.
IPv6 Support — OpenLDAP supports the next generation Internet Protocol version 6.
LDAP Over IPC — OpenLDAP can communicate within a system using interprocess communication (IPC). This enhances security by eliminating the need to communicate over a network.
Updated C API — Improves the way programmers can connect to and use LDAP directory servers.
LDIFv1 Support — Provides full compliance with the LDAP Data Interchange Format (LDIF) version 1.
Enhanced Stand-Alone LDAP Server — Includes an updated access control system, thread pooling, better tools, and much more.
Any discussion of LDAP requires a basic understanding of a set of LDAP-specific terms:
entry — A single unit within an LDAP directory. Each entry is identified by its unique Distinguished Name (DN).
attributes — Information directly associated with an entry. For example, an organization could be represented as an LDAP entry. Attributes associated with the organization might include a fax number, an address, and so on. People can also be represented as entries in an LDAP directory, with common attributes such as the person's telephone number and email address.
Some attributes are required, while other attributes are optional. An objectclass definition sets which attributes are required for each entry. Objectclass definitions are found in various schema files, located in the /etc/openldap/schema/ directory. For more information, refer to Section 24.5, “The /etc/openldap/schema/ Directory”.
The assertion of an attribute and its corresponding value is also referred to as a Relative Distinguished Name (RDN). An RDN is only unique per entry, whereas a DN is globally unique.
LDIF — The LDAP Data Interchange Format (LDIF) is an ASCII text representation of LDAP entries. Files used for importing data to LDAP servers must be in LDIF format. An LDIF entry looks similar to the following example:
[<id>] dn: <distinguished name> <attrtype>: <attrvalue> <attrtype>: <attrvalue> <attrtype>: <attrvalue>
Each entry can contain as many <attrtype>: <attrvalue> pairs as needed. A blank line indicates the end of an entry.
All <attrtype> and <attrvalue> pairs must be defined in a corresponding schema file to use this information.
Any value enclosed within a < and a > is a variable and can be set whenever a new LDAP entry is created. This rule does not apply, however, to <id>. The <id> is a number determined by the application used to edit the entry.
OpenLDAP Daemons and Utilities
The suite of OpenLDAP libraries and tools are included within the following packages:
openldap — Contains the libraries necessary to run the OpenLDAP server and client applications.
openldap-clients — Contains command line tools for viewing and modifying directories on an LDAP server.
openldap-servers — Contains the servers and other utilities necessary to configure and run an LDAP server.
There are two servers contained in the openldap-servers package: the Standalone LDAP Daemon (/usr/sbin/slapd) and the Standalone LDAP Update Replication Daemon (/usr/sbin/slurpd).
The slapd daemon is the standalone LDAP server while the slurpd daemon is used to synchronize changes from one LDAP server to other LDAP servers on the network. The slurpd daemon is only used when dealing with multiple LDAP servers.
To perform administrative tasks, the openldap-servers package installs the following utilities into the /usr/sbin/ directory:
slapadd — Adds entries from an LDIF file to an LDAP directory. For example, the command /usr/sbin/slapadd -l ldif-input reads in the LDIF file, ldif-input, containing the new entries.
Only the root user may use /usr/sbin/slapadd. However, the directory server runs as the ldap user. Therefore the directory server is unable to modify any files created by slapadd. To correct this issue, after using slapadd, type the following command:
chown -R ldap /var/lib/ldap
slapcat — Pulls entries from an LDAP directory in the default format, Sleepycat Software's Berkeley DB system, and saves them in an LDIF file. For example, the command /usr/sbin/slapcat -l ldif-output outputs an LDIF file called ldif-output containing the entries from the LDAP directory.
slapindex — Re-indexes the slapd directory based on the current content. This tool should be run whenever indexing options within /etc/openldap/slapd.conf are changed.
slappasswd — Generates an encrypted user password value for use with ldapmodify or the rootpw value in the slapd configuration file, /etc/openldap/slapd.conf. Execute the /usr/sbin/slappasswd command to create the password.
You must stop slapd by issuing the /sbin/service ldap stop command before using slapadd, slapcat or slapindex. Otherwise, the integrity of the LDAP directory is at risk.
For more information on using these utilities, refer to their respective man pages.
The openldap-clients package installs tools into /usr/bin/ which are used to add, modify, and delete entries in an LDAP directory. These tools include the following:
ldapadd — Adds entries to an LDAP directory by accepting input via a file or standard input; ldapadd is actually a hard link to ldapmodify -a.
ldapdelete — Deletes entries from an LDAP directory by accepting user input at a shell prompt or via a file.
ldapmodify — Modifies entries in an LDAP directory, accepting input via a file or standard input.
ldappasswd — Sets the password for an LDAP user.
ldapsearch — Searches for entries in an LDAP directory using a shell prompt.
ldapcompare — Opens a connection to an LDAP server, binds, and performs a comparison using specified parameters.
ldapwhoami — Opens a connection to an LDAP server, binds, and performs a whoami operation.
ldapmodrdn — Opens a connection to an LDAP server, binds, and modifies the RDNs of entries.
With the exception of ldapsearch, each of these utilities is more easily used by referencing a file containing the changes to be made rather than typing a command for each entry to be changed within an LDAP directory. The format of such a file is outlined in the man page for each utility.
NSS, PAM, and LDAP
In addition to the OpenLDAP packages, Red Hat Enterprise Linux includes a package called nss_ldap, which enhances LDAP's ability to integrate into both Linux and other UNIX environments.
The nss_ldap package provides the following modules (where
The nss_ldap package provides the following modules for Itanium or AMD64 architectures:
The pam_ldap module allows PAM-aware applications to authenticate users using information stored in an LDAP directory. PAM-aware applications include console login, POP and IMAP mail servers, and Samba. By deploying an LDAP server on a network, all of these applications can authenticate using the same user ID and password combination, greatly simplifying administration.
For more about configuring PAM, refer to Section 42.4, “Pluggable Authentication Modules (PAM)” and the PAM man pages.
PHP4, LDAP, and the Apache HTTP Server
Red Hat Enterprise Linux includes a package containing an LDAP module for the PHP server-side scripting language.
The php-ldap package adds LDAP support to the PHP4 HTML-embedded scripting language via the /usr/lib/php4/ldap.so module. This module allows PHP4 scripts to access information stored in an LDAP directory.
Red Hat Enterprise Linux ships with the mod_authz_ldap module for the Apache HTTP Server. This module uses the short form of the distinguished name for a subject and the issuer of the client SSL certificate to determine the distinguished name of the user within an LDAP directory. It is also capable of authorizing users based on attributes of that user's LDAP directory entry, determining access to assets based on the user and group privileges of the asset, and denying access for users with expired passwords. The mod_ssl module is required when using the mod_authz_ldap module.
The mod_authz_ldap module does not authenticate a user to an LDAP directory using an encrypted password hash. This functionality is provided by the experimental mod_auth_ldap module, which is not included with Red Hat Enterprise Linux. Refer to the Apache Software Foundation website online at https://www.apache.org/ for details on the status of this module.
LDAP Client Applications
There are graphical LDAP clients available which support creating and modifying directories, but they are not included with Red Hat Enterprise Linux. One such application is LDAP Browser/Editor — A Java-based tool available online at https://www.iit.edu/~gawojar/ldap/.
Other LDAP clients access directories as read-only, using them to reference, but not alter, organization-wide information. Some examples of such applications are Sendmail, Mozilla, Gnome Meeting, and Evolution.
OpenLDAP configuration files are installed into the /etc/openldap/ directory. The following is a brief list highlighting the most important directories and files:
/etc/openldap/ldap.conf — This is the configuration file for all client applications which use the OpenLDAP libraries such as ldapsearch, ldapadd, Sendmail, Evolution, and Gnome Meeting.
/etc/openldap/slapd.conf — This is the configuration file for the slapd daemon. Refer to Section 24.6.1, “Editing /etc/openldap/slapd.conf” for more information.
/etc/openldap/schema/ directory — This subdirectory contains the schema used by the slapd daemon.
The /etc/openldap/schema/ directory holds LDAP definitions, previously located in the slapd.at.conf and slapd.oc.conf files. The /etc/openldap/schema/redhat/ directory holds customized schemas distributed by Red Hat for Red Hat Enterprise Linux.
All attribute syntax definitions and objectclass definitions are now located in the different schema files. The various schema files are referenced in /etc/openldap/slapd.conf using include lines, as shown in this example:
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/rfc822-MailMember.schema include /etc/openldap/schema/redhat/autofs.schema
Do not modify schema items defined in the schema files installed by OpenLDAP.
It is possible to extend the schema used by OpenLDAP to support additional attribute types and object classes using the default schema files as a guide. To do this, create a local.schema file in the /etc/openldap/schema/ directory. Reference this new schema within slapd.conf by adding the following line below the default include schema lines:
Next, define new attribute types and object classes within the local.schema file. Many organizations use existing attribute types from the schema files installed by default and add new object classes to the local.schema file.