Learn Linux, 302 (Mixed environments)

Authentication and authorization

Authentication mechanisms and configuring access control

Content series:

This content is part # of # in the series: Learn Linux, 302 (Mixed environments)

Stay tuned for additional content in this series.

This content is part of the series:Learn Linux, 302 (Mixed environments)

Stay tuned for additional content in this series.

In this article, learn about these concepts:

  • Local password database setup
  • The smbpasswd file format
  • Synchronization of passwords between Samba and other systems
  • Alternative back-end storage for passwords
  • Integration of Samba with Lightweight Directory Access Protocol (LDAP)
  • Access control lists (ACLs)

This article helps you prepare for Objective 313.2 in Topic 313 of the Linux Professional Institute's (LPI) Mixed Environment Specialty exam (302). The objective has a weight of 8.


To get the most from the articles in this series, you should have an advanced knowledge of Linux and a working Linux system on which you can practice the commands covered in this article. In addition, you should have access to a Windows environment that you can use to test authentication and authorization mechanisms.

Samba authentication mechanisms

Samba offers several ways to store passwords and account information using password back ends. Some of these methods rely on local disk storage; some rely on network-based methods. In addition, Samba provides mechanisms for a Linux server to use the Samba authentication system for logins.

Because Samba has been around for close to two decades, it carries with it some technical baggage. Older authentication systems are still supported, but newer technology has replaced the old. When you read documentation about Samba, you will find references to these older systems. This confusion is further compounded by command-line tools with names similar to a particular technology.

Despite the name password back end, account data and other attributes are stored in the back end in addition to passwords. The data itself might also be stored in an LDAP server, and the job of the Samba password back end is to serve as an intermediary between Samba and LDAP.

To make things even more interesting, Microsoft devices expect password hashes to use a format that is different from the UNIX password format. The passwords are hashed, which means that they're encrypted in a one-way fashion; therefore, it is impossible to go between UNIX and Samba password formats. As a result, it's not possible to authenticate Samba clients out of the UNIX password database.

Local password database options

Local password database refers to those password back ends that store the information on the server rather than authenticating over the network. These are not the highest-performance options, but they are easy to use.

You may see references in literature to the plain-text back end. Many years ago, Windows clients would pass their credentials to the server in an unencrypted format. It was then possible to hash the password in the UNIX style and check the results against the local password database. Windows clients no longer do this without a few registry changes, and no one wants unencrypted passwords on their network if they can avoid it. So, you might see mentions of the plain-text password database, but you won't run into it in production.

Most older systems will use the smbpasswd password back end. This back end holds the account data in a simple flat file. The data in this file consists of the account name, the password hashes, and some basic account information. This basic account information is simple and does not offer storage of the advanced attributes that you find in the Microsoft administration tools.

The currently favored local storage back end is tdbsam. Recall Trivial Database files (TDB) from Topic 310.3 (see Related topics for a link): TDB files offer a quick and durable way to access key-value information. The tdbsam back end stores information in a format much like the Microsoft Windows NT Security Account Manager (SAM) does, which means almost anything that can be stored in the SAM can be represented in the Samba server. Therefore, tdbsam provides a high level of compatibility with Microsoft systems.

The downside to tdbsam is that it is a binary format, so you can't easily look inside it. The article "Learn Linux, 302 (Mixed environments): Trivial Database files" (developerWorks, March 2011) shows how to get some of the key-value pairs from inside the file, but it is up to you to reconstruct it into something meaningful. The file is called passdb.tdb.

Using the smbpasswd database

For a new installation, you wouldn't want to choose the smbpasswd database back end. It is possible that you'll run into this back end in the field, however, so an understanding of it is important.

You configure the password database back end with the passdb backend parameter. The code below shows the smbpasswd database being chosen:

  passdb backend=smbpasswd:/etc/samba/smbpasswd

Here you see the passdb backend global parameter in use, with the value of smbpasswd and the path to the file, separated by a colon (:). The colon and the path are optional but preferred. If you leave them out, Samba places the file in the directory of its choosing. Samba creates this file when you restart, but the file will be empty.

You use the smbpasswd command to add a user. Listing 1 shows a user being added and the effect on the smbpasswd file.

Listing 1. Adding a user to an smbpasswd file
# smbpasswd -a sean
New SMB password:
Retype new SMB password:
Added user sean.
# cat smbpasswd
sean:1001:01FC5A6BE7BC6929AAD3B435B51404EE: \
0CB6948805F797BF2A82807973B89537:[U          ]:LCT-4DCDE4D8:

Listing 1 starts off by adding a user called sean through the use of the -a flag. This user must exist in the local UNIX database or the command will fail. The smbpasswd file then has a single line (which has been broken up in Listing 1 for clarity), with the fields separated by a colon. The fields, in order, are:

  • User name.
  • UNIX user ID.
  • Legacy Lanman hash. (Because of a lack of security on this hash, it's effectively a plain-text password.)
  • The secure Windows NT hash. (This is the hash needed to authenticate modern clients.)
  • Account flags. (The only flag here is U, which signifies a user account. Consult the smbpasswd(5) man page for more flags.)
  • The Last Changed Time (LCT) of the account. (The hexadecimal value is an encoded version of the UNIX timestamp.)

Users can change their password by typing smbpasswd, and the root user can change another user's password by specifying the user name. The -a flag is needed only to add the account.

Plain-text files have their limitations, both in terms of how fast they can be consulted and what metadata can be stored about the account. Therefore, the tdbsam database was created.

Using the tdbsam database

The tdbsam database was designed as a replacement for the smbpasswd database. More data can be stored about accounts, and because of the use of trivial databases, it is much faster.

Guidelines on the limitations of the tdbsam database are not concrete. The official documentation suggests upgrading to an LDAP database at 250 users, but other sources list anecdotal evidence of support for thousands of clients. The number of simultaneous requests seems to be a large factor, which is influenced by the number of clients, the workload, and the latency between the clients and the server. As with most applications, it is best to monitor key factors such as latency, CPU, and disk I/O to predict the breaking point of your network.

Configuring the tdbsam back end is just as easy as it was for smbpasswd. Add passdb backend=tdbsam—optionally with a file name—to your global section, and restart Samba. The default name of the TDB file with the authentication information is passdb.tdb.

The smbpasswd tool is also able to manipulate users in the tdbsam database. Listing 2 shows the tdbsam database before and after a user is created with smbpasswd.

Listing 2. Creating a user with smbpasswd and viewing the tdbsam
# tdbdump passdb.tdb
key(13) = "INFO/version\00"
data(4) = "\03\00\00\00"
# smbpasswd -a sean
New SMB password:
Retype new SMB password:
Added user sean.
# tdbdump passdb.tdb
key(13) = "RID_00000bba\00"
data(5) = "sean\00"
key(10) = "USER_sean\00"
data(205) = "\00\00\00\00....EC\04\00\00"
key(13) = "INFO/version\00"
data(4) = "\03\00\00\00"

The initial contents of passdb.tdb are a single key that contains a version string. A user is then added exactly in the same way as earlier. The smbpasswd utility is smart enough to read smb.conf to understand how it is supposed to be adding a user. The password database now contains two additional keys: The first maps a Microsoft relative ID (RID) to a user name, and the other contains information about the user. The data is mostly binary, so decoding it would require looking at the layout of the data structure in the Samba source code.

LDAP authentication

The TDB file format offers relatively good performance and is suitable for most small environments. To scale beyond the TDB files, you must authenticate against an LDAP server. LDAP is naturally suited for authentication because of its tree-like structure. Microsoft's Active Directory® Domain Services is built around LDAP, too.

Setting up an LDAP server

The first step to integrating Samba and LDAP is to configure the LDAP server. A detailed explanation is beyond the scope of this article, but the study material for the 301 exam covers the topic in depth (see Related topics). You may want to review this material, as an understanding of LDAP is required for this integration.

OpenLDAP is the most common LDAP server you will find on Linux servers. Its configuration file is slapd.conf. Listing 3 offers a configuration file that's ready for integration with Samba.

Listing 3. slapd.conf
# Include the core schema files, and the perquisites for samba.schema
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

database bdb
# Configure the tree and the admin user
pidfile /var/run/openldap/
suffix "dc=ertw, dc=com"
rootdn "cn=admin, dc=ertw, dc=com"
rootpw linux
directory /var/lib/ldap

# Indexes
index objectclass             eq
index cn                      pres,sub,eq
index sn                      pres,sub,eq
# For storing Unix accounts in LDAP
index uidNumber               eq
index gidNumber               eq
index memberUid               eq
# Samba specific
index uid                     pres,sub,eq
index displayName             pres,sub,eq
index sambaSID              eq
index sambaPrimaryGroupSID  eq
index sambaDomainName       eq

index default               sub

Listing 3 uses the dc=ertw,dc=com prefix for all the objects. The first section loads all the schema elements needed for Samba integration. core.schema is required for basic operation of OpenLDAP, and samba.schema brings in the Samba objectClasses. The other schemas are prerequisites for samba.schema and must be included first, because the files are processed sequentially.

The next section, beginning with database bdb, indicates that the Berkeley database will be used and gives some information about the tree, including an administrative user and a directory. The rest of the file sets up indices to make searching the tree easier; the indices come from the default configuration of OpenLDAP and the Samba documentation.

You must now populate your LDAP tree with the various containers to store users, computers, and groups. You must also associate the security identifier (SID) of your server with some of the records. This is a complex matter; fortunately, the smbldap-tools project has made it simple. Your distribution will probably come with a package for these tools; otherwise, download and install them manually (see Related topics for a link).

After you have installed the smbldap-tools utilities, go through the configuration files and fill in the requested information, such as the name of your domain or workgroup and the administrative information to connect to your LDAP server. Then, run the smbldap-populate command to build your tree. The output is shown in Listing 4.

Listing 4. Populating the LDAP tree
# smbldap-populate
Populating LDAP directory for domain BOB (S-1-5-21-2287037134-1443008385-640796334)
(using builtin directory structure)

entry dc=ertw,dc=com already exist.
adding new entry: ou=People,dc=ertw,dc=com
adding new entry: ou=Groups,dc=ertw,dc=com
adding new entry: ou=Computers,dc=ertw,dc=com
adding new entry: ou=Idmap,dc=ertw,dc=com
adding new entry: uid=root,ou=People,dc=ertw,dc=com
adding new entry: cn=Replicators,ou=Groups,dc=ertw,dc=com
adding new entry: sambaDomainName=BOB,dc=ertw,dc=com

Please provide a password for the domain root:
Changing UNIX and samba passwords for root
New password:
Retype new password:

Listing 4 shows that the smbldap-populate command has determined the SID and domain of the local machine and is building the directory structure in LDAP. Finally, the tool asks for your root password and synchronizes it in the LDAP tree.

Connecting Samba to LDAP

Configuring Samba to use LDAP involves telling the server how to bind to your LDAP tree. Listing 5 shows a minimal Samba configuration for LDAP authentication.

Listing 5. A minimal configuration to authenticate Samba to LDAP
  passdb backend = ldapsam:ldap://
  ldap suffix = dc=ertw,dc=com
  ldap user suffix = ou=People
  ldap group suffix = ou=Groups
  ldap admin dn = uid=samba_service,ou=People,dc=ertw,dc=com

Listing 5 operates in the global scope and points the local server to an LDAP server located at The three suffixes defined first tell Samba the base name of the tree and the name of the branches for users and groups, respectively. Finally, the distinguished name (DN) of an administrative user is configured. This user will be used to connect to the tree to authenticate other users. The LDAP Data Interchange Format (LDIF) information for this user is shown in Listing 6.

Listing 6. LDIF for the service account
dn: uid=samba_service,ou=People,dc=ertw,dc=com
uid: samba_service
objectclass: person
objectclass: uidobject
description: Service account to allow Samba to authenticate
cn: samba_service
sn: samba_service
userPassword: {SSHA}tQNdW/bNxQGz2iGoLz5zFL5wJ8px43v5

You must set the password for the administrative DN with the smbpasswd -w command, followed by the password. The userPassword hash shown in Listing 6 is the same password but was generated with the slappasswd command. Now, restart Samba.

Managing users

Typically, you must take care to manage the mappings between UNIX user IDs and Microsoft SIDs, keeping in mind the domain SID. This is an error-prone procedure, so the smbldap-useradd command will help. Run smbldap-useradd -a sean to add a user called sean. The -a parameter tells the program to add the Samba objectClasses to the LDAP object so that the user can log in to a Microsoft domain. Finally, give the user a password with the smbldap-passwd command followed by the user name.

At this point, you should be able to connect to your Samba server and use the credentials you just supplied in the LDAP tree. Many other tools in the smbldap-tools package will help manage your users and plan a larger migration.

UNIX authentication to Samba

Single sign-on, or password synchronization between Linux and Microsoft, is difficult to achieve, because the two operating systems store their passwords differently. The smbldap-tools package gets around this issue by working on both systems at the same time. Another alternative is to turn control of passwords over to the Microsoft network.

Linux supports a concept called pluggable authentication modules (PAM). PAM lets the administrator configure how services are authenticated and change the authentication process by manipulating configuration files without the application's knowledge. An application calls the PAM libraries to authenticate a user. PAM consults the configuration file for the instructions to authenticate a user to that particular service. The success or failure of the authentication is returned to the application.

Over time, many authentication modules have been written to allow authentication to other services, from local password files to LDAP, Kerberos, and even a Microsoft network. The module that provides this service is called pam_smb.

Configuring pam_smb

Your distribution should come with the latest version of pam_smb; if not, you can download the source code from the website (see Related topics for the link). You configure the module in /etc/pam_smb.conf. The file format is simple: just the name of the domain followed by one or two servers that can provide authentication. Here's a sample configuration:


This sample authenticates users in the MYGROUP domain or workgroup against the ALICE and BOB servers. If you had only one server to handle the authentication, your configuration file would have only the two lines for the domain and the single authentication server.

Next, you must insert pam_smb into the authentication stack. You will find several configuration files inside /etc/pam.d that refer to the particular authentication order for an individual service. Most of these files will look similar, as they often include a common file rather than duplicating configuration across many different files. Look for the file that is included with the include keyword. For example, on Fedora, this file is either password-auth or system-auth. Listing 7 shows the authentication section of the password-auth file.

Listing 7. The authentication section of password-auth
auth        required
# Use samba authentication
auth        sufficient debug
auth        sufficient nullok try_first_pass
auth        requisite uid >= 500 quiet
auth        required

Each line in Listing 7 is processed in order. The first line calls pam_env, which sets environment variables. The second line lets pam_smb try an authentication request with extra debugging. If the authentication succeeds, the check is deemed sufficient and the user is logged in. If it fails, control passes to pam_unix, which checks against the UNIX password file.

When playing with PAM, it is wise to keep a root account logged in and a known working copy of the files close. If you lock yourself out of the system, you can quickly gain access by copying over the incorrect files.

Name services

Linux has a file called /etc/nsswitch.conf that controls how the system libraries map between user and group IDs and the names they represent. This file configures the Name Service Switch (NSS) system. Most systems point to the local files, such as /etc/passwd and /etc/group, or an LDAP or Network Information Service (NIS) server. It is also possible to use a service called Winbind to have the system libraries request the mappings from the Microsoft network.

The next article in this series deals with this topic in depth. For now, it is enough to understand that users are authenticated by PAM, but user and group names are authenticated from the NSS system.

Access control lists

Microsoft servers support a fairly robust set of permissions, allowing the administrator to configure access to files and directories with a great deal of precision. Even though some UNIX systems come with file system ACLs, support is not widespread. As such, Linux systems are often limited to the traditional Read/Write/Execute bits against Everyone/Group/User access. Samba must present the ACL interface to the Microsoft clients and map this interface in to UNIX file permissions, optionally storing some information in a TDB file.

Several parameters govern how file permissions are mapped between UNIX and Windows NT permissions. Two important parameters are force security mode and security mask. These parameters work together to set and remove file permission bits, respectively.

Reviewing file permissions

UNIX file permission modes are octal numbers: Execute is 1, Write is 2, and Read is 4. These numbers correspond to the three bits required to make up an octal digit. The first of the three octal digits is the owner permission, followed by the group, and then global (Everyone) permissions. A file that is mode 750 is Read/Write/Execute to the owner, readable and executable to the group, and offers no access to everyone else.

You can perform binary operations on the octal values to set and clear permissions. An OR sets the associated bits, while AND clears a bit. 1 OR 4 is 5, because you start with the 1, and then set the 4 bit. Similarly, 5 OR 4 is still 5, because the 5 is a combination of the 1 and 4 bits, and setting a bit that's already set has no effect.

The AND is the opposite of the OR. For a bit position to be carried through to the final result, the bit must be set on both sides of the AND. 1 AND 1 is 1, because both the 1 bits are set. 5 AND 1 is 1, because the 1 bit is set on both sides, but the 4 bit is only set on the left side. Through careful use of AND and OR, you can make sure that bits are always set or cleared.

Applying bit manipulation to Samba

The force security mode forces bits to be set on a file when it is created or when the client tries to change permissions. By default, it is 000, which means that no bits are forced. If you were to set force security mode to 700, you would always be forcing the user bits to Read/Write/Execute, ensuring that the user can always read his or her file, even if the user tries to remove the permissions.

Similarly, security mask performs an AND and clears bits. By default, this mode is 777, which does not clear anything. 775 would clear the Write bit from the Everyone position of the file, which would prevent users from creating files to which everyone can write.

You can apply both security mask and force security mode globally or at the share level. They are most helpful on public and group folders, where you want to ensure that files have the correct group or global permissions without the user's intervention.

Downloadable resources

Related topics

ArticleTitle=Learn Linux, 302 (Mixed environments): Authentication and authorization