Handling User Accounts in Samba

In this third part to a four-part series on handling authentication and authorization in Samba, you will learn about username maps, account utilities, and more. It is excerpted from chapter five of Using Samba, Third Edition, written by Gerald Carter, Jay Ts and Robert Eckstein (O’Reilly, 2007; ISBN: 0596007698). Copyright © 2007 O’Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O’Reilly Media.

 passdb backend = ldapsam

The third officially supported passdb module is the ldapsam backend. A complete discussion of LDAP is beyond the scope of this book. If you are interested in LDAP and directory services, a recommended resource is LDAP System Administration, by Gerald Carter (O’Reilly). The remainder of this section assumes a basic level of comfort with LDAP directories and the OpenLDAP software in particular. If you are using a directory server from a different vendor, the examples should prove easy to adapt.

When you consider the ldapsam backend, the first thing to do is to become familiar with the schema. There are two auxiliary classes and one structural object class that will be encountered in relation to users and groups:


This structural object class is used to store information that is intended to be shared between Samba domain controllers in the same domain. We examine this more in Chapter 9.


This auxiliary object class represents normal user and computer accounts and is commonly used to extend a user’s posixAccount entry in the directory. If a user (or computer) does not have a preexisting entry in the directory service, Samba attempts to use the account object as the structural class to instantiate a user. We haven’t discussed how machine and domain trust accounts are implemented yet, but we return to this subject in Chapter 9.


This auxiliary object class contains the attributes necessary for Samba’s group mapping functionality and is designed to use the posixGroup class as its structural basis.* Group mapping is covered later in this chapter.

All the necessary attributes and object classes are defined in an OpenLDAP 2.x compatible schema file named samba.schema located in the examples/LDAP directory of the Samba source distribution. In this same location are schema files for other directory services as well, although these may not be up to date. Make sure that you include or import the appropriate schema file into your LDAP server’s configuration. Be aware that Samba’s OpenLDAP schema file requires you include the nis.schema, inetorgperson.schema, and cosine.schema files first.

Remember that the LanMan ( sambaLMPassword ) and NT ( sambaNTPassword ) password hashes stored in the sambaSamAccount object are plain-text equivalents and should never be made readable to users. Access control rules should restrict these attributes to administrative users only, such as Samba’s ldap admin dn distinguished name (discussed a few paragraphs ahead). The following ACLs in OpenLDAP’s slapd.conf file protect the passwords from normal users but allow them to be read and modified by Samba:

  ## protect the samba password hashes
  access to attr=sambaNTPassword,sambaLMPasswor d
    by cn=smbadmin,ou=people,dc=example,dc=com write
    by * none

For performance reasons, the directory service should support fast equality searches on the uid , cn , sambaSID , gidNumber , uidNumber , and displayName attributes. Newer Samba releases (beginning with 3.0.23) also use a substring matching rule on the sambaSID attribute. To effect this performance enhancement, add the following indexes (or their equivalents) to the server’s database section, if any are missing.

  ## Samba’s index settings for OpenLDAP’s slapd.conf
index   uid,cn,displayName,memberUid   eq
  index   uidNumber,gidNumber            eq
  index   sambaSID                       eq,

Finally, it may be necessary to restart your directory server and/or rerun indexing tools to get it to recognize the changes.

Begin configuring smb.conf by setting up the connection parameters, starting with the LDAP server’s URI in the passdb backend value.

      passdb backend = ldapsam:ldap://localhost/

By default, all LDAP requests are sent to the directory in an unencrypted form. Unless the master LDAP server and Samba are running on the same machine, it is highly recommended that you take steps to secure the LDAP traffic from eavesdrop ping. Even when an LDAP replica is running locally on the Samba host, any referrals going back to the master LDAP server must still be encrypted.

Use the ldaps:// URI in the passdb backend option if you wish to connect using LDAP over SSL. However, using StartTLS is the recommended method for configuring data privacy when communicating with an LDAP directory. In this case, the ldap:// URI suffices. To enable StartTLS support, add the following setting to the [global] section:

  ldap ssl = start_tls

It is possible to include multiple LDAP URIs in a single-quoted string for purposes of fault tolerance or load balancing. If there are two servers, ldap1 and ldap2, which are replicas of the directory, we can configure Samba to use one in case the other is unavailable. The list of servers is passed on to the underlying LDAP client libraries, which handle the actual network connection details and any failover behavior. The ldap ssl parameter is included here to reiterate the need to secure all communication with the directory service; its value, however, specifies the use of StartTLS instead of SSL:

  passdb backend = ldapsam:"ldap://ldap1/ ldap://ldap2/ "
  ldap_ssl = start_tls

