Learn Linux, 302 (Mixed environments)

Managing user accounts and groups

Planning user and group account management

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:

  • UNIX accounts
  • Managing Samba accounts
  • Mapping accounts
  • Forcing account permissions to files and directories

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


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 particular, this article assumes that you have a working knowledge of Linux command-line functions and at least a general understanding of the purpose of Samba, as covered in "Learn Linux, 302 (Mixed environments): Concepts." To perform the actions described in this article, you must have the Samba software installed. In addition, you should have network access to a Windows client.

Understanding UNIX user and group accounts

Your Samba server probably doesn't exist in a silo. Users need to access files and directories, but before they can do so, they need to authenticate. Users can connect from Linux workstations or a Windows desktop. Either way, they need accounts that the Samba server recognizes.

Once users are authenticated, they need appropriate permissions to files, directories, and printing services. Groups are a feature of Samba that can help you better manage these permissions.

The sam back-end database is your mediator from the local UNIX accounts to the remote user accounts. There are several methods for allowing your users to authenticate to the Samba server, but before delving into Samba accounts, you should have a solid understanding of the basics of UNIX user and group account management.

User accounts

When you create a local user account on a Linux computer with a tool such as useradd, the account information is written to the /etc/passwd file. This file stores information such as the user's user name, home directory, default shell, and any comments associated with the account. These accounts are commonly referred to as UNIX local accounts. This article uses the terms UNIX account and local account interchangeably.

Listing 1 creates a local account with the user name monty, provides a description of Monty Python in the comment section (-c), specifies a home directory (-m), and gives the user a default shell of /bin/bash (-s).

Listing 1. Creating a local account
[tbost@samba ~]$ sudo useradd -c'Monty Python' -m -s /bin/bash monty
[tbost@samba ~]$ less /etc/passwd | grep monty
monty:x:504:504:Monty Python:/home/monty:/bin/bash
[tbost@samba ~]$

Each line in /etc/passwd represents a user account record. Each record has seven fields separated with a delimiter: a colon (:). The user name in the first field, the user ID (UID) in the third field, and the group ID (GID) in the fourth field are of particular concern when you manage Samba accounts.

Group accounts

Group accounts perform a vital role in easing the burden of management for any multi-user computer. If you are managing a Samba server, allowing destined groups access to specific directories, files, and printing services is part of a typical configuration.

As in user accounts, if you are working with a local Samba account configuration, you need to create UNIX group accounts on the local Samba server in most Samba configurations. You can locate UNIX group account information in the /etc/group file. Some Linux distributions create a local private group for each new user. Such is the case here, with the addition of user monty:

[tbost@samba ~]$ less /etc/group | grep monty
[tbost@samba ~]$

This code displays the private group account created for user monty. If you are working in a mixed environment with Windows computers, keep in mind that Windows doesn't allow a user account and group account to have identical names.

Much like user accounts, group accounts should exist on the local UNIX server before Samba can use them. Create a group by using a utility such as groupadd (see Listing 2), or edit the /etc/group file directly with an editor such as vim.

Listing 2. Creating a group account and adding a user to it
[tbost@samba ~]$ sudo groupadd accounting
[tbost@samba ~]$ sudo usermod -G accounting monty
[tbost@samba ~]$ less /etc/group | grep accounting
[tbost@samba ~]$

Listing 2 uses the /sbin/groupadd and /sbin/usermod tools to create the group and add a user to it. If you have multiple users to add to a group, you can create a script to perform the task or add the users to the /etc/group file directly. Members of the group should be in the last delimited field and separated by a comma (,). If you create groups manually, keep in mind that each group should have a unique GID.

Managing Samba accounts

For the typical Samba configuration, account information is stored in one of three password databases:

  • smbpasswd
  • tdbsam
  • ldapsam

Using smbpasswd and tdbsam

The smbpasswd database is the default back-end database used by Samba until version 3.4. In Samba 3.4, smbpasswd is being deprecated and tdbsam is now the default back end as well as the recommended back-end database for an environment with less than 250 users.

The tdbsam database is considered more scalable than smbpasswd. If you are using a version of Samba that employs smbpassd by default, you can change the back-end database in the smb.conf file by specifying the parameter passdb = tdbsam in the global section.

But smbpasswd is not just a database: It's a tool included with the Samba suite that can provide a way to manage Samba accounts in a simple Samba configuration. To create a Samba account, you need root privileges. The account should exist on the local Linux server before you attempt to create the samba account. Listing 3 shows the code for creating a Samba user account with smbpasswd.

Listing 3. Creating a Samba user account using smbpasswd
[tbost@samba ~]$ sudo smbpasswd -a monty
New SMB password:
Retype new SMB password:
Added user monty.

Users do have access to smbpasswd to change their passwords, as shown in Listing 4.

