![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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.
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 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 monty:x:504: [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 accounting:x:506:monty [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.
For the typical Samba configuration, account information is stored in one of three password databases:
- smbpasswd
- tdbsam
- ldapsam
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:
[global] 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 ~]$ |
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: Workstations: 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 Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF |
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 lengthpassword historyuser must logon to change passwordmaximum password ageminimum password agelockout durationreset count minutesbad lockout attemptdisconnect timerefuse 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.
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 directory-services.example.org 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.)
[global] idmap backend = ldap:ldap://directory-services.example.org:636 |
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
| Windows | UNIX |
|---|---|
| Monty | monty |
| bostt | tbost |
| sue.george | sue |
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 [global] 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 = sue.george |
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.
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 sue.george 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:
adm:x:4:root,adm,daemon,monty,tbost,sue users:x:100:monty,tbost,sue guests:x:507:monty,tbost,sue |
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
| Windows | UNIX | Windows relative ID (RID) | UNIX GID |
|---|---|---|---|
| Domain Admins | adm | 512 | 4 |
| Domain Users | users | 513 | 100 |
| Domain Guests | guests | 514 | 507 |
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:
- With root privileges, use the
net groupmap addcommand to specify the Windows group ntgroup='Domain Admin" to map to the UNIX group, unixgroup=adm.Perform this step for each group mapping.
- The final command in Listing 9 displays the mapping for the groups.
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:
[global] 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:
[global] 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.
Learn
-
Learn more about Samba
account information databases in Chapter 11 of the Samba 3.x manual.
-
Learn more about grup
mapping in Chapter 12 of the Samba 3.x manual.
-
Get a detailed description of the
pdbedittool in thepdbeditmanual documentation. -
Learn more about Identity
Mapping (IDMAP) for stand-alone and primary domain controller servers in Chapter 14 of the Samba manual.
-
At the LPIC Program
site, find detailed objectives, task lists, and sample questions for the three levels
of the LPI's Linux systems administration certification. In particular, look at the
LPI-302
detailed objectives and the
tasks
and sample questions.
-
Review the entire LPI
exam prep series on developerWorks to learn Linux fundamentals and prepare
for systems administrator certification based on LPI exam objectives prior to April
2009.
-
Exam
Preparation Resources for Revised LPIC Exams provides a list of other
certification training resources maintained by LPI.
-
In the developerWorks
Linux zone, find hundreds of
how-to
articles and tutorials as well as downloads, discussion forums, and a wealth
of other resources for Linux developers and administrators.
-
Follow developerWorks on
Twitter, or subscribe to a feed of
Linux
tweets on developerWorks.
-
Stay current with developerWorks
technical events and webcasts focused on a variety of IBM products and
IT industry topics.
-
Attend a free developerWorks
Live! briefing to get up to speed quickly on IBM products and tools as well
as IT industry trends.
-
Watch developerWorks
on-demand demos ranging from product installation and setup demos for beginners
to advanced functionality for experienced developers.
Discuss
-
Get involved in the My developerWorks
community. Connect with other developerWorks users while exploring the
developer-driven blogs, forums, groups, and wikis.
Tracy Bost is a seasoned software developer and systems engineer. He is also a lecturer and trainer for the Linux operating system. Tracy has been certified as both a Red Hat Certified Engineer (RHCE) and a Microsoft Certified Systems Engineer (MCSE), along with being an active member of the Linux Foundation. He has worked in several industries, including mortgage, real estate, and the nonprofit sector.