Samba treats LDAP as another storage facility for users and groups. Thus all of the user’s attributes are retrieved from the directory when a SMB/CIFS connection request must be authenticated. When configuring the directory service access con trol settings, we restricted the password hashes to be readable only by Samba itself when using its ldap admin dn distinguished name to bind to the server:

  ldap admin dn = cn=smbadmin,ou=people,dc=example,dc=com

The password associated with this privileged DN is stored in clear text separately in secrets.tdb. The smbpasswd command can store these credentials interactively ( -W option) or on a command line ( -w option). Here we have chosen to enter it interactively so that the password will not be displayed in the output of ps:

  root# smbpasswd -W
Setting stored password for "cn=smbadmin,ou=people,dc=example,dc=com"
in secrets.tdb
  New SMB password: <enter password>
  Retype new SMB password:
<re-enter password>

The final bit of information that Samba requires for ldapsam is the set of base suffixes used to query and store users and groups. The top-level suffix is specified by the ldap suffix option. This DN should be the parent of the other smb.conf search suffixes, which are specified by the following options:

ldap user suffix
   The search base for locating and storing user

ldap machine suffix
   The search base for locating and storing computer
   and domain trust accounts

ldap group suffix
   The search base for locating and storing group
   mapping entries

ldap idmap suffix
   The search base for mapping winbindd’s SIDs to the
   Samba host’s uid/gid entries; additional information
   on winbindd is provided in Chapter 10

The ldap suffix should be specified first in smb.conf and should be a full DN. The remaining search suffixes should be defined relative to the ldap suffix value. In order to support a directory name space such as the directory information tree (DIT) shown in Figure 5-2, we would add the following parameters to Samba’s configuration:

ldap suffix         = dc=example,dc=com
ldap user suffix    = ou=people
ldap machine suffix = ou=people
ldap group suffix   = ou=group
ldap idmap suffix   = ou=idmap

It is possible to define different machine and user suffixes. If you do so, the server’s LDAP NSS module must search both bases when querying for a posixAccount . As one of the Samba developers has said, “Machines are people too.” The nss_ldap library from PADL software (http://www.padl.com) supports this by enabling the

Figure 5-2.  Samba’s DIT

library’s RFC2307bis extensions (pass the –enable-rfc2307bis option to the nss_ldap configure script when compiling) and then defining multiple nss_base_passwd directives in its configuration file (usually /etc/ldap.conf). The complete details of PADL’s nss_ldap configuration is beyond the scope of this discussion. For more information, please refer to PADL’s web site and the documentation included with its software.

To finish off the section, Table 5-10 lists the LDAP-related parameters supported in smb.conf. Samba and LDAP integration are revisited in Chapters 9 and 10.

Table 5-10. LDAP-related parameters

Parameter Value Description Default Scope
ldap admin dn DN The user DN entry with administrative access to read and modify all Samba attributes and entries in the directory. "" Global
ldap replication sleep integer (in milliseconds) The period to delay queries to an LDAP replica after updating the master directory server. 1000 Global
ldap ssl off Transport layer encryption settings when not using LDAPS in the ldapsam server URI. off Global
ldap suffix DN The parent search suffix that establishes the base suffix for LDAP queries. "" Global
ldap group suffix DN The suffix relative to the ldap suffix that stores group mapping information. "" Global
ldap idmap suffix DN The suffix relative to the ldap suffix that stores winbindd’s identity mapping information. "" Global
ldap machine DN The suffix relative to the ldap suffix that stores computer and domain trust account suffix information "" Global
ldap user suffix DN The suffix relative to the ldap suffix that stores user account information. "" Global
ldap timeout integer (in seconds) The maximum time in seconds to wait for a response to an LDAP query. 15 Global

{mospagebreak title=Username Maps}

A username map is a mechanism for translating a login name sent by a client in the session setup request to a local Unix username. It’s independent of any passdb backend. The most common use is to handle usernames that differ between Windows and Unix. Usernames on Windows systems can violate the limits placed by Unix systems on length and characters used, so sometimes the user account must be stored on the Unix or Linux system, and recognized by Samba as a different name from the one sent by a Windows system to authenticate the user.

This mapping feature comes in two forms: username map uses a file lookup, whereas username map script relies upon an external command to perform the search. Both smb.conf parameters are summarized in Table 5-11.

Table 5-11. Username mapping

Parameter Value Description Default Scope
username map string Absolute path of the username map file. "" Global
username map script string Absolute path to a script or tool that accepts the requested username as a parameter and prints the mapped username (if any) to standard output. This script is mutually exclusive with, and takes precedence over, the username map parameter. "" Global

The username map option requires the absolute path to a map file on the server. Frequently this file is named smbusers and is stored in the same location as smb.conf. No default mapping file is distributed with Samba, although some vendors may choose to do so. The username map option must be explicitly set as shown here:

  [global ]
      username map = /usr/local/samba/lib/smbusers

This map file contains entries in the form of:

  map_to = map_from

The map_to  value is a single Unix username. The map_from  value may be a list of val ues that include:

  1. A single username. Login names containing whitespace must be surrounded by double quotes (e.g., “Lee Zard”).
  2. A Unix or NIS netgroup name prefaced by a & , @ , or + . This same syntax is reused for other smb.conf parameters and so is discussed in the final section of this chapter, where it is most applicable.
  3. A single wildcard character, *, that matches everything.

Processing of the username map file continues until either the complete map has been parsed or until an entry prefixed by an exclamation point ( ! ) matches successfully. Any lines beginning with a hash ( # ) or semicolon ( ; ) character are ignored as comments. If no match is found at all, the original username is unchanged.

As an example, to map a Windows user of Lee.Zard to a Unix login name of lizard, we could use a single entry such as:

  !lizard = Lee.Zard

The righthand values are compared in a case-insensitive fashion, so this example would succeed regardless of whether the user logs on with Lee.Zard or LEE.ZARD. The beginning ! prevents smbd from continuing to look for additional matches for lizard after this entry is parsed.

The username map script allows an administrator to define an external command that will be invoked, rather than reading a map file directly. It provides the flexibility to store the maps in directory services such as LDAP. The mapping command must accept a username as its sole parameter (provided by smbd) and must return a single login name to standard output if any mapping is necessary. Without getting into too many details, the following example uses the OpenLDAP ldapsearch tool to query a directory service based on the common name ( cn ) attribute and maps the user to the login name provided by the uid attribute.

ldapsearch -x -LLL -h ldapsrv1 -b "dc=example,dc=com"
-s sub "(&(cn=$1)(objectclass=posixAccount))" |
grep uid: | cut -d: -f 2 | sed ‘s/^s*//’

Assuming that this script is named ldapmapuser.sh, we can instruct smbd to make use of it by adding the following line to smb.conf:

  [global ]
      username map script = /usr/local/bin/ldapmapuser.sh

In this way, it is possible to integrate the username map functionality with the ldapsam passdb backend.

The point at which the mapping occurs is dependent on the value of the security parameter. In the context of our current discussion around security = user , the map is queried before the user is authenticated. To illustrate the consequence, assume that we have the following entry in a username map file:

  root = administrator

If a user attempts to connect to our standalone server with a login name of Administrator, the password supplied must match the one for root in Samba’s configured passdb backend.

When Samba is configured as a domain member server ( security = domain or security = ads ), the map is applied after a user has been authenticated by a domain controller. The means that when a user connects as DOMAINadministrator, she must provide the actual password for that account even though the account may be eventually mapped to the local superuser account. The process becomes even more complicated with the presence of winbindd. Therefore the remainder of the discussion of username maps and member servers is saved until Chapter 10.

{mospagebreak title=Account Utilities}

Samba provides a set of tools for manipulating user accounts stored in its passdb. The Samba developers have designed these tools to work in the same manner, regardless of which passdb module is used. For this reason, our discussion can focus on the tool without worrying about where or how the information is stored.

Many administrators, particularly LDAP administrators, have a tendency to manage the user attributes (e.g., password hashes or SIDs) manually. It is possible in many instances to do this. However, it is not recommended for most installations. If you understand how to manipulate these attributes directly without breaking your server, it is probably okay. But consider this the sticker that voids your warranty if removed. If you can get away with it, congratulations. Such tactics are not covered here.

The two main user management tools are smbpasswd and pdbedit. The former is the original tool for setting user passwords in an smbpasswd file. During the Samba 3.0 development cycle, it was thought that this tool would be superseded by pdbedit. However, this has not yet happened, and pdbedit is considered by some as the example of how not to build a command-line interface. In Chapter 9, we explore how to use MS-RPC tools such as the Windows NT 4.0 User Manager for Domains and MMC plug-ins to manage users and group from Windows clients. At the moment, these two command-line utilities are what we have to work with.

The smbpasswd tool has two basic categories of functions:

  • When run as root, the command can be used to manipulate Samba’s local user accounts.
  • Normal users can use the tool to perform password changes against remote Samba and Windows servers.

Local user management breaks down further into:

  1. Adding or deleting a user from Samba’s list of accounts
  2. Setting user passwords
  3. Enabling or disabling user accounts

In previous chapters, you’ve seen examples of adding a new user by passing a login name to the -a argument. It is also possible to feed the new password to the tool on standard input using the -s option, which can be very useful for shell scripts. Here is an example that adds a user named smitty and assigns a password of “cat.” The reason for the complicated syntax is to answer both prompts output by the smbpasswd command to request the password. Remember that the Unix user smitty must already exist.

  root# (echo "cat"; echo "cat" ) | smbpasswd -s -a smitty
  Added user smitty.

To later manually change this user’s password, run the smbpasswd command again, but this time without the
-a option. In this example, we enter the new password interactively rather than using the -s option again:

  root# smbpasswd smitty
  New SMB password: <enter new password>
  Retype new SMB password: 
<re-enter new password>

The password is verified by comparing both input strings. If both match, the new password is set. Otherwise you will see an error message stating, Mismatch – password unchanged. 

An account can be disabled to prevent the user from logging on. Disabling a user’s account sets the D flag in the account control flags. (Refer to Table 5-9 in the earlier section on the smbpasswd file format for an overview of these flags.) The following lines disable smitty’s account ( -d option) and then reenable it ( -e option):

  root# smbpasswd -d smitty
Disabled user smitty .
  root# smbpasswd -e smitty
  Enabled user smitty.

When the account is no longer necessary, we can delete this user from our passdb using the -x option and passing it the account name. This command has no effect on the user’s Unix account in /etc/passwd.

  root# smbpasswd -x smitty
  Deleted user smitty.

Table 5-12 summarizes the command-line options available to root when running smbpasswd.

Table 5-12. Command-line options for smbpasswd when run as root

Argument Description
-a name Add a user account.
-c smb.conf Specify an alternative configuration file.
-d name Disable a user account.
-e name Enable a user account.
-h Print the command usage.
-n name Set a null password for a user.
-x name Delete a user account.

If smbpasswd is a tool for day-to-day administrative tasks, pdbedit is more akin to a low-level database editor. Overall, its syntax can be cryptic at times, but it does pro vide three major functions not supported by the smbpasswd command:

  1. Editing of account policy settings, such as maximum password age and bad login attempts before locking an account.
  2. Editing the full set of supported user attributes, such as the login script, the user’s SID, and roaming user profile location.
  3. Converting from one passdb backend to another.

The first two features are more related to Samba domain controller functionality, and so are discussed in full detail in Chapter 9. The last is covered here, because without the translation support between passdb storage formats, tasks such as converting from an smbpasswd file to tdbsam would be time-consuming and extremely error-prone.

pdbedit’s option naming is a bit confusing at first. The import option ( -i ) reads in from one backend, whereas the export option ( -e ) writes to another. Each command-line switch accepts a passdb backend value as its argument. So to convert from smbpasswd to a tdbsam backend, you would run the following command as root:

  root# pdbedit
  Importing account for rootok
  Importing account for kong…ok
  <remaining output deleted>

It is a good idea to copy your current passdb file or database to a tem porary location, rather than working on the live version.

{mospagebreak title=Synchronizing Passwords}

The complaint with Samba in regard to user accounts is that its user passwords must be maintained separately from the from the Unix or Linux system passwords. To help alleviate the pain of managing multiple passwords for each user, Samba provides a mechanism to synchronize the user’s Unix password entry when a CIFS client requests that the LanMan and NT password hashes be changed. Of course, this solution does not help when the user changes the password by means other than the SMB/CIFS protocol, such as using the passwd command or writing to the passdb storage directly using pdbedit.

The only prerequisite of using this feature is for the root user to able to reset a user’s password without knowing the old password. The reason for this requirement is that the client encrypts the new password with the old password hash as the key. The clear text of the old password is never sent. Password hashes are one-way, so there is no way to derive the clear text of the password from the old password hash.

It is extremely difficult to make generalities about Windows clients because there are so many different versions. In fact, Windows 9x/Me clients do send the clear text of the old password, in uppercase of course, when the the net.exe command is used to change a password. But this approach is hardly useful, because it is impossible to determine the case of the new password.

The smbd daemon currently supports three mechanisms for changing a user’s Unix password:

  • Communicating with an external password program
  • Utilizing the PAM password change API
  • Requesting that the LDAP Directory service do the work on its behalf

The simplest option of the three, the ldap password sync option (sometimes called ldap passwd sync ), instructs smbd to send a ModifyPassword extended request to the directory service, which then updates the userPassword attribute on behalf of the user. This option currently works only when Samba is using the ldapsam passdb module and when the LDAP directory service is running a recent version of OpenLDAP. To enable password synchronization, with all these prerequisites in place, add ldap password sync = yes to the [global] section of smb.conf.

If you can’t make use of this optimal solution, the next option is to enable the unix password sync option and then choose which of the first two mutually exclusive password change mechanisms you wish to use. Relying on an external program is the older method. In this case, you must define a value for the passwd program parameter and then specify a passwd chat conversation string.*

The chat value is a special string generally called an “expect string” or “chat string”; it lists pairs of strings in which the first of each pair is the text that you expect the external program to output, and the second is the text that the external program expects the user to enter. With an expect string, an automated system can interact with a program that was designed for a human user. In this case, Samba is pretending to be the root user and is interacting with a password change program. The Samba expect string is case-insensitive and can contain wildcards ( * ) to eat a variable number of characters when evaluating the output from the program in the passwd program parameter. Remember that the passwd program executable is run as root, so be sure to pass the Unix user name ( %u ) as a command-line argument, or else you will be stuck just changing root’s credentials.

The following example works on most recent versions of Linux from Novell or Red Hat:

encrypt passwords = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *New*password* %nn

Deriving passwd chat values is not extremely difficult. This one was developed by examining the output from running /usr/bin/passwd from a shell prompt, as shown here:

  root# passwd lizard
Changing password for lizard.
  New Password:
  Reenter New Password:
  Password changed.

Notice that the expect string collapses the first line of output to a single * character.

The pam password change Boolean parameter replaces the invocation of an external command with a series of calls to the system’s PAM library. The passwd chat param eters plays the same role as before, providing a means by which smbd is able to interact with the PAM password change interface. This requires that the Samba PAM service has been correctly configured in either /etc/pam.conf or /etc/pam.d/samba. The following is a basic PAM password change stack that performs strengths checks on the new password, and finally hands it off to the pam_unix.so library to actually update the user’s credentials:

  password required  pam_pwcheck.so  nullo k
  password required  pam_unix2.so    nullok use_first_pass use_authtok

Next, we can update the previous example to make use of the new PAM configura tion file:

encrypt passwords = yes
unix password sync = yes
pam password change = yes
passwd chat = *New*password* %nn

If desired, password strength checking can be performed using an external utility specified by the check password script parameter. This directive should point to a tool or script that accepts the new password as its single argument and returns 0 for valid passwords and a nonzero value if the strength check fails.

Table 5-13 summarizes all of the password synchronization options we have discussed in this section.

Table 5-13. Password synchronization parameters






check password script


Defines an external script that is used to verify the strength of a new password. The script must return 0 to indicate a valid password.



ldap password sync


If enabled, smbdsends a Modify Password extended operation (currently supported only by OpenLDAP servers) to request that the user’s directory service password attribute be updated.



pam password change


Controls whether smbd uses PAM to change a user’s Unix password.



passwd program


External program to change a user’s Unix credentials.



passwd chat


An expect string that smbd uses to interact and evaluate the password change conversation.

*new*password* %nn *new*password* %nn *changed*


passwd chat debug


Samba dumps the passwd chatconversa-tion to its logfiles when this option is enabled, the DEBUG_PASSWORDmacro was enabled at compile time, and the debug level is set to 100 or greater.



passwd chat timeout


The maximum number of seconds that smbd should wait for a passwdchatto complete.



unix password sync


Defines whether Samba should attempt to synchronize a user’s Unix password upon receiving a password change request from a CIFS client.



Please check back next week for the continuation of this article.

Google+ Comments

Google+ Comments