Listing 4. Local user changing the password with smbpasswd
[monty@samba ~]$ smbpasswd
Old SMB password:
New SMB password:
Retype new SMB password:
Password changed for user monty
[monty@samba ~]$

Alternatively, you can configure Samba for password synchronization so that when a user changes the local account password, the Samba password is updated, as well:

unix password sync = yes

If a user doesn't need access to the Samba server for an extended period of time, you can temporarily disable the account, and then enable it at a later date. If a user no longer needs access, you can delete the account. Listing 5 shows the commands.

Listing 5. Disabling, enabling, and deleting a Samba account with smbpasswd
[tbost@samba ~]$ sudo smbpasswd -d monty
Disabled user monty.
[tbost@samba ~]$ sudo smbpasswd -e monty
Enabled user monty.
[tbost@samba ~]$ sudo smbpasswd -x monty
Deleted user monty.
[tbost@samba ~]$

Using pdbedit

A feature-rich tool included with the Samba suite is pdbedit. This tool can work with accounts from any of three back-end databases. In addition to creating, modifying, and removing users, you can use pdbedit to:

  • List user accounts
  • Specify home directories
  • Import user accounts
  • Set account policies

You can use pdbedit and sambapasswd interchangeably on the tdbsam database (see Listing 6). Any commands you perform with pdbedit must be with root privileges, however.

Listing 6. Interacting with the back-end database using smbpasswd and pdbedit
[tbost@samba ~]$ sudo smbpasswd -a monty
New SMB password:
Retype new SMB password:
Added user monty.
[tbost@samba ~]$ sudo pdbedit -L
monty:504:Monty Python
[tbost@samba ~]# sudo pdbedit -L --verbose 
Unix username:        monty
NT username:          
Account Flags:        [U          ]
User SID:             S-1-5-21-2247757331-3676616310-3820305120-1001
Primary Group SID:    S-1-5-21-2247757331-3676616310-3820305120-513
Full Name:            Monty Python
Home Directory:       \\samba\monty
HomeDir Drive:        
Logon Script:         
Profile Path:         \\samba\monty\profile
Domain:               SAMBA
Account desc:         
Munged dial:          
Logon time:           0
Logoff time:          never
Kickoff time:         never
Password last set:    Tue, 24 May 2011 14:19:46 CDT
Password can change:  Tue, 24 May 2011 14:20:16 CDT
Password must change: Tue, 24 May 2011 14:20:16 CDT
Last bad password   : 0
Bad password count  : 0

Listing 6 demonstrates how you can create a user with smbpassd, and then list Samba users with pdbedit. For more extensive account information in pdbedit, include the --verbose switch.

You can also use pdbedit to set account policies. Account policy names you can manage are:

  • min password length
  • password history
  • user must logon to change password
  • maximum password age
  • minimum password age
  • lockout duration
  • reset count minutes
  • bad lockout attempt
  • disconnect time
  • refuse machine password change

Listing 7 changes the minimum password length to eight characters, and then changes the maximum password age to 30 days. The -P switch takes a string argument that should match exactly one of the predefined policy names, while the -c switch takes an argument of the value for the policy setting.

Listing 7. Managing accounts with pdbedit
[tbost@samba ~]$ sudo pdbedit -P 'min password length' -C 8
account policy "min password length" description: Minimal password length (default: 5)
account policy "min password length" value was: 5
account policy "min password length" value is now: 8
[tbost@samba ~]$ sudo pdbedit -P 'maximum password age' -C 30
account policy "maximum password age" value was: 4294967295
account policy "maximum password age" value is now: 30

Refer to the man pdbedit documentation, or type pdbedit -h for more details about available commands.

Using ldapsam

If you are working with an existing directory service such as Lightweight Directory Access Control (LDAP) or working in a larger environment (that is, more than 250 users), you can use the ldapsam back end. Of the three back-end databases, ldapsam is the only one that allows storage of group accounts. By storing all users and groups in the ldap back end, all your servers can have consistent UIDs and GIDs. Configuring LDAP is beyond the scope of this article, but the idmap backend parameter in smb.conf specifies the location of your LDAP server.

The parameter set below directs Samba to use the LDAP directory service at host name as its back-end storage. You should first have a working LDAP server that is configured to interact with Samba. (idmap is discussed in more detail in the following section.)

idmap backend = ldap:ldap://

Mapping accounts

If your Samba server is a stand-alone server within one domain, you'll probably just use mapping files. However, if your environment consists of users connecting to the Samba server from another domain, the idmap tool assists with mapping the UIDs and GIDs properly.

User mapping using sampasswd and TDB files

If Windows users connecting to the Samba server have the identical user names as those created on the Samba server, a mapping file shouldn't be necessary. However, if your Windows users have names that do not map exactly, you can create a mapping file to link the user names. Keep in mind that although Linux is case sensitive, Windows user name are not. So, the Windows user name TBost is not the same local account as tbost. Table 1 shows the mapping from Windows to UNIX account names.

Table 1. Windows and UNIX account names to be used for mapping

When you create the Samba accounts, use the Windows account name. You can then specify a file location in the smb.conf file that will map the accounts to the appropriate UNIX account. Listing 8 shows account mapping in UNIX.

Listing 8. Simple account mapping in UNIX
[tbost@samba ~]$ sudo vi /etc/samba/smb.conf 
username map = /etc/samba/smbusers
[tbost@samba ~]$ sudo vi /etc/samba/smbusers 
# Unix_name = SMB_name1 SMB_name2 ...
root = administrator admin
nobody = guest pcguest smbguest
monty = Monty
tbost = bostt
sue =

The code command in Listing 8 configures the username map parameter to use /etc/samba/smbusers as the mapping file. When mapping accounts, it is straightforward: You place the UNIX account name on the left side and the Samba account names on the right side, separated by the equal sign (=). When users connect, Samba maps to the appropriate account.

Mapping groups

For typical Samba server environments, group mappings are configurable using the net groupmap command from the Samba suite. Suppose Windows users accounts Monty, bostt, and are members of Domain Admins, Domain Users, and Domain Guests group accounts. If you want these users to have group account permission for the similar UNIX groups on the Samba server, add the UNIX account user names to each group:


This is only a partial listing of the complete list of groups on a Samba server. Groups adm and users were created when the Linux operating system was installed. You will need to add each user to the appropriate group (see Table 2).

Table 2. Windows and UNIX account groups to be used for mapping
WindowsUNIXWindows relative ID (RID)UNIX GID
Domain Adminsadm5124
Domain Usersusers513100
Domain Guestsguests514507

The net groupmap command can map your domain groups (see Listing 9), and net groupmap list lists the domain group mappings. Starting with Samba 3.x, new group-mapping functionality is available to create associations between a Windows group RID and a UNIX GID.

Listing 9. Mapping groups with the groupmap command
[tbost@samba ~]$sudo net groupmap add ntgroup="Domain Admins" unixgroup=adm \
rid=512 type=d
Successfully added group Domain Admins to the mapping db as a domain group
[tbost@samba ~]$ sudo net groupmap add ntgroup="Domain Users" unixgroup=users \
rid=513 type=d
Successfully added group Domain Users to the mapping db as a domain group
[tbost@samba ~]$sudo net groupmap add ntgroup="Domain Guests" unixgroup=guests \
rid=514 type=d
Successfully added group Domain Guests to the mapping db as a domain group
[tbost@samba ~]$sudo net groupmap list
Domain Users (S-1-5-21-2247757331-3676616310-3820305120-513) -> users
Domain Guests (S-1-5-21-2247757331-3676616310-3820305120-514) -> guests
Domain Admins (S-1-5-21-2247757331-3676616310-3820305120-512) -> adm

The sequence of steps to map groups in Listing 9 is:

  1. With root privileges, use the net groupmap add command to specify the Windows group ntgroup='Domain Admin" to map to the UNIX group, unixgroup=adm.

    Perform this step for each group mapping.

  2. The final command in Listing 9 displays the mapping for the groups.

Using identity mapping

For most environments, the above mappings are sufficient. However, if you manage a more complex environment, such as one with multiple Samba servers or workstations from different domains connecting to your Samba server, you should become familiar with identify mapping (IDMAP) and Winbind. IDMAP can help overcome interoperability concerns between a security ID (SID) and a local UNIX UID or GID.

If your Samba server is a member of a Windows domain, you can use Winbind to map an SID to a UID or GID. You can set the range of the idmap parameter and specify how long Winbind should cache the account information in the smb.conf file:

idmap uid = 20000-50000
idmap gid = 20000-50000
winbind cache time = 300

The parameters in the code above instruct Winbind to use the local UID range of 20000-50000 and a GID range of 20000-50000. This configuration is a relatively safe range for a Samba server that doesn't expect to have several thousand local user or group accounts. The winbind cache time = 300 parameter instructs Winbind to cache account information for 300 seconds. By default, Winbind stores mappings in the winbind_idmap.tdb file.

Using default accounts to force ownership

Instead of adding every user to a group, you may find it less cumbersome to use the force user and force group parameters. When set, these parameters instruct Samba to connect an authorized user as having the permissions for the specified user and group. This is especially beneficial when configuring a share that will be accessed by many users and common permissions are sufficient:

username map = /etc/samba/smbusers
force user = guest
force group = +employees

In the code above, the force user parameter treats all connected users as user guest when working with files. A user must still connect with a valid user account. The configuration shows will force user accounts to guest, with the group account employees.

Downloadable resources

Related topics

ArticleTitle=Learn Linux, 302 (Mixed environments): Managing user accounts and groups