2
<body bgcolor="#ffffff">
4
<img src="samba2_xs.gif" border="0" alt=" " height="100" width="76"
5
hspace="10" align="left" />
7
<h1 class="head0">Chapter 9. Users and Security</h1>
11
<p><a name="INDEX-1"/>In this chapter, we
12
cover the basic concepts of managing security in Samba so that you
13
can set up your Samba server with a security policy suited to your
16
<p>One of Samba's most complicated tasks lies in
17
reconciling the security models of Unix and Windows systems. Samba
18
must identify users by associating them with valid usernames and
19
groups, authenticate them by checking their passwords, then control
20
their access to resources by comparing their access rights to the
21
permissions on files and directories. These are complex topics on
22
their own, and it doesn't help that there are three
23
different operating system types to deal with (Unix, Windows
24
95/98/Me, and Windows NT/2000/XP) and that Samba supports multiple
25
methods of handling user authentication.</p>
29
<div class="sect1"><a name="samba2-CHP-9-SECT-1"/>
31
<h2 class="head1">Users and Groups</h2>
33
<p><a name="INDEX-2"/>Let's start
34
out as simply as possible and add support for a single user. The
35
easiest way to set up a client user is to create a Unix account (and
36
home directory) for that individual on the server and notify Samba of
37
the user's existence. You can do the latter by
38
creating a disk share that maps to the user's home
39
directory in the Samba configuration file and restricting access to
40
that user with the <tt class="literal">valid</tt><a name="INDEX-3"/>
41
<tt class="literal">users</tt> option. For example:</p>
43
<blockquote><pre class="code">[dave]
45
comment = Dave's home directory
47
valid users = dave</pre></blockquote>
49
<p>The <tt class="literal">valid</tt> <tt class="literal">users</tt> option lists
50
the users allowed to access the share. In this case, only the user
51
<tt class="literal">dave</tt> is allowed to access the share. In some
52
situations it is possible to specify that any user can access a disk
53
share by using the <tt class="literal">guest</tt> <tt class="literal">ok</tt>
54
parameter. Because we don't wish to allow guest
55
access, that option is absent here. If you allow both authenticated
56
users and guest users access to the same share, you can make some
57
files accessible to guest users by assigning world-readable
58
permissions to those files while restricting access to other files to
59
particular users or groups.</p>
61
<p>When client users access a Samba share, they have to pass two levels
62
of restriction. Unix permissions on files and directories apply as
63
usual, and configuration parameters specified in the Samba
64
configuration file apply as well. In other words, a client must first
65
pass Samba's security mechanisms (e.g.,
66
authenticating with a valid username and password, passing the check
67
for the <tt class="literal">valid</tt> <tt class="literal">users</tt> parameter
68
and the <tt class="literal">read</tt> <tt class="literal">only</tt> parameter,
69
etc.), as well as the normal Unix file and directory permissions of
70
its Unix-side user, before it can gain read/write access to a share.</p>
72
<p>Remember that you can abbreviate the user's home
73
directory by using the <tt class="literal">%H</tt><a name="INDEX-4"/> variable. In addition, you can use the
74
Unix username variable <tt class="literal">%u</tt><a name="INDEX-5"/> and/or the client username variable
75
<tt class="literal">%U</tt><a name="INDEX-6"/> in your options as well. For
78
<blockquote><pre class="code">[dave]
79
comment = %U home directory
82
path = %H</pre></blockquote>
84
<p>With a single user accessing a home directory, access permissions are
85
taken care of when the user account is created. The home directory is
86
owned by the user, and permissions on it are set appropriately.
87
However, if you're creating a shared directory for
88
group access, you need to perform a few more steps.
89
Let's take a stab at a
90
<a name="INDEX-7"/>group share for the
91
accounting department in the <em class="emphasis">smb.conf</em> file:</p>
93
<blockquote><pre class="code">[accounting]
94
comment = Accounting Department Directory
96
valid users = @account
97
path = /home/samba/accounting
99
directory mode = 0770</pre></blockquote>
101
<p>The first thing we did differently is to specify
102
<tt class="literal">@account</tt> as the valid user instead of one or more
103
individual usernames. This is shorthand for saying that the valid
104
users are represented by the Unix group <tt class="literal">account</tt>.
105
These users will need to be added to the group entry
106
<tt class="literal">account</tt> in the
107
<a name="INDEX-8"/><a name="INDEX-9"/>system group file (
108
<em class="filename">/etc/group</em><a name="INDEX-10"/>
109
or equivalent) to be recognized as part of the group. Once they are,
110
Samba will recognize those users as valid users for the share.</p>
112
<p>In addition, you need to create a shared directory that the members
113
of the group can access and point to it with the
114
<tt class="literal">path</tt> configuration option. Here are the Unix
115
commands that create the shared directory for the accounting
116
department (assuming <em class="emphasis">/home/samba</em> already
119
<blockquote><pre class="code"># <tt class="userinput"><b>mkdir /home/samba/accounting</b></tt>
120
# <tt class="userinput"><b>chgrp account /home/samba/accounting</b></tt>
121
# <tt class="userinput"><b>chmod 770 /home/samba/accounting</b></tt></pre></blockquote>
123
<p>There are two other options in this <em class="filename">smb.conf</em>
124
example, both of which we saw in the previous chapter. These options
125
are <tt class="literal">create</tt><a name="INDEX-11"/> <tt class="literal">mode</tt> and
126
<tt class="literal">directory</tt><a name="INDEX-12"/> <tt class="literal">mode</tt>. These
127
options set the maximum file and directory permissions that a new
128
file or directory can have. In this case, we have denied all world
129
access to the contents of this share. (This is reinforced by the
130
<em class="emphasis">chmod</em> command, shown earlier.)<a name="INDEX-13"/></p>
133
<div class="sect2"><a name="samba2-CHP-9-SECT-1.1"/>
135
<h3 class="head2">Handling Multiple Individual Users</h3>
137
<p><a name="INDEX-14"/>Let's return
138
to user shares for a moment. If we have several users for whom to set
139
up home directory shares, we probably want to use the special
140
<tt class="literal">[homes]</tt> share that we introduced in <a href="ch08.html">Chapter 8</a>. With the
141
<tt class="literal">[homes]</tt><a name="INDEX-15"/> share, all we need to say is:</p>
143
<blockquote><pre class="code">[homes]
145
writable = yes</pre></blockquote>
147
<p>The <tt class="literal">[homes]</tt> share is a special section of the
148
Samba configuration file. If a user attempts to connect to an
149
ordinary share that doesn't appear in the
150
<em class="filename">smb.conf</em> file (such as specifying it with a UNC
151
in Windows Explorer), Samba will search for a
152
<tt class="literal">[homes]</tt> share. If one exists, the incoming share
153
name is assumed to be a username and is queried as such in the
154
password database ( <em class="filename">/etc/passwd</em> or equivalent)
155
file of the Samba server. If it appears, Samba assumes the client is
156
a Unix user trying to connect to his home directory.</p>
158
<p>As an illustration, let's assume that
159
<tt class="literal">sofia</tt> is attempting to connect to a share called
160
<tt class="literal">[sofia]</tt> on the Samba server. There is no share by
161
that name in the configuration file, but a <tt class="literal">[homes]</tt>
162
share exists and user <tt class="literal">sofia</tt> is present in the
163
password database, so Samba takes the following steps:</p>
166
<p>Samba creates a new disk share called <tt class="literal">[sofia]</tt> with
167
the <tt class="literal">path</tt> specified in the
168
<tt class="literal">[homes]</tt> section. If no <tt class="literal">path</tt>
169
option is specified in <tt class="literal">[homes]</tt>, Samba initializes
170
it to her home directory.</p>
172
<p>Samba initializes the new share's options from the
173
defaults in <tt class="literal">[globals]</tt>, as well as any overriding
174
options in <tt class="literal">[homes]</tt> with the exception of
175
<tt class="literal">browsable</tt>.</p>
177
<p>Samba connects <tt class="literal">sofia</tt>'s client to
180
<p>The <tt class="literal">[homes]</tt> share is a fast, painless way to
181
create shares for your user community without having to duplicate the
182
information from the password database file in the
183
<em class="filename">smb.conf</em> file. It does have some
184
<a name="INDEX-16"/>peculiarities, however, that we need to
188
<p>The <tt class="literal">[homes]</tt> section can represent any account on
189
the machine, which isn't always desirable. For
190
example, it can potentially create a share for
191
<tt class="literal">root</tt>, <tt class="literal">bin</tt>,
192
<tt class="literal">sys</tt>, <tt class="literal">uucp</tt>, and the like. You
194
<tt class="literal">invalid</tt><a name="INDEX-17"/> <tt class="literal">users</tt> option
195
to protect against this.</p>
197
<p>The meaning of the
198
<tt class="literal">browsable</tt><a name="INDEX-18"/> configuration option is
199
different from other shares; it indicates only that a
200
<tt class="literal">[homes]</tt> section won't show up in
201
the local browse list, not that the <tt class="literal">[alice]</tt> share
202
won't. When the <tt class="literal">[alice]</tt> section
203
is created (after the initial connection), it will use the
204
<tt class="literal">browsable</tt> value from the
205
<tt class="literal">[globals]</tt> section for that share, not the value
206
from <tt class="literal">[homes]</tt>.</p>
208
<p>As we mentioned, there is no need for a path statement in
209
<tt class="literal">[homes]</tt> if the users have Unix home directories in
210
the server's <em class="filename">/etc/passwd</em> file.
211
You should ensure that a valid home directory does exist, however, as
212
Samba will not automatically create a home directory for a user and
213
will refuse a tree connect if the user's directory
214
does not exist or is not accessible. <a name="INDEX-19"/></p>
224
<div class="sect1"><a name="samba2-CHP-9-SECT-2"/>
226
<h2 class="head1">Controlling Access to Shares</h2>
228
<p><a name="INDEX-20"/><a name="INDEX-21"/>Often you will need to restrict the users who
229
can access a specific share for security reasons. This is very easy
230
to do with Samba because it contains a wealth of options for creating
231
practically any security configuration. Let's
232
introduce a few configurations that you might want to use in your own
235
<p>We've seen what happens when you specify valid
236
users. However, you are also allowed to specify a list of
237
<a name="INDEX-22"/>invalid users—users who should never be
238
allowed access to Samba or its shares. This is done with the
239
<tt class="literal">invalid</tt><a name="INDEX-23"/> <tt class="literal">users</tt>
240
option. We hinted at one frequent use of this option earlier: a
241
global default with the <tt class="literal">[homes]</tt> section to ensure
242
that various system users and superusers cannot be forged for access.
245
<blockquote><pre class="code">[global]
246
invalid users = root bin daemon adm sync shutdown \
247
halt mail news uucp operator
248
auto services = dave peter bob
252
writable = yes</pre></blockquote>
254
<p>The <tt class="literal">invalid</tt> <tt class="literal">users</tt> option, like
255
<tt class="literal">valid</tt> <tt class="literal">users</tt>, can take group
256
names, preceded by an at sign (<tt class="literal">@</tt>), as well as
257
usernames. In the event that a user or group appears in both lists,
258
the <tt class="literal">invalid</tt> <tt class="literal">users</tt> option takes
259
precedence, and the user or group is denied access to the share.</p>
261
<p>At the other end of the spectrum, you can explicitly specify users
262
who will be allowed <a name="INDEX-24"/><a name="INDEX-25"/>superuser (root) access to a share with
263
the <tt class="literal">admin</tt><a name="INDEX-26"/> <tt class="literal">users</tt>
264
option. An example follows:</p>
266
<blockquote><pre class="code">[sales]
268
comment = Sedona Real Estate Sales Data
270
valid users = sofie shelby adilia
271
admin users = mike</pre></blockquote>
273
<p>This option takes both group names and usernames. In addition, you
274
can specify NIS netgroups by preceding them with an
275
<tt class="literal">@</tt> as well; if the netgroup is not found, Samba
276
will assume that you are referring to a standard Unix group.</p>
278
<p>Be careful if you assign administrative privileges to a share for an
279
entire group. The Samba Team highly recommends you avoid using this
280
option, as it essentially gives root access to the specified users or
281
groups for that share.</p>
283
<p>If you wish to force read-only or read/write access on users who
284
access a share, you can do so with the
285
<tt class="literal">read</tt><a name="INDEX-27"/> <tt class="literal">list</tt> and
286
<tt class="literal">write</tt> <tt class="literal">list</tt> options,
287
respectively. These options can be used on a per-share basis to
288
restrict a writable share or to grant write access to specific users
289
in a read-only share, respectively. For example:</p>
291
<blockquote><pre class="code">[sales]
293
comment = Sedona Real Estate Sales Data
295
write list = sofie shelby</pre></blockquote>
297
<p>The <tt class="literal">write</tt><a name="INDEX-28"/> <tt class="literal">list</tt> option
298
cannot override Unix permissions. If you've created
299
the share without giving the <tt class="literal">write-list</tt> user write
300
permission on the Unix system, she will be denied write access
301
regardless of the setting of <tt class="literal">write</tt>
302
<tt class="literal">list</tt>.</p>
305
<div class="sect2"><a name="samba2-CHP-9-SECT-2.1"/>
307
<h3 class="head2">Guest Access</h3>
309
<p><a name="INDEX-29"/>As mentioned
310
earlier, you can configure a share using
311
<tt class="literal">guest</tt><a name="INDEX-30"/> <tt class="literal">ok</tt>
312
<tt class="literal">=</tt> <tt class="literal">yes</tt> to allow access to guest
313
users. This works only when using share-level security, which we will
314
cover later in this chapter. When a user connects as a guest,
315
authenticating with a username and password is unnecessary, but Samba
316
still needs a way to map the connected client to a user on the local
317
system. The <tt class="literal">guest</tt><a name="INDEX-31"/>
318
<tt class="literal">account</tt> parameter can be used in the share to
319
specify the Unix account that guest users should be assigned when
320
connecting to the Samba server. The default value for this is set
321
during compilation and is typically <tt class="literal">nobody</tt>, which
322
works well with most Unix versions. However, on some systems the
323
<tt class="literal">nobody</tt><a name="INDEX-32"/> account is not allowed to access some
324
services (e.g., printing), and you might need to set the guest user
325
to <tt class="literal">ftp</tt> or some other account instead.</p>
327
<p>If you wish to restrict access in a share only to guests—in
328
other words, all clients connect as the guest account when accessing
329
the share—you can use the <tt class="literal">guest</tt>
330
<tt class="literal">only</tt> option in conjunction with the
331
<tt class="literal">guest</tt> <tt class="literal">ok</tt> option, as shown in
332
the following example:</p>
334
<blockquote><pre class="code">[sales]
336
comment = Sedona Real Estate Sales Data
340
guest only = yes</pre></blockquote>
342
<p>Make sure you specify <tt class="literal">yes</tt> for both
343
<tt class="literal">guest</tt> <tt class="literal">only</tt> and
344
<tt class="literal">guest</tt> <tt class="literal">ok</tt>; otherwise, Samba will
345
not use the guest account that you specify.</p>
351
<div class="sect2"><a name="samba2-CHP-9-SECT-2.2"/>
353
<h3 class="head2">Access Control Options</h3>
355
<p><a href="ch09.html#samba2-CHP-9-TABLE-1">Table 9-1</a> <a name="INDEX-33"/><a name="INDEX-34"/>summarizes the options that you can use
356
to control access to shares.</p>
358
<a name="samba2-CHP-9-TABLE-1"/><h4 class="head4">Table 9-1. Share-level access options</h4><table border="1">
386
<p><tt class="literal">admin users</tt></p>
389
<p>string (list of usernames)</p>
392
<p>Users who can perform operations as root</p>
403
<p><tt class="literal">valid users</tt></p>
406
<p>string (list of usernames)</p>
409
<p>Users who can connect to a share</p>
420
<p><tt class="literal">invalid users</tt></p>
423
<p>string (list of usernames)</p>
426
<p>Users who will be denied access to a share</p>
437
<p><tt class="literal">read list</tt></p>
440
<p>string (list of usernames)</p>
443
<p>Users who have read-only access to a writable share</p>
454
<p><tt class="literal">write list</tt></p>
457
<p>string (list of usernames)</p>
460
<p>Users who have read/write access to a read-only share</p>
471
<p><tt class="literal">max connections</tt></p>
477
<p>Maximum number of connections for a share at a given time</p>
480
<p><tt class="literal">0</tt></p>
488
<p><tt class="literal">guest only</tt> <tt class="literal">(only guest)</tt></p>
494
<p>If <tt class="literal">yes</tt>, allows only guest access</p>
497
<p><tt class="literal">no</tt></p>
505
<p><tt class="literal">guest account</tt></p>
508
<p>string (name of account)</p>
511
<p>Unix account that will be used for guest access</p>
514
<p><tt class="literal">nobody</tt></p>
524
<div class="sect3"><a name="samba2-CHP-9-SECT-2.2.1"/>
526
<a name="INDEX-35"/><h3 class="head3">admin users</h3>
528
<p>This option specifies a list of users that perform file operations as
529
if they were <tt class="literal">root</tt>. This means that they can modify
530
or destroy any other user's files, regardless of the
531
permissions. Any files that they create will have root ownership and
532
will use the default group of the admin user. The
533
<tt class="literal">admin</tt> <tt class="literal">users</tt> option allows PC
534
users to act as administrators for particular shares. Be very careful
535
when using this option, and make sure good password and other
536
security policies are in place.</p>
543
<div class="sect3"><a name="samba2-CHP-9-SECT-2.2.2"/>
545
<a name="INDEX-36"/><a name="INDEX-37"/><h3 class="head3">valid users, invalid users</h3>
547
<p>These two options let you enumerate the users and groups who are
548
granted or denied access to a particular share. You can enter a list
549
of user and/or group names. If a name is prefixed by an at sign
550
(<tt class="literal">@</tt>), it is interpreted as a group name—with
551
NIS groups searched before Unix groups. If the name is prefixed by a
552
plus sign (<tt class="literal">+</tt>), it is interpreted as the name of a
553
Unix group, and NIS is not searched. If the name is prefixed by an
554
ampersand (<tt class="literal">&</tt>), it is interpreted as an NIS
555
group name rather than as a Unix group name. The plus sign and
556
ampersand can be used together to specify whether NIS or Unix groups
557
are searched first. For example:</p>
559
<blockquote><pre class="code">[database]
560
valid users = mary ellen sue &sales +marketing @dbadmin
561
invalid users = gavin syd dana &techies +&helpdesk</pre></blockquote>
563
<p>In the <tt class="literal">valid</tt> <tt class="literal">users</tt> parameter,
564
users <tt class="literal">mary</tt>, <tt class="literal">ellen</tt>, and
565
<tt class="literal">sue</tt> are allowed access to the
566
<tt class="literal">[database]</tt> share, as are the members of the Unix
567
group <tt class="literal">marketing</tt> and NIS/Unix group
568
<tt class="literal">dbadmin</tt>. The <tt class="literal">invalid</tt>
569
<tt class="literal">users</tt> parameter denies access to the share by
570
users <tt class="literal">gavin</tt>, <tt class="literal">syd</tt>, and
571
<tt class="literal">dana</tt>, as well as members of the NIS group
572
<tt class="literal">techies</tt> and Unix/NIS group
573
<tt class="literal">helpdesk</tt>. In this last case, the list of Unix
574
groups is searched first for the <tt class="literal">helpdesk</tt> group,
575
and if it is not found there, the list of NIS groups is searched.</p>
577
<p>The important rule to remember with these options is that any name or
578
group in the <tt class="literal">invalid</tt> <tt class="literal">users</tt> list
579
will <em class="emphasis">always</em> be denied access, even if it is
580
included (in any form) in the <tt class="literal">valid</tt>
581
<tt class="literal">users</tt> list.</p>
588
<div class="sect3"><a name="samba2-CHP-9-SECT-2.2.3"/>
590
<a name="INDEX-38"/><a name="INDEX-39"/><h3 class="head3">read list, write list</h3>
592
<p>Like the <tt class="literal">valid</tt> <tt class="literal">users</tt>
593
<tt class="literal">and</tt> <tt class="literal">invalid</tt>
594
<tt class="literal">users</tt> options, this pair of options specifies
595
which users have read-only access to a writable share and read/write
596
access to a read-only share, respectively. The value of either
597
options is a list of users. The <tt class="literal">read</tt>
598
<tt class="literal">list</tt> parameter overrides any other Samba
599
permissions granted—as well as Unix file permissions on the
600
server system—to deny users write access.
601
<tt class="literal">The</tt> <tt class="literal">write</tt>
602
<tt class="literal">list</tt> parameter overrides other Samba permissions
603
to grant write access, but cannot grant write access if the user
604
lacks write permissions for the file on the Unix system. You can
605
specify NIS or Unix group names by prefixing the name with an at sign
606
(such as <tt class="literal">@users</tt>). Neither configuration option has
607
a default value associated with it.</p>
614
<div class="sect3"><a name="samba2-CHP-9-SECT-2.2.4"/>
616
<a name="INDEX-40"/><h3 class="head3">max connections</h3>
618
<p>This option specifies the maximum number of client connections that a
619
share can have at any given time. Any connections that are attempted
620
after the maximum is reached will be rejected. The default value is
621
<tt class="literal">0</tt>, which is a special case that allows an
622
unlimited number of connections. You can override it per share as
625
<blockquote><pre class="code">[accounting]
626
max connections = 30</pre></blockquote>
628
<p>This option is useful in the event that you need to limit the number
629
of users who are accessing a licensed program or piece of data
637
<div class="sect3"><a name="samba2-CHP-9-SECT-2.2.5"/>
639
<a name="INDEX-41"/><h3 class="head3">guest only</h3>
641
<p>This share-level option (also called <tt class="literal">only</tt>
642
<tt class="literal">guest</tt>) forces a connection to a share to be
643
performed with the user specified by the <tt class="literal">guest</tt>
644
<tt class="literal">account</tt> option. The share to which this is applied
645
must explicitly specify <tt class="literal">guest</tt>
646
<tt class="literal">ok</tt> <tt class="literal">=</tt> <tt class="literal">yes</tt> for
647
this option to be recognized by Samba. The default value for this
648
option is <tt class="literal">no</tt>.</p>
655
<div class="sect3"><a name="samba2-CHP-9-SECT-2.2.6"/>
657
<a name="INDEX-42"/><h3 class="head3">guest account</h3>
659
<p>This option specifies the name of the account to be used for guest
660
access to shares in Samba. The default for this option varies from
661
system to system, but it is often set to <tt class="literal">nobody</tt>.
662
Some default user accounts have trouble connecting as guest users. If
663
that occurs on your system, the Samba Team recommends using the
664
<tt class="literal">ftp</tt> account as the guest user. <a name="INDEX-43"/> <a name="INDEX-44"/><a name="INDEX-45"/></p>
673
<div class="sect2"><a name="samba2-CHP-9-SECT-2.3"/>
675
<h3 class="head2">Username Options</h3>
677
<p><a href="ch09.html#samba2-CHP-9-TABLE-2">Table 9-2</a> shows two additional options that Samba
678
can use to correct for incompatibilities in usernames between Windows
681
<a name="samba2-CHP-9-TABLE-2"/><h4 class="head4">Table 9-2. Username options</h4><table border="1">
709
<p><tt class="literal">username</tt> <tt class="literal">map</tt></p>
712
<p>string (filename)</p>
715
<p>Sets the name of the username mapping file</p>
726
<p><tt class="literal">username</tt> <tt class="literal">level</tt></p>
732
<p>Indicates the number of capital letters to use when trying to match a
736
<p><tt class="literal">0</tt></p>
746
<div class="sect3"><a name="samba2-CHP-9-SECT-2.3.1"/>
748
<a name="INDEX-46"/><h3 class="head3">username map</h3>
750
<p>Client usernames on an SMB network can be relatively long (up to 255
751
characters), while usernames on a Unix network often cannot be longer
752
than eight characters. This means that an individual user can have
753
one username on a client and another (shorter) one on the Samba
754
server. You can get past this issue by<em class="firstterm">
755
</em><a name="INDEX-47"/>mapping a free-form client
756
username to a Unix username of eight or fewer characters. It is
757
placed in a standard text file, using a format that
758
we'll describe shortly. You can then specify the
759
pathname to Samba with the global <tt class="literal">username</tt>
760
<tt class="literal">map</tt> option. Be sure to restrict access to this
761
file; make the root user the file's owner and deny
762
write access to others (with octal permissions of 744 or 644).
763
Otherwise, an untrusted user with access to the file can easily map
764
his client username to the root user of the Samba server.</p>
766
<p>You can specify this option as follows:</p>
768
<blockquote><pre class="code">[global]
769
username map = /usr/local/samba/private/usermap.txt</pre></blockquote>
771
<p>Each entry in the username map file should be listed as follows: the
772
Unix username, followed by an equal sign (<tt class="literal">=</tt>),
773
followed by one or more whitespace-separated SMB client usernames.
774
Note that unless instructed otherwise (i.e., a guest connection),
775
Samba will expect both the client and the server user to have the
776
same password. You can also map NT groups to one or more specific
777
Unix groups using the <tt class="literal">@</tt> sign. Here are some
780
<blockquote><pre class="code">jarwin = JosephArwin
781
manderso = MarkAnderson
782
users = @account</pre></blockquote>
784
<p>You can also use the asterisk to specify a wildcard that matches any
785
free-form client username as an entry in the username map file:</p>
787
<blockquote><pre class="code">nobody = *</pre></blockquote>
789
<p>Comments can be placed in the file by starting the line with a hash
790
mark (<tt class="literal">#</tt>) or a semicolon (<tt class="literal">;</tt>).</p>
792
<p>Note that you can also use this file to redirect one Unix user to
793
another user. Be careful, though, as Samba and your client might not
794
notify the user that the mapping has been made and Samba might be
795
expecting a different password.</p>
802
<div class="sect3"><a name="samba2-CHP-9-SECT-2.3.2"/>
804
<a name="INDEX-48"/><h3 class="head3">username level</h3>
806
<p>SMB clients (such as Windows) will often send usernames in SMB
807
connection requests entirely in capital letters; in other words,
808
client usernames are not necessarily case-sensitive. On a Unix
809
server, however, usernames <em class="emphasis">are</em> case-sensitive:
810
the user <tt class="literal">ANDY</tt> is different from the user
811
<tt class="literal">andy</tt>. By default, Samba attacks this problem by
812
doing the following:</p>
815
<p>Checking for a user account with the exact name sent by the client</p>
817
<p>Testing the username in all lowercase letters</p>
819
<p>Testing the username in lowercase letters with only the first letter
822
<p>If you wish to have Samba attempt more combinations of upper- and
823
lowercase letters, you can use the <tt class="literal">username</tt>
824
<tt class="literal">level</tt> global configuration option. This option
825
takes an integer value that specifies how many letters in the
826
username should be capitalized when attempting to connect to a share.
827
You can specify this option as follows:</p>
829
<blockquote><pre class="code">[global]
830
username level = 3</pre></blockquote>
832
<p>In this case, Samba attempts all possible permutations of usernames
833
having three capital letters. The larger the number, the more
834
computations Samba has to perform to match the username, and the
835
longer the authentication will take.</p>
848
<div class="sect1"><a name="samba2-CHP-9-SECT-3"/>
850
<h2 class="head1">Authentication of Clients</h2>
852
<p><a name="INDEX-49"/>At
853
this point, we should discuss how Samba authenticates users. Each
854
user who attempts to connect to a share not allowing guest access
855
must provide a password to
856
<a name="INDEX-50"/>make a successful connection. What
857
Samba does with that password—and consequently the strategy
858
Samba will use to handle user authentication—is the arena of
859
the <tt class="literal">security</tt> configuration option. Samba currently
860
supports <a name="INDEX-51"/><a name="INDEX-52"/><a name="INDEX-53"/>four
861
<a name="INDEX-54"/>security levels on its network:
862
<em class="firstterm">share</em>, <em class="firstterm">user</em>,
863
<em class="firstterm">server</em>, and <em class="firstterm">domain</em>.</p>
866
<dt><b><a name="INDEX-55"/>Share-level security</b></dt>
868
<p>Each share in the workgroup has one or more passwords associated with
869
it. Anyone who knows a valid password for the share can access it.</p>
874
<dt><b><a name="INDEX-56"/>User-level security</b></dt>
876
<p>Each share in the workgroup is configured to allow access from
877
certain users. With each initial tree connection, the Samba server
878
verifies users and their passwords to allow them access to the share.</p>
883
<dt><b><a name="INDEX-57"/>Server-level security</b></dt>
885
<p>This is the same as user-level security, except that the Samba server
886
uses another server to validate users and their passwords before
887
granting access to the share.</p>
892
<dt><b><a name="INDEX-58"/>Domain-level security</b></dt>
894
<p>Samba becomes a member of a Windows NT domain and uses one of the
895
domain's domain controllers—either the PDC or
896
a BDC—to perform authentication. Once authenticated, the user
897
is given a special token that allows her access to any share with
898
appropriate access rights. With this token, the domain controller
899
will not have to revalidate the user's password each
900
time she attempts to access another share within the domain. The
901
domain controller can be a Windows NT/2000 PDC or BDC, or Samba
902
acting as a Windows NT PDC.</p>
907
<p>Each security policy can be implemented with the global
908
<tt class="literal">security</tt> option, as shown in <a href="ch09.html#samba2-CHP-9-TABLE-3">Table 9-3</a>.</p>
910
<a name="samba2-CHP-9-TABLE-3"/><h4 class="head4">Table 9-3. Security option</h4><table border="1">
938
<p><tt class="literal">security</tt><a name="INDEX-59"/></p>
941
<p><tt class="literal">domain</tt>, <tt class="literal">server</tt>,
942
<tt class="literal">share</tt>, or <tt class="literal">user</tt></p>
945
<p>Indicates the type of security that the Samba server will use</p>
948
<p><tt class="literal">user</tt></p>
958
<div class="sect2"><a name="samba2-CHP-9-SECT-3.1"/>
960
<h3 class="head2">Share-Level Security</h3>
962
<p>With share-level security, each share has one or more passwords
963
associated with it, with the client being authenticated when first
964
connecting to the share. This differs from the other modes of
965
security in that there are no restrictions as to whom can access a
966
share, as long as that individual knows the correct password. Shares
967
often have multiple passwords. For example, one password might grant
968
read-only access, while another might grant read/write access.
969
Security is maintained as long as unauthorized users do not discover
970
the password for a share to which they shouldn't
973
<p>OS/2 and Windows 95/98/Me both support share-level security on their
974
resources. You can set up share-level security with Windows 95/98/Me
975
by first enabling share-level security using the Access Control tab
976
of the Network Control Panel dialog. Then select the
977
"Share-level access control" radio
978
button (which deselects the "User-level access
979
control" radio button), as shown in <a href="ch09.html#samba2-CHP-9-FIG-1">Figure 9-1</a>, and click the OK button. Reboot as requested.</p>
981
<div class="figure"><a name="samba2-CHP-9-FIG-1"/><img src="figs/sam2_0901.gif"/></div><h4 class="head4">Figure 9-1. Selecting share-level security on a Windows 95/98/Me system</h4>
983
<p>Next, right-click a resource—such as a hard drive or a
984
CD-ROM—and select the Properties menu item. This will bring up
985
the Resource Properties dialog box. Select the Sharing tab at the top
986
of the dialog box, and enable the resource as Shared As. From here,
987
you can configure how the shared resource will appear to individual
988
users, as well as assign whether the resource will appear as
989
read-only, read/write, or a mix, depending on the password that is
992
<p>You might be thinking that this security model is not a good fit for
993
Samba—and you would be right. In fact, if you set the
994
<tt class="literal">security</tt> <tt class="literal">=</tt>
995
<tt class="literal">share</tt> option in the Samba configuration file,
996
Samba will still reuse the username/password combinations in the
997
system password files to authenticate access. More precisely, Samba
998
will take the following steps when a client requests a connection
999
using share-level security:</p>
1002
<p>When a connection is requested, Samba will accept the password and
1003
(if sent) the username of the client.</p>
1005
<p>If the share is <tt class="literal">guest</tt> <tt class="literal">only</tt> ,
1006
the user is immediately granted access to the share with the rights
1007
of the user specified by the <tt class="literal">guest</tt>
1008
<tt class="literal">account</tt> parameter; no password checking is
1011
<p>For other shares, Samba appends the username to a list of users who
1012
are allowed access to the share. It then attempts to validate the
1013
password given in association with that username. If successful,
1014
Samba grants the user access to the share with the rights assigned to
1015
that user. The user will not need to authenticate again unless a
1016
<tt class="literal">revalidate</tt> <tt class="literal">=</tt>
1017
<tt class="literal">yes</tt> option has been set inside the share.</p>
1019
<p>If the authentication is unsuccessful, Samba attempts to validate the
1020
password against the list of users previously compiled during
1021
attempted connections, as well as those specified under the share in
1022
the configuration file. If the password matches that of any username
1023
(as specified in the system password file, typically
1024
<em class="filename">/etc/passwd </em>), the user is granted access to the
1025
share under that username.</p>
1027
<p>However, if the share has a <tt class="literal">guest</tt>
1028
<tt class="literal">ok</tt> or <tt class="literal">public</tt> option set, the
1029
user will default to access with the rights of the user specified by
1030
the <tt class="literal">guest</tt> <tt class="literal">account</tt> option.</p>
1032
<p>You can indicate in the configuration file which users should be
1033
initially placed on the share-level security user list by using the
1034
<tt class="literal">username</tt> configuration option, as shown here:</p>
1036
<blockquote><pre class="code">[global]
1040
path = /home/samba/accounting1
1043
username = davecb, pkelly, andyo</pre></blockquote>
1045
<p>Here, when a user attempts to connect to a share, Samba verifies the
1046
sent password against each user in its own list, in addition to the
1047
passwords of users <tt class="literal">davecb</tt>,
1048
<tt class="literal">pkelly</tt>, and <tt class="literal">andyo</tt>. If any of
1049
the passwords match, the connection is verified, and the user is
1050
allowed. Otherwise, connection to the specific share will fail.</p>
1056
<div class="sect2"><a name="samba2-CHP-9-SECT-3.2"/>
1058
<h3 class="head2">Share-Level Security Options</h3>
1060
<p><a href="ch09.html#samba2-CHP-9-TABLE-4">Table 9-4</a> shows the options typically associated
1061
with <em class="firstterm">share-level
1062
security</em><a name="INDEX-60"/>.</p>
1064
<a name="samba2-CHP-9-TABLE-4"/><h4 class="head4">Table 9-4. Share-level access options</h4><table border="1">
1092
<p><tt class="literal">only user</tt></p>
1098
<p>If <tt class="literal">yes</tt>, usernames specified by
1099
<tt class="literal">username</tt> are the only ones allowed</p>
1102
<p><tt class="literal">no</tt></p>
1110
<p><tt class="literal">username</tt> (<tt class="literal">user</tt> or
1111
<tt class="literal">users</tt>)</p>
1114
<p>string (list of usernames)</p>
1117
<p>Users against which a client's password is tested</p>
1130
<div class="sect3"><a name="samba2-CHP-9-SECT-3.2.1"/>
1132
<a name="INDEX-61"/><h3 class="head3">only user</h3>
1134
<p>This Boolean option indicates whether Samba will allow connections to
1135
a share using share-level security based solely on the individuals
1136
specified in the <tt class="literal">username</tt> option, instead of those
1137
users compiled on Samba's internal list. The default
1138
value for this option is <tt class="literal">no</tt>. You can override it
1139
per share as follows:</p>
1141
<blockquote><pre class="code">[global]
1144
username = andy, peter, valerie
1145
only user = yes</pre></blockquote>
1152
<div class="sect3"><a name="samba2-CHP-9-SECT-3.2.2"/>
1154
<a name="INDEX-62"/><h3 class="head3">username</h3>
1156
<p>This option presents a list of usernames and/or group names against
1157
which Samba tests a connection password to allow access. It is
1158
typically used with clients that have share-level security to allow
1159
connections to a particular service based solely on a qualifying
1160
password—in this case, one that matches a password set up for a
1163
<blockquote><pre class="code">[global]
1166
username = andy, peter, terry</pre></blockquote>
1168
<p>You can enter a list of usernames and/or group names. If a name is
1169
prefixed by an at sign (<tt class="literal">@</tt>), it is interpreted as a
1170
group name, with NIS groups searched before Unix groups. If the name
1171
is prefixed by a plus sign (<tt class="literal">+</tt>), it is interpreted
1172
as the name of a Unix group, and NIS is not searched. If the name is
1173
prefixed by an ampersand (<tt class="literal">&</tt>), it is
1174
interpreted as an NIS group name rather than a Unix group name. The
1175
plus sign and ampersand can be used together to specify whether NIS
1176
or Unix groups are searched first. When Samba encounters a group name
1177
in this option, it attempts to authenticate each user in the group
1178
until if finds one that succeeds. Beware that this can be very
1181
<p>We recommend against using this option unless you are implementing a
1182
Samba server with share-level security.</p>
1191
<div class="sect2"><a name="samba2-CHP-9-SECT-3.3"/>
1193
<h3 class="head2">User-Level Security</h3>
1195
<p>The default mode of security with Samba is <em class="firstterm">user-level
1196
security</em><a name="INDEX-63"/>. With this method, each share is
1197
assigned specific users that can access it. When a user requests a
1198
connection to a share, Samba authenticates by validating the given
1199
username and password with the authorized users in the configuration
1200
file and the passwords in the password database of the Samba server.
1201
As mentioned earlier in the chapter, one way to isolate which users
1202
are allowed access to a specific share is by using the
1203
<tt class="literal">valid</tt> <tt class="literal">users</tt> option for each
1206
<blockquote><pre class="code">[global]
1211
valid users = bob, joe, sandy</pre></blockquote>
1213
<p>Each user listed can connect to the share if the password provided
1214
matches the password stored in the system password database on the
1215
server. Once the initial authentication succeeds, the client will not
1216
need to supply a password again to access that share unless the
1217
<tt class="literal">revalidate</tt> <tt class="literal">=</tt>
1218
<tt class="literal">yes</tt> option has been set.</p>
1220
<p>Passwords can be sent to the Samba server in either an encrypted or a
1221
nonencrypted format. If you have both types of systems on your
1222
network, you should ensure that the passwords represented by each
1223
user are stored both in a traditional account database and
1224
Samba's encrypted password database. This way,
1225
authorized users can gain access to their shares from any type of
1226
client.<a name="FNPTR-1"/><a href="#FOOTNOTE-1">[1]</a> However, we recommend that you
1227
move your system to encrypted passwords and abandon nonencrypted
1228
passwords if security is an issue. <a href="ch09.html#samba2-CHP-9-SECT-4">Section 9.4</a> of this chapter
1229
explains how to use encrypted as well as nonencrypted passwords.</p>
1235
<div class="sect2"><a name="samba2-CHP-9-SECT-3.4"/>
1237
<h3 class="head2">Server-Level Security</h3>
1239
<p><em class="firstterm">Server-level
1240
security</em><a name="INDEX-64"/> is similar to user-level security.
1241
However, with server-level security, Samba delegates password
1242
authentication to another SMB password server—typically another
1243
Samba server or a Windows NT/2000 server acting as a PDC on the
1244
network. Note that Samba still maintains its list of shares and their
1245
configuration in its <em class="filename">smb.conf</em> file. When a
1246
client attempts to make a connection to a particular share, Samba
1247
validates that the user is indeed authorized to connect to the share.
1248
Samba then attempts to validate the password by passing the username
1249
and password to the SMB password server. If the password is accepted,
1250
a session is established with the client. See <a href="ch09.html#samba2-CHP-9-FIG-2">Figure 9-2</a> for an illustration of this setup.</p>
1252
<div class="figure"><a name="samba2-CHP-9-FIG-2"/><img src="figs/sam2_0902.gif"/></div><h4 class="head4">Figure 9-2. A typical system setup using server-level security</h4>
1254
<p>You can configure Samba to use a separate password server under
1255
server-level security with the use of the
1256
<tt class="literal">password</tt><a name="INDEX-65"/> <tt class="literal">server</tt>
1257
global configuration option, as follows:</p>
1259
<blockquote><pre class="code">[global]
1261
password server = mixtec toltec</pre></blockquote>
1263
<p>Note that you can specify more than one machine as the target of the
1264
<tt class="literal">password</tt> <tt class="literal">server</tt>; Samba moves
1265
down the list of servers in the event that its first choice is
1266
unreachable. The servers identified by the
1267
<tt class="literal">password</tt> <tt class="literal">server</tt> option are
1268
given as NetBIOS names, not their DNS names or equivalent IP
1269
addresses. Also, if any of the servers reject the given password, the
1270
connection automatically fails—Samba will not attempt another
1273
<p>One caveat: when using this option, you still need an account
1274
representing that user on the regular Samba server. This is because
1275
the Unix operating system needs a username to perform various I/O
1276
operations. The preferable method of handling this is to give the
1277
user an account on the Samba server but disable the
1278
account's password by replacing it in the system
1279
password file (e.g., <em class="filename">/etc/passwd </em>) with an
1286
<div class="sect2"><a name="samba2-CHP-9-SECT-3.5"/>
1288
<h3 class="head2">Domain-Level Security</h3>
1290
<p>With <em class="firstterm">domain-level
1291
security</em><a name="INDEX-66"/>, the Samba server acts as a member of
1292
a Windows domain. Recall from <a href="ch01.html">Chapter 1</a> that each
1293
domain has a primary domain controller, which can be a Windows
1294
NT/2000 or Samba server offering password authentication. The domain
1295
controller keeps track of users and passwords in its own database and
1296
authenticates each user when she first logs on and wishes to access
1297
another machine's shares.</p>
1299
<p>As mentioned earlier in this chapter, Samba has a similar ability to
1300
offer user-level security, but that option is Unix-centric and
1301
assumes that the authentication occurs via Unix password files. If
1302
the Unix machine is part of an NIS or NIS+ domain, Samba
1303
authenticates users transparently against a shared password file in
1304
typical Unix fashion. Samba then provides access to the NIS or NIS+
1305
domain from Windows. There is, of course, no relationship between the
1306
NIS concept of a domain and a Windows NT domain.</p>
1308
<p>Configuring Samba for domain-level security is covered in <a href="ch04.html">Chapter 4</a> in <a href="ch04.html#samba2-CHP-4-SECT-7">Section 4.7</a>. <a name="INDEX-67"/></p>
1318
<div class="sect1"><a name="samba2-CHP-9-SECT-4"/>
1320
<h2 class="head1">Passwords</h2>
1322
<p><a name="INDEX-68"/>Passwords
1323
are a thorny issue with Samba. So much so, in fact, that they are
1324
often the first major problem that users encounter when they install
1325
Samba. At this point, we need to delve deeper into Samba to discover
1326
what is happening on the network.</p>
1328
<p>Passwords sent from individual clients can be either encrypted or
1329
nonencrypted. Encrypted passwords are, of course, more secure. A
1330
nonencrypted, plain-text password can be easily read with a
1331
packet-sniffing program, such as the modified
1332
<em class="emphasis">tcpdump</em> program for Samba that we used in <a href="ch01.html">Chapter 1</a>. Whether passwords are encrypted by default
1333
depends on the operating system that the client is using to connect
1334
to the Samba server. <a href="ch09.html#samba2-CHP-9-TABLE-5">Table 9-5</a> lists which
1335
<a name="INDEX-69"/>Windows operating
1336
systems encrypt their passwords and which send plain-text passwords
1339
<a name="samba2-CHP-9-TABLE-5"/><h4 class="head4">Table 9-5. Windows operating systems with encrypted passwords</h4><table border="1">
1345
<p>Operating system</p>
1348
<p>Encrypted or plain text</p>
1355
<p>Windows for Workgroups</p>
1371
<p>Windows 95 with SMB Update</p>
1395
<p>Windows NT 3.x</p>
1403
<p>Windows NT 4.0 before SP <tt class="literal">3</tt></p>
1411
<p>Windows NT 4.0 after SP 3</p>
1436
<p>Three different encryption methods are used. Windows 95/98/Me clients
1437
use a method inherited from Microsoft's LAN Manager
1438
network software. Windows NT/2000/XP systems use a newer system,
1439
called NT LAN Manager, or NTLM. A newer version of this (called NT
1440
LAN Manager Version 2, or NTLMv2) uses a different method for
1441
password hashing.</p>
1443
<p>If encrypted passwords are supported, Samba stores the encrypted
1444
passwords in a file called <em class="filename">smbpasswd</em>. By
1445
default, this file is located in the <em class="filename">private</em>
1446
directory of the Samba distribution (typically
1447
<em class="filename">/usr/local/samba/private</em>). At the same time, the
1448
client stores an encrypted version of a user's
1449
password on its own system. The plain-text password is never stored
1450
on either system. Each system encrypts the password automatically
1451
using a standard algorithm when the password is set or changed.</p>
1453
<p>When a client requests a connection to an SMB server that supports
1454
encrypted passwords (such as Samba or Windows NT/2000/XP), the two
1455
computers undergo the following negotiations:</p>
1458
<p>The client attempts to negotiate a protocol with the server.</p>
1460
<p>The server responds with a protocol and indicates that it supports
1461
encrypted passwords. At this time, it sends back a randomly generated
1462
8-byte challenge string.</p>
1464
<p>The client uses the challenge string as a key to encrypt its already
1465
encrypted password using an algorithm predefined by the negotiated
1466
protocol. It then sends the result to the server.</p>
1468
<p>The server does the same thing with the encrypted password stored in
1469
its database. If the results match, the passwords are equivalent, and
1470
the user is authenticated.</p>
1472
<p>Note that even though the original passwords are not involved in the
1473
authentication process, you need to be very careful that the
1474
encrypted passwords located inside the <em class="filename">smbpasswd</em>
1475
file are guarded from unauthorized users. If they are compromised, an
1476
unauthorized user can break into the system by replaying the steps of
1477
the previous algorithm. The encrypted passwords are just as sensitive
1478
as the plain-text passwords—this is known as
1479
<em class="firstterm">plain-text-equivalent</em> data in the cryptography
1480
world. Of course, your local security policy should require that the
1481
clients safeguard their plain-text-equivalent passwords as well.</p>
1483
<p>You can configure Samba to accept encrypted passwords with the
1484
following global additions to <em class="filename">smb.conf</em>. Note
1485
that we explicitly name the location of the Samba password file:</p>
1487
<blockquote><pre class="code">[global]
1489
encrypt passwords = yes
1490
smb passwd file = /usr/local/samba/private/smbpasswd</pre></blockquote>
1492
<p>Samba, however, will not accept any users until the
1493
<em class="filename">smbpasswd</em> file has been created and the users
1494
have been added to it with the <em class="emphasis">smbpasswd</em>
1495
command, as we showed you in <a href="ch02.html">Chapter 2</a>.</p>
1498
<div class="sect2"><a name="samba2-CHP-9-SECT-4.1"/>
1500
<h3 class="head2">Disabling Encrypted Passwords on the Client</h3>
1502
<p><a name="INDEX-70"/><a name="INDEX-71"/>While Unix authentication has been
1503
in use for decades—including the use of
1504
<em class="emphasis">telnet</em> and <em class="emphasis">rlogin</em> access
1505
across the Internet—it embodies well-known security risks.
1506
Plaintext passwords are sent over the Internet and can be retrieved
1507
from TCP packets by malicious snoopers. However, if you feel that
1508
your network is secure and you wish to use standard Unix
1509
<em class="filename">/etc/passwd</em> authentication for all clients, you
1510
can do so, but you must disable encrypted passwords on those Windows
1511
clients that default to using them.</p>
1513
<p>To do this, you must modify the Windows registry on each client
1514
system. The Samba distribution includes the <em class="filename">.reg</em>
1515
files you need for this, located in the source
1516
distribution's <em class="filename">/docs/Registry</em>
1517
directory. Depending on the platform, you use one of the following
1520
<blockquote class="simplelist">
1522
<p><em class="filename">Win95_PlainPassword.reg</em></p>
1524
<p><em class="filename">Win98_PlainPassword.reg</em></p>
1526
<p><em class="filename">WinME_PlainPassword.reg</em></p>
1528
<p><em class="filename">NT_PlainPassword.reg</em></p>
1530
<p><em class="filename">Win2000_PlainPassword.reg</em></p>
1534
<p>(For Windows XP, use the <em class="filename">.reg</em> file for Windows
1535
2000.) You can perform the installation by copying the appropriate
1536
<em class="filename">.reg</em> file to a DOS floppy, inserting the floppy
1537
in the client's floppy drive, and running the
1538
<em class="filename">.reg</em> file from the Run menu item in the
1539
client's Start menu. (Or you can just double-click
1540
the file's icon.)</p>
1542
<p>After you reboot the machine, the client will not encrypt its hashed
1543
passwords before sending them to the server. This means that the
1544
plain-text passwords can been seen in the TCP packets that are
1545
broadcast across the network. Again, we encourage you not to do this
1546
unless you are absolutely sure that your network is secure.</p>
1548
<p>If passwords are not encrypted, use these two lines in your Samba
1549
configuration file:</p>
1551
<blockquote><pre class="code">[global]
1553
encrypt passwords = no</pre></blockquote>
1559
<div class="sect2"><a name="samba2-CHP-9-SECT-4.2"/>
1561
<h3 class="head2">The smbpasswd File</h3>
1563
<p>Samba stores its encrypted passwords in a file called
1564
<em class="filename">smbpasswd</em><a name="INDEX-72"/>,
1565
which by default resides in the
1566
<em class="filename">/usr/local/samba/private</em> directory. The
1567
<em class="filename">smbpasswd</em> file should be guarded as closely as
1568
the Unix system's password file (either
1569
<em class="filename">/etc/passwd</em> or
1570
<em class="filename">/etc/shadow</em>). Only the root user should have
1571
read/write access to the <em class="filename">private</em> directory, and
1572
no other users should have access to it at all. In addition, the
1573
<em class="filename">smbpasswd</em> file should have all access denied to
1574
all users except for root. When things are set up for good security,
1575
long listings of the <em class="filename">private</em> directory and
1576
<em class="filename">smbpasswd</em> file look like the following:</p>
1578
<blockquote><pre class="code"># <tt class="userinput"><b>ls -ld /usr/local/samba/private</b></tt>
1579
drwx- - - - - - 2 root root 4096 Nov 26 01:11 /usr/local/samba/private
1580
# <tt class="userinput"><b>ls -l /usr/local/samba/private/smbpasswd</b></tt>
1581
-rw- - - - - - - 1 root root 204 Nov 26 01:11 /usr/local/samba/private/smbpasswd</pre></blockquote>
1583
<p>Before you can use encrypted passwords, you need to create an entry
1584
for each Unix user in the <em class="filename">smbpasswd</em> file. The
1585
structure of the file is somewhat similar to a Unix
1586
<em class="filename">passwd</em> file, but has different fields. <a href="ch09.html#samba2-CHP-9-FIG-3">Figure 9-3</a> illustrates the layout of the
1587
<em class="filename">smbpasswd</em> file; the entry shown is actually one
1588
line in the file.</p>
1590
<div class="figure"><a name="samba2-CHP-9-FIG-3"/><img src="figs/sam2_0903.gif"/></div><h4 class="head4">Figure 9-3. Structure of the smbpasswd file entry (actually one line)</h4>
1592
<p>Normally, entries in the <em class="filename">smbpasswd</em> file are
1593
created automatically by the <em class="emphasis">smbpasswd</em> command.
1594
Still, you might like to know how to interpret data within the
1595
<em class="filename">smbpasswd</em> file, in case you'd
1596
like to see what accounts are stored in it or even modify it
1597
manually. Here is a breakdown of the individual fields:</p>
1600
<dt><b>Username</b></dt>
1602
<p>This is the username of the account. It is taken directly from the
1603
system password file.</p>
1610
<p>This is the user ID (UID) of the account. Like the username, it is
1611
taken directly from the system password file and must match the UID
1617
<dt><b>LAN Manager Password Hash</b></dt>
1619
<p>This is a 32-bit hexadecimal sequence that represents the password
1620
Windows 95/98/Me clients will use. It is derived by splitting the
1621
password into two 7-character strings, with all lowercase letters
1622
forced into uppercase. If fewer than 14 characters are in the
1623
password, the strings are padded with nulls. Then each 7-character
1624
string is converted to a 56-bit DES key and used to encrypt the
1625
constant string <tt class="literal">KGS!@#$%</tt>. The two 64-bit results
1626
are concatenated and stored as the password hash.</p>
1629
<p>If there is currently no password for the user, the first 11
1630
characters of the hash will consist of the sequence
1631
<tt class="literal">NO</tt> <tt class="literal">PASSWORD</tt> followed by
1632
<tt class="literal">X</tt> characters for the remainder. If the password
1633
has been disabled, it will consist of 32 <tt class="literal">X</tt>
1638
<dt><b>NT LAN Manager (NTLM) Password Hash</b></dt>
1640
<p>This is a 32-bit hexadecimal sequence that represents the password
1641
Windows NT/2000/XP clients will use. It is derived by hashing the
1642
user's password (represented as a 16-bit
1643
little-endian Unicode sequence) with an MD4 hash. The password is not
1644
converted to uppercase letters first.</p>
1649
<dt><b>Account Flags</b></dt>
1651
<p>This field consists of 11 characters between two braces ( [ ] ). Any
1652
of the following characters can appear in any order; the remaining
1653
characters should be spaces:</p>
1659
<p>This account is a standard user account.</p>
1666
<p>This account is currently disabled, and Samba should not allow any
1674
<p>This account has no password associated with it.</p>
1681
<p>This is a workstation trust account that can be used to configure
1682
Samba as a PDC when allowing Windows NT machines to join its domain.</p>
1689
<dt><b>Last Change Time</b></dt>
1691
<p>This code consists of the characters <tt class="literal">LCT-</tt> followed
1692
by a hexadecimal representation of the number of seconds since the
1693
epoch (midnight on January 1, 1970) that the entry was last changed.
1694
<a name="INDEX-73"/></p>
1703
<div class="sect2"><a name="samba2-CHP-9-SECT-4.3"/>
1705
<h3 class="head2">Password Synchronization</h3>
1707
<p><a name="INDEX-74"/><a name="INDEX-75"/>Having a regular password (either in
1708
<em class="filename">/etc/passwd</em> or <em class="filename">/etc/shadow</em>)
1709
and an encrypted version of the same password (in the
1710
<em class="filename">smbpasswd</em> file) can be troublesome when you need
1711
to change both of them. Luckily, Samba affords you a limited ability
1712
to keep your passwords synchronized. Samba has a pair of
1713
configuration options to update a user's regular
1714
Unix password automatically when the encrypted password is changed on
1715
the system. The feature can be activated by specifying the
1716
<tt class="literal">unix</tt><a name="INDEX-76"/> <tt class="literal">password</tt>
1717
<tt class="literal">sync</tt> global configuration option:</p>
1719
<blockquote><pre class="code">[global]
1720
unix password sync = yes</pre></blockquote>
1722
<p>With this option enabled, Samba attempts to change the
1723
user's regular password (as <tt class="literal">root</tt>)
1724
when the encrypted version is changed with
1725
<em class="filename">smbpasswd</em>. However, two other options have to be
1726
set correctly for this to work.</p>
1728
<p>The easier of the two is <tt class="literal">passwd</tt>
1729
<tt class="literal">program</tt>. This option simply specifies the Unix
1730
command used to change a user's standard system
1731
password. It is set to <tt class="literal">/bin/passwd</tt>
1732
<tt class="literal">%u</tt> by default. With some Unix systems, this is
1733
sufficient, and you do not need to change anything. Others, such as
1734
Red Hat Linux, use <em class="emphasis">/usr/bin/passwd</em> instead. In
1735
addition, you might want to change this to another program or script
1736
at some point in the future. For example, let's
1737
assume that you want to use a script called
1738
<em class="emphasis">changepass</em> to change a user's
1739
password. Recall that you can use the variable <tt class="literal">%u</tt>
1740
to represent the current Unix username. So the example becomes:</p>
1742
<blockquote><pre class="code">[global]
1743
unix password sync = yes
1744
passwd program = changepass %u</pre></blockquote>
1746
<p>Note that this program is called as the <tt class="literal">root</tt> user
1747
when the <tt class="literal">unix</tt> <tt class="literal">password</tt>
1748
<tt class="literal">sync</tt> option is set to <tt class="literal">yes</tt>. This
1749
is because Samba does not necessarily have the old plain-text
1750
password of the user.</p>
1752
<p>The harder option to configure is
1753
<tt class="literal">passwd</tt><a name="INDEX-77"/> <tt class="literal">chat</tt>. The
1754
<tt class="literal">passwd</tt> <tt class="literal">chat</tt> option works like a
1755
Unix chat script. It specifies a series of strings to send, as well
1756
as responses to expect from the program specified by the
1757
<tt class="literal">passwd</tt> <tt class="literal">program</tt> option. For
1758
example, this is what the default <tt class="literal">passwd</tt>
1759
<tt class="literal">chat</tt> looks like. The delimiters are the spaces
1760
between each grouping of characters:</p>
1762
<blockquote><pre class="code">passwd chat = *old*password* %o\n *new*password* %n\n *new*password* %n\n *changed*</pre></blockquote>
1764
<p>The first grouping represents a response expected from the
1765
password-changing program. Note that it can contain wildcards
1766
(<tt class="literal">*</tt>), which help to generalize the chat programs to
1767
handle a variety of similar outputs. Here,
1768
<tt class="literal">*old*password*</tt> indicates that Samba is expecting
1769
any line from the password program containing the letters
1770
<tt class="literal">old</tt> followed by the letters
1771
<tt class="literal">password</tt>, without regard for what comes before,
1772
after, or between them. If Samba does not receive the expected
1773
response, the password change will fail.</p>
1775
<p>The second grouping indicates what Samba should send back once the
1776
data in the first grouping has been matched. In this case, you see
1777
<tt class="literal">%o\n</tt>. This response is actually two items: the
1778
variable <tt class="literal">%o</tt> represents the old password, while the
1779
<tt class="literal">\n</tt> is a newline character. So, in effect, this
1780
will "type" the old password into
1781
the standard input of the password-changing program, and then
1782
"press" Enter.</p>
1784
<p>Following that is another response grouping, followed by data that
1785
will be sent back to the password-changing program. (In fact, this
1786
response/send pattern continues indefinitely in any standard Unix
1787
<em class="emphasis">chat</em> script.) The script continues until the
1788
final pattern is matched.</p>
1790
<p>You can help match the response strings sent from the password
1791
program with the characters listed in <a href="ch09.html#samba2-CHP-9-TABLE-6">Table 9-6</a>.
1792
In addition, you can use the characters listed in <a href="ch09.html#samba2-CHP-9-TABLE-7">Table 9-7</a> to help formulate your response.</p>
1794
<a name="samba2-CHP-9-TABLE-6"/><h4 class="head4">Table 9-6. Password chat response characters</h4><table border="1">
1810
<p><tt class="literal">*</tt></p>
1813
<p>Zero or more occurrences of any character.</p>
1818
<p>"<tt class="literal"> </tt>"</p>
1821
<p>Allows you to include matching strings that contain spaces. Asterisks
1822
are still considered wildcards even inside of quotes, and you can
1823
represent a null response with empty quotes.</p>
1829
<a name="samba2-CHP-9-TABLE-7"/><h4 class="head4">Table 9-7. Password chat send characters</h4><table border="1">
1845
<p><tt class="literal">%o</tt></p>
1848
<p>The user's old password</p>
1853
<p><tt class="literal">%n</tt></p>
1856
<p>The user's new password</p>
1861
<p><tt class="literal">\n</tt></p>
1864
<p>The linefeed character</p>
1869
<p><tt class="literal">\r</tt></p>
1872
<p>The carriage-return character</p>
1877
<p><tt class="literal">\t</tt></p>
1880
<p>The tab character</p>
1885
<p><tt class="literal">\s</tt></p>
1894
<p>For example, you might want to change your password chat to the
1895
following entry. This handles scenarios in which you do not have to
1896
enter the old password. In addition, this also handles the new
1897
<tt class="literal">all</tt> <tt class="literal">tokens</tt>
1898
<tt class="literal">updated</tt> <tt class="literal">successfully</tt> string
1899
that Red Hat Linux sends:</p>
1901
<blockquote><pre class="code">passwd chat = *New password* %n\n *new password* %n\n *success*</pre></blockquote>
1903
<p>Again, the default chat should be sufficient for many Unix systems.
1904
If it isn't, you can use the
1905
<tt class="literal">passwd</tt> <tt class="literal">chat</tt>
1906
<tt class="literal">debug</tt> global option to set up a new chat script
1907
for the password change program. The <tt class="literal">passwd</tt>
1908
<tt class="literal">chat</tt> <tt class="literal">debug</tt> option logs
1909
everything during a password chat. This option is a simple Boolean,
1912
<blockquote><pre class="code">[global]
1913
unix password sync = yes
1914
passwd chat debug = yes
1915
log level = 100</pre></blockquote>
1917
<p>After you activate the password chat debug feature, all I/O received
1918
by Samba through the password chat can be sent to the
1919
<em class="filename">log.smbd</em> Samba log file with a debug level of
1920
100, which is why we entered a new <tt class="literal">log</tt>
1921
<tt class="literal">level</tt> option as well. As this can often generate
1922
multitudes of error logs, it can be more efficient to use your own
1923
script—by setting the <tt class="literal">passwd</tt>
1924
<tt class="literal">program</tt> option—in place of
1925
<em class="filename">/bin/passwd</em> to record what happens during the
1926
exchange. Be careful because the log file contains the passwords in
1927
plain text. Keeping files containing plain-text passwords can (or
1928
<em class="emphasis">should</em>) be against local security policy in your
1929
organization, and it also might raise serious legal issues. Make sure
1930
to protect your log files with strict file permissions and to delete
1931
them as soon as you've grabbed the information you
1932
need. If possible, use the <tt class="literal">passwd</tt>
1933
<tt class="literal">chat</tt> <tt class="literal">debug</tt> option only while
1934
your own password is being changed.</p>
1936
<p>The operating system on which Samba is running might have strict
1937
requirements for valid passwords to make them more impervious to
1938
dictionary attacks and the like. Users should be made aware of these
1939
restrictions when changing their passwords.</p>
1941
<p>Earlier we said that password synchronization is limited. This is
1942
because there is no reverse synchronization of the encrypted
1943
<em class="filename">smbpasswd</em> file when a standard Unix password is
1944
updated by a user. There are various strategies to get around this,
1945
including NIS and freely available implementations of the Pluggable
1946
Authentication Modules (PAM) standard, but none of them really solves
1947
all the problems.</p>
1949
<p>More information regarding passwords can be found in the in the Samba
1950
source distribution file
1951
<em class="filename">docs/htmldocs/ENCRYPTION.html</em>.<a name="INDEX-80"/></p>
1957
<div class="sect2"><a name="samba2-CHP-9-SECT-4.4"/>
1959
<h3 class="head2">Password Configuration Options</h3>
1961
<p><a name="INDEX-81"/><a name="INDEX-82"/>The options in <a href="ch09.html#samba2-CHP-9-TABLE-8">Table 9-8</a> will help you work with passwords in Samba.</p>
1963
<a name="samba2-CHP-9-TABLE-8"/><h4 class="head4">Table 9-8. Password configuration options</h4><table border="1">
1991
<p><tt class="literal">encrypt</tt> <tt class="literal">passwords</tt></p>
1997
<p>If <tt class="literal">yes</tt>, enables encrypted passwords.</p>
2000
<p><tt class="literal">no</tt></p>
2008
<p><tt class="literal">unix password</tt> <tt class="literal">sync</tt></p>
2014
<p>If <tt class="literal">yes</tt>, updates the standard Unix password
2015
database when a user changes his encrypted password.</p>
2018
<p><tt class="literal">no</tt></p>
2026
<p><tt class="literal">passwd chat</tt></p>
2029
<p>string (chat commands)</p>
2032
<p>Sequence of commands sent to the password program.</p>
2035
<p>See earlier section on this option</p>
2043
<p><tt class="literal">passwd chat</tt> <tt class="literal">debug</tt></p>
2049
<p>If <tt class="literal">yes</tt>, sends debug logs of the password-change
2050
process to the log files with a level of 100.</p>
2053
<p><tt class="literal">no</tt></p>
2061
<p><tt class="literal">passwd program</tt></p>
2064
<p>string (Unix command)</p>
2067
<p>Program to be used to change passwords.</p>
2070
<p><tt class="literal">/bin/passwd</tt> <tt class="literal">%u</tt></p>
2078
<p><tt class="literal">password level</tt></p>
2084
<p>Number of capital-letter permutations to attempt when matching a
2085
client's password.</p>
2096
<p><tt class="literal">update</tt> <tt class="literal">encrypted</tt></p>
2102
<p>If <tt class="literal">yes</tt>, updates the encrypted password file when a
2103
client connects to a share with a plain-text password.</p>
2106
<p><tt class="literal">no</tt></p>
2114
<p><tt class="literal">null passwords</tt></p>
2120
<p>If <tt class="literal">yes</tt>, allows access for users with null
2124
<p><tt class="literal">no</tt></p>
2132
<p><tt class="literal">smb passwd file</tt></p>
2135
<p>string (filename)</p>
2138
<p>Name of the encrypted password file.</p>
2141
<p><tt class="literal">/usr/local/samba/private/smbpasswd</tt></p>
2149
<p><tt class="literal">hosts equiv</tt></p>
2152
<p>string (filename)</p>
2155
<p>Name of a file that contains hosts and users that can connect without
2156
using a password.</p>
2167
<p><tt class="literal">use rhosts</tt></p>
2170
<p>string (filename)</p>
2173
<p>Name of a .<em class="emphasis">rhosts</em> file that allows users to
2174
connect without using a password.</p>
2187
<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.1"/>
2189
<h3 class="head3">encrypt passwords</h3>
2191
<p>The <tt class="literal">encrypt</tt><a name="INDEX-83"/>
2192
<tt class="literal">passwords</tt> global option switches Samba from using
2193
plain-text passwords to encrypted passwords for authentication.
2194
Encrypted passwords will be expected from clients if the option is
2195
set to <tt class="literal">yes</tt>:</p>
2197
<blockquote><pre class="code">encrypt passwords = yes</pre></blockquote>
2199
<p>In Samba 2.2.x versions and with previous versions, encrypted
2200
passwords are disabled by default. This was changed in Samba 3.0 to
2201
make encrypted passwords enabled by default.</p>
2203
<p>If you use encrypted passwords, you must have a valid
2204
<em class="filename">smbpasswd</em> file in place and populated with
2205
usernames that authenticate with encrypted passwords. (See <a href="ch09.html#samba2-CHP-9-SECT-4.2">Section 9.4.2</a> earlier in
2206
this chapter.) In addition, Samba must know the location of the
2207
<em class="filename">smbpasswd</em> file; if it is not in the default
2209
<em class="filename">/usr/local/samba/private/smbpasswd</em> ), you can
2210
explicitly name it using the <tt class="literal">smb</tt>
2211
<tt class="literal">passwd</tt> <tt class="literal">file</tt> option.</p>
2213
<p>If you wish, you can use <tt class="literal">update</tt>
2214
<tt class="literal">encrypted</tt> to force Samba to update the
2215
<em class="filename">smbpasswd</em> file with encrypted passwords each
2216
time a client connects using a nonencrypted password.</p>
2218
<p>If you have a mixture of clients on your network, with some of them
2219
using encrypted passwords and others using plain-text passwords, you
2220
can use the <tt class="literal">include</tt> option to make Samba treat
2221
each client appropriately. To do this, create individual
2222
configuration files based on the client name (<tt class="literal">%m</tt>).
2223
These host-specific configuration files can contain an
2224
<tt class="literal">encrypted</tt> <tt class="literal">passwords</tt>
2225
<tt class="literal">=</tt> <tt class="literal">yes</tt> option that activates
2226
only when those clients are connecting to the server.</p>
2233
<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.2"/>
2235
<a name="INDEX-84"/><h3 class="head3">unix password sync</h3>
2237
<p>The <tt class="literal">unix</tt> <tt class="literal">password</tt>
2238
<tt class="literal">sync</tt> global option allows Samba to update the
2239
standard Unix password file when a user changes her encrypted
2240
password. The encrypted password is stored on a Samba server in the
2241
<em class="filename">smbpasswd</em> file, which is located by default in
2242
<em class="filename">/usr/local/samba/private</em>. You can activate this
2243
feature as follows:</p>
2245
<blockquote><pre class="code">[global]
2246
unix password sync = yes</pre></blockquote>
2248
<p>If this option is enabled, Samba changes the encrypted password and,
2249
in addition, attempts to change the standard Unix password by passing
2250
the username and new password to the program specified by the
2251
<tt class="literal">passwd</tt> <tt class="literal">program</tt> option
2252
(described earlier). Note that Samba does not necessarily have access
2253
to the plain-text password for this user, so the password changing
2254
program must be invoked as <tt class="literal">root</tt>.<a name="FNPTR-2"/><a href="#FOOTNOTE-2">[2]</a> If the Unix password change does not
2255
succeed, for whatever reason, the SMB password is not changed either.</p>
2262
<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.3"/>
2264
<a name="INDEX-85"/><h3 class="head3">passwd chat</h3>
2266
<p>This option specifies a series of send/response strings similar to a
2267
Unix chat script, which interface with the password-changing program
2268
on the Samba server. <a href="ch09.html#samba2-CHP-9-SECT-4.3">Section 9.4.3</a> earlier in this
2269
chapter covers this option in detail.</p>
2276
<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.4"/>
2278
<h3 class="head3">passwd chat debug</h3>
2280
<p>If set to <tt class="literal">yes</tt>, the
2281
<tt class="literal">passwd</tt><a name="INDEX-86"/> <tt class="literal">chat</tt>
2282
<tt class="literal">debug</tt> global option logs everything sent or
2283
received by Samba during a password chat. All the I/O received by
2284
Samba through the password chat is sent to the Samba logs with a
2285
debug level of 100; you must specify <tt class="literal">log</tt>
2286
<tt class="literal">level</tt> <tt class="literal">=</tt> <tt class="literal">100</tt>
2287
for the information to be recorded. <a href="ch09.html#samba2-CHP-9-SECT-4.3">Section 9.4.3</a> earlier in this
2288
chapter describes this option in more detail. Be aware that if you do
2289
set this option, the plain-text passwords will be visible in the
2290
debugging logs, which could be a security hazard if they are not
2291
properly secured. It is against the security policy of some
2292
organizations for system administrators to have access to
2293
users' passwords.</p>
2300
<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.5"/>
2302
<h3 class="head3">passwd program</h3>
2304
<p>The <tt class="literal">passwd</tt><a name="INDEX-87"/>
2305
<tt class="literal">program</tt> option specifies a program on the Unix
2306
Samba server that Samba can use to update the standard system
2307
password file when the encrypted password file is updated. This
2308
option defaults to the standard <em class="emphasis">passwd</em> program,
2309
usually located in the <em class="filename">/bin</em> directory. The
2310
<tt class="literal">%u</tt> variable is typically used as the requesting
2311
user when the command is executed. The actual handling of input and
2312
output to this program during execution is handled through the
2313
<tt class="literal">passwd</tt> <tt class="literal">chat</tt> option. <a href="ch09.html#samba2-CHP-9-SECT-4.3">Section 9.4.3</a> earlier in this
2314
chapter covers this option in detail.</p>
2321
<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.6"/>
2323
<a name="INDEX-88"/><h3 class="head3">password level</h3>
2325
<p>With SMB, nonencrypted (or plain-text) passwords are sent with
2326
capital letters, just like the usernames mentioned previously. Many
2327
Unix users, however, choose passwords with both upper- and lowercase
2328
letters. Samba, by default, only attempts to match the password
2329
entirely in lowercase letters and not capitalizing the first letter.</p>
2331
<p>Like <tt class="literal">username</tt> <tt class="literal">level</tt>, a
2332
<tt class="literal">password</tt> <tt class="literal">level</tt> option can be
2333
used to attempt various permutations of the password with capital
2334
letters. This option takes an integer value that specifies how many
2335
letters in the password should be capitalized when attempting to
2336
connect to a share. You can specify this option as follows:</p>
2338
<blockquote><pre class="code">[global]
2339
password level = 3</pre></blockquote>
2341
<p>In this case, Samba then attempts all permutations of the password it
2342
can compute having three capital letters. The larger the number, the
2343
more computations Samba has to perform to match the password, and the
2344
longer a connection to a specific share might take.</p>
2351
<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.7"/>
2353
<a name="INDEX-89"/><h3 class="head3">update encrypted</h3>
2355
<p>For sites switching over to the encrypted password format, Samba
2356
provides an option that should help with the transition. The
2357
<tt class="literal">update</tt> <tt class="literal">encrypted</tt> option allows
2358
a site to ease into using encrypted passwords from plain-text
2359
passwords. You can activate this option as follows:</p>
2361
<blockquote><pre class="code">[global]
2362
update encrypted = yes</pre></blockquote>
2364
<p>This instructs Samba to create an encrypted version of each
2365
user's Unix password in the
2366
<em class="filename">smbpasswd</em> file each time she connects to a
2367
share. When this option is enabled, you must have the
2368
<tt class="literal">encrypt</tt> <tt class="literal">passwords</tt> option set to
2369
<tt class="literal">no</tt> so that the client passes plain-text passwords
2370
to Samba to update the files. Once each user has connected at least
2371
once, you can set <tt class="literal">encrypted</tt>
2372
<tt class="literal">passwords</tt> <tt class="literal">=</tt>
2373
<tt class="literal">yes</tt>, allowing you to use only the encrypted
2374
passwords. The user must already have a valid entry in the
2375
<em class="filename">smbpasswd</em> file for this option to work.</p>
2382
<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.8"/>
2384
<a name="INDEX-90"/><h3 class="head3">null passwords</h3>
2386
<p>This global option tells Samba whether to allow access from users
2387
that have null passwords (encrypted or nonencrypted) set in their
2388
accounts. The default value is <tt class="literal">no</tt>. You can
2389
override it as follows:</p>
2391
<blockquote><pre class="code">null passwords = yes</pre></blockquote>
2393
<p>We highly recommend against doing so because of the security risks
2394
this option can present to your system, including inadvertent access
2395
to system users (such as <tt class="literal">bin</tt>) in the system
2396
password file who have null passwords set.</p>
2403
<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.9"/>
2405
<a name="INDEX-91"/><h3 class="head3">smb passwd file</h3>
2407
<p>This global option identifies the location of the encrypted password
2408
database. By default, it is set to
2409
<em class="filename">/usr/local/samba/private/smbpasswd</em>. You can
2410
override it as follows:</p>
2412
<blockquote><pre class="code">[global]
2413
smb passwd file = /etc/samba/smbpasswd</pre></blockquote>
2415
<p>This location, for example, is common on many Red Hat distributions
2416
on which Samba has been installed using an RPM package.</p>
2423
<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.10"/>
2425
<a name="INDEX-92"/><h3 class="head3">hosts equiv</h3>
2427
<p>This global option specifies the name of a standard Unix
2428
<em class="filename">hosts.equiv</em> file that allows hosts or users to
2429
access shares without specifying a password. You can specify the
2430
location of such a file as follows:</p>
2432
<blockquote><pre class="code">[global]
2433
hosts equiv = /etc/hosts.equiv</pre></blockquote>
2435
<p>The default value for this option does not specify any
2436
<em class="filename">hosts.equiv</em> file. Because using a
2437
<em class="filename">hosts.equiv</em> file is a huge security risk, we
2438
strongly recommend against using this option.</p>
2445
<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.11"/>
2447
<a name="INDEX-93"/><h3 class="head3">use rhosts</h3>
2449
<p>This global option specifies the name of a standard Unix
2450
user's <em class="filename">.rhosts</em> file that allows
2451
foreign hosts to access shares without specifying a password. You can
2452
specify the location of such a file as follows:</p>
2454
<blockquote><pre class="code">[global]
2455
use rhosts = /home/dave/.rhosts</pre></blockquote>
2457
<p>The default value for this option does not specify any
2458
<em class="filename">.rhosts</em> file. Like the <tt class="literal">hosts</tt>
2459
<tt class="literal">equiv</tt> option discussed earlier, using such a file
2460
is a security risk. We highly recommend that you do not use this
2461
option unless you are confident in the security of your network.
2462
<a name="INDEX-94"/>
2463
<a name="INDEX-95"/><a name="INDEX-96"/></p>
2476
<div class="sect1"><a name="samba2-CHP-9-SECT-5"/>
2478
<h2 class="head1">Authentication with winbind</h2>
2480
<p><a name="INDEX-97"/><a name="INDEX-98"/>In <a href="ch03.html">Chapter 3</a>, we
2481
showed you how to add Windows clients to a network in which user
2482
accounts were maintained on the Samba server. We added a user account
2483
to the Windows client using the same username and password as an
2484
account on the Unix system. This method works well in many computing
2485
environments. However, if a Samba server is added to a Windows
2486
network that already has a Windows NT/2000 primary domain controller,
2487
the PDC has a preexisting database of user accounts and group
2488
information that is used for authentication. It can be a big chore to
2489
transfer that database manually to the Unix server, and later
2490
maintain and synchronize the Unix and Windows databases.</p>
2492
<p>In <a href="ch04.html">Chapter 4</a>, we showed you how to add a Samba
2493
server as a domain member server to a network having a Windows
2494
NT/2000 primary domain controller. We set <tt class="literal">security</tt>
2495
<tt class="literal">=</tt> <tt class="literal">domain</tt> in the Samba
2496
configuration file to have the Samba server hand off authentication
2497
to the Windows PDC. Using that method, passwords are kept only on the
2498
PDC, but it is still necessary to set up user accounts on the Unix
2499
side to make sure each client has a valid Unix UID and group ID
2500
(GID). This is necessary for maintaining the file ownerships and
2501
permissions of the Unix security model. Whenever Samba performs an
2502
operation on the Unix filesystem on behalf of the Windows client, the
2503
user must have a valid UID and GID on the local Unix system.</p>
2505
<p>A facility that has recently been added to Samba, winbind, allows the
2506
Windows <a name="INDEX-99"/>PDC to handle
2507
not only authentication, but the user and group information as well.
2508
Winbind works by extending the Unix user and group databases beyond
2509
the standard <em class="filename">/etc/passwd</em> and
2510
<em class="filename">/etc/group</em> files such that users and groups on
2511
the Windows PDC also exist as valid users and groups on the Unix
2512
system. The extension applies to the entire Unix system and allows
2513
users who are members of a Windows domain to perform any action on
2514
the Unix system that a local user would, including logging in to the
2515
Unix system by <em class="emphasis">telnet</em> or even on the local
2516
system, using their domain usernames and passwords.</p>
2518
<p>When winbind is in use, administration of user accounts can be done
2519
on the Windows PDC, without having to repeat the tasks on the Unix
2520
side. This includes password expiration and allowing users to change
2521
their passwords, which would otherwise not be practical. Aside from
2522
simplifying domain administration and being a great time saver,
2523
winbind lets Samba be used in computing environments where it
2524
otherwise might not be allowed.</p>
2525
<a name="samba2-CHP-9-NOTE-143"/><blockquote class="note"><h4 class="objtitle">WARNING</h4>
2526
<p>Because this is a chapter on security, we want to point out that some
2527
issues might relate to allowing a Windows system to authenticate
2528
users accessing a Unix system! Whatever you might think of the
2529
relative merits of Unix and Windows security models (and even more
2530
importantly, their <em class="emphasis">implementations</em>), one thing
2531
is certain: adding winbind support to your Samba server greatly
2532
complicates the authentication system overall—and quite
2533
possibly allows more opportunities for crackers.</p>
2535
<p>We present winbind in this chapter not as a means of improving
2536
security, but rather as a further example of Samba's
2537
ability to integrate itself into a modern Windows environment.</p>
2541
<div class="sect2"><a name="samba2-CHP-9-SECT-5.1"/>
2543
<h3 class="head2">Installing winbind</h3>
2545
<p><a name="INDEX-100"/>Installing
2546
and configuring winbind is fairly complicated and involves the
2547
following steps:</p>
2550
<p>Reconfigure, recompile, and reinstall Samba—to add support for
2553
<p>Configure the Unix name server switch.</p>
2555
<p>Modify the Samba configuration file.</p>
2557
<p>Start and test the <em class="emphasis">winbindd</em> daemon.</p>
2559
<p>Configure the system to start and stop the
2560
<em class="emphasis">winbindd</em> daemon automatically.</p>
2562
<p>Optionally, configure PAM for use with winbind.</p>
2564
<p>At the time this book was written, winbind was supported only on
2565
Linux, so all of the following directions are specific to it. Other
2566
Unix flavors might be supported at a later time. In addition, we
2567
assume you have a Windows NT/2000 primary domain controller running
2568
on your network.</p>
2570
<p>First, you will need to configure and compile Samba using the
2571
<tt class="literal">--with-winbind</tt> configure option. Directions for
2572
doing this are included in <a href="ch02.html">Chapter 2</a> in <a href="ch02.html#samba2-CHP-2-SECT-3">Section 2.3</a>. As usual, run
2573
<em class="emphasis">make install</em> to reinstall the Samba binaries.</p>
2579
<div class="sect2"><a name="samba2-CHP-9-SECT-5.2"/>
2581
<h3 class="head2">Configuring nsswitch</h3>
2583
<p><a name="INDEX-101"/>When
2584
Samba is compiled after being configured with the
2585
<tt class="literal">--with-winbind</tt> option, the compilation process
2586
produces a library called
2587
<em class="filename">libnss_winbind.so</em><a name="INDEX-102"/> in the
2588
<em class="filename">source/nsswitch</em> directory. This library needs to
2589
be copied to the <em class="filename">/lib</em> directory:</p>
2591
<blockquote><pre class="code"># <tt class="userinput"><b>cp nsswitch/libnss_winbind.so /lib</b></tt></pre></blockquote>
2593
<p>Also, a symbolic link must be created for winbind to be fully
2596
<blockquote><pre class="code"># <tt class="userinput"><b>ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2</b></tt></pre></blockquote>
2598
<a name="samba2-CHP-9-NOTE-144"/><blockquote class="note"><h4 class="objtitle">TIP</h4>
2599
<p>The name of this symbolic link is correct for Samba 2.2.3 and Red Hat
2600
7.1. The name might change—with a higher version number in the
2601
extension—in future releases. See the
2602
<em class="emphasis">winbindd</em> manual page for details.</p>
2605
<p>Next, we need to modify <em class="filename">/etc/nsswitch.conf</em> to
2606
make the lines for <tt class="literal">passwd</tt> and
2607
<tt class="literal">group</tt> look like this:</p>
2609
<blockquote><pre class="code">passwd: files winbind
2610
group: files winbind</pre></blockquote>
2612
<p>Then activate these changes by issuing the following command:</p>
2614
<blockquote><pre class="code"># <tt class="userinput"><b>/sbin/ldconfig</b></tt></pre></blockquote>
2616
<p>What we've just done is reconfigure the Linux name
2617
service switch, which allows name service and other tasks to be
2618
configured to use the traditional method (files in the
2619
<em class="filename">/etc</em> directory) or an extension coded in a
2620
library, such as the <em class="filename">libnss_winbind.so</em> library
2621
we've just installed. We've
2622
specified in our configuration that Samba will search for user and
2623
group information first in the <em class="filename">/etc/passwd</em> and
2624
<em class="filename">/etc/group files</em>, and if they are not found
2625
there, in the winbind service.</p>
2631
<div class="sect2"><a name="samba2-CHP-9-SECT-5.3"/>
2633
<h3 class="head2">Modifying smb.conf</h3>
2635
<p><a name="INDEX-103"/><a name="INDEX-104"/>To use winbind, we must have our Samba
2636
server added to the Windows NT domain as a domain member server (as
2637
we described in <a href="ch04.html">Chapter 4</a>) and also add some
2638
parameters to the Samba configuration file to configure winbind. In
2639
addition to the options required to configure Samba as a domain
2640
member server, we need:</p>
2642
<blockquote><pre class="code">[global]
2643
winbind uid = 10000-20000
2644
winbind gid = 10000-20000</pre></blockquote>
2646
<p>The <tt class="literal">winbind</tt> <tt class="literal">uid</tt> and
2647
<tt class="literal">winbind</tt> <tt class="literal">gid</tt> options tell
2648
winbind how to map between Windows relative identifiers (RIDs) and
2649
Unix UIDs and GIDs. Windows uses RIDs to identify users and groups
2650
within the domain, and to function, the Unix system must have a UID
2651
and GID associated with every user and group RID that is received
2652
from the Windows primary domain controller. The
2653
<tt class="literal">winbind</tt> <tt class="literal">uid</tt> and
2654
<tt class="literal">winbind</tt> <tt class="literal">gid</tt> parameters simply
2655
provide winbind with a range of UIDs and GIDs, respectively, that are
2656
allocated by the system administrator for Windows NT domain users and
2657
groups. You can use whatever range you want for each; just make sure
2658
the lowest number in the range does not conflict with any entries in
2659
your <em class="filename">/etc/passwd</em> or
2660
<em class="filename">/etc/group</em> files at any time, either now or in
2661
the future. It is important to be conservative about this. Once
2662
winbind adds an RID to UID/GID mapping to its database, it is very
2663
difficult to modify the mapping.</p>
2664
<a name="samba2-CHP-9-NOTE-145"/><blockquote class="note"><h4 class="objtitle">WARNING</h4>
2665
<p><a name="INDEX-105"/>The file
2666
<em class="filename">/usr/local/samba/locks/winbindd_idmap.tdb</em>
2667
contains winbind's RID mapping file by default. We
2668
suggest you regard this file as extremely sensitive and make sure to
2669
guard it carefully against any kind of harm or loss. If you lose it,
2670
you will have to re-create it manually, which can be a very
2671
labor-intensive task.</p>
2674
<a name="samba2-CHP-9-NOTE-145a"/><blockquote class="note"><h4 class="objtitle">WARNING</h4>
2675
<p>Be careful when adding local users after domain users have started
2676
accessing the Samba server. The domain users will have entries
2677
created for them by winbind in <em class="filename">/etc/passwd,</em> with
2678
UIDs in the range you specify. If you are using a method of creating
2679
new accounts that automatically assigns UIDs, it might choose UIDs by
2680
adding 1 to the highest UID assigned thus far, which will be the most
2681
recent UID added by winbind. (This is the case on Red Hat Linux, with
2682
the <em class="emphasis">useradd</em> script, for example.) The UID for
2683
the new local user will be within the range allocated for winbind,
2684
which will have undesired effects. Make sure to add new local users
2685
using a method that assigns them UIDs in the proper range. For
2686
example, you can use the <em class="emphasis">-u</em> option of
2687
<em class="emphasis">useradd</em> to specify the UID to assign to the new
2691
<p>Restart the Samba daemons to put your changes to the configuration
2692
file into effect. If you have not already done so while adding your
2693
Samba server as a domain member server, you must issue the command:</p>
2695
<blockquote><pre class="code"># <tt class="userinput"><b>smbpasswd -j </b></tt><em class="replaceable">domain</em><tt class="userinput"><b> -r </b></tt><em class="replaceable">pdc</em><tt class="userinput"><b> -U Administrator</b></tt></pre></blockquote>
2697
<p>as we described in <a href="ch04.html">Chapter 4</a>. At this point, you
2698
can start the <em class="emphasis">winbindd</em> daemon:</p>
2700
<blockquote><pre class="code"># <tt class="userinput"><b>winbindd</b></tt></pre></blockquote>
2702
<p><a name="INDEX-106"/>You might want to
2703
run a <em class="emphasis">ps ax</em> command to see that the
2704
<em class="emphasis">winbindd</em> daemon is running. Now, to make sure
2705
everything we've done up to this point works, we can
2706
use Samba's <em class="emphasis">wbinfo</em> command:</p>
2708
<blockquote><pre class="code">$ <tt class="userinput"><b>wbinfo -u</b></tt>
2709
METRAN\Administrator
2714
$ <tt class="userinput"><b>wbinfo -g</b></tt>
2715
METRAN\Domain Admins
2716
METRAN\Domain Guests
2717
METRAN\Domain Users</pre></blockquote>
2719
<p>The <em class="emphasis">-u</em> option queries the domain controller for
2720
a list of domain users, and the <em class="emphasis">-g</em> option asks
2721
for the list of groups. The output shows that the Samba host system
2722
can query the Windows PDC through winbind.</p>
2724
<p>Another thing to check is the list of users and groups, using the
2725
<em class="emphasis">getent</em> command:</p>
2727
<blockquote><pre class="code"># <tt class="userinput"><b>getent passwd</b></tt>
2728
root:x:0:0:root:/root:/bin/bash
2730
daemon:x:2:2:daemon:/sbin:
2731
<i class="lineannotation">... deleted ...</i>
2732
jay:x:500:500:Jay Ts:/home/jay:/bin/bash
2733
rik:x:501:501::/home/rik:/bin/bash
2734
METRAN\Administrator:x:10000:10000::/home/METRAN/administrator:/bin/bash
2735
METRAN\bebe:x:10001:10000:Bebe Larta:/home/METRAN/bebe:/bin/bash
2736
METRAN\Guest:x:10002:10000::/home/METRAN/guest:/bin/bash
2737
METRAN\jay:x:10003:10000:Jay Ts:/home/METRAN/jay:/bin/bash
2738
METRAN\linda:x:10004:10000:Linda Lewis:/home/METRAN/linda:/bin/bash
2742
bin:x:1:root,bin,daemon
2743
daemon:x:2:root,bin,daemon
2744
<i class="lineannotation">... deleted ...</i>
2747
METRAN\Domain Admins:x:10001:METRAN\Administrator
2748
METRAN\Domain Guests:x:10002:METRAN\Guest
2749
METRAN\Domain Users:x:10000:METRAN\Administrator,METRAN\jay,METRAN\linda,METRAN\bebe</pre></blockquote>
2751
<p>This shows that the Linux system is finding the domain users and
2752
groups through winbind, in addition to those in the
2753
<em class="filename">/etc/passwd</em> and <em class="filename">/etc/group</em>
2754
files. If this part doesn't work as shown earlier,
2755
with the domain users and groups listed after the local ones, check
2756
to make sure you made the symbolic link to
2757
<em class="filename">libnss_winbind.so</em> in <em class="filename">/lib</em>
2760
<p>Now you can try connecting to a Samba share from a Windows system
2761
using a domain account. You can either log on to the domain from a
2762
Windows NT/2000/XP workstation or use <em class="emphasis">smbclient</em>
2763
with the <em class="emphasis">-U</em> option to specify a username.</p>
2765
<a name="samba2-CHP-9-NOTE-147"/><blockquote class="note"><h4 class="objtitle">NOTE</h4>
2766
<p>If you get errors while attempting to log on to the domain, it is
2767
probably because you had previously configured the client system with
2768
a computer account on another domain controller. Commonly, you get a
2769
dialog box that says, "The domain
2770
<em class="replaceable">NAME</em> is not available."
2771
On a Windows 2000 system, the fix is to log in to the system as an
2772
administrative user and open the Control Panel, double-click the
2773
System icon, click the Network Identification tab, then click the
2774
Properties button. In the dialog that comes up, click the
2775
"Workgroup:" radio button and fill
2776
in the name of the workgroup (you can use the same name as the
2777
domain). Click the OK buttons in the dialogs, and reboot if
2780
<p>This removes the computer account from the primary domain controller.
2781
Now log in again as the administrative user and repeat the previous
2782
directions, but change from the workgroup back to the domain. This
2783
creates a new computer account that
2784
"fits" the workstation to the new
2785
primary domain controller. If your network has backup domain
2786
controllers, it will take up to 15 minutes for the new computer
2787
account to propagate to the BDCs.</p>
2789
<p>If you are using Windows NT/XP, the method is slightly different. For
2790
the exact procedure, see the section in <a href="ch04.html">Chapter 4</a>
2791
that is specific to your Windows version.</p>
2794
<p>After logging in as a domain user, try creating a file or two in a
2795
Samba share. (You might need to change the permissions on the shared
2796
directory—say, to 777—to allow this access. This is very
2797
permissive, but after you finish reading this section, you will
2798
understand how to change ownership and permissions on the directory
2799
to restrict access to selected domain users.) After
2800
you've created files by one or more domain users,
2801
take a look at the directory's contents from a Linux
2802
shell. You will see something like this:</p>
2804
<blockquote><pre class="code">$ <tt class="userinput"><b>ls -l /u</b></tt>
2805
-rwxrw-rw- 1 METRAN\b METRAN\D 0 Apr 13 00:00 bebes-file.doc
2806
-rwxrw-rw- 1 METRAN\l METRAN\D 0 Apr 12 23:58 lindas-file.doc
2807
drwxrwxr-x 6 jay jay 4096 Jan 15 05:12 snd
2808
<b class="emphasis-bold">$ ls -ln /u</b>
2810
-rwxrw-rw- 1 10001 10000 0 Apr 13 00:00 bebes-file.doc
2811
-rwxrw-rw- 1 10004 10000 0 Apr 12 23:58 lindas-file.doc
2812
drwxrwxr-x 6 500 500 4096 Jan 15 05:12 snd</pre></blockquote>
2814
<p>We can even use the domain usernames and groups from the Linux shell:</p>
2816
<blockquote><pre class="code"># <tt class="userinput"><b>chown 'METRAN\linda:METRAN\Domain Users' /u</b></tt>
2817
# <tt class="userinput"><b>ls -ldu /u</b></tt>
2818
drwxrwxrwx 3 METRAN\l METRAN\D 4096 Apr 13 00:44 /u
2819
# <tt class="userinput"><b>ls -ldn /u</b></tt>
2820
drwxrwxrwx 3 10004 10000 4096 Apr 13 00:00 /u</pre></blockquote>
2822
<p>Notice how the owner and group are listed as being those of the
2823
domain user and group. Unfortunately, the GNU <em class="emphasis">ls</em>
2824
command won't show the full names of the domain
2825
users and groups, but we can use the <em class="emphasis">-ln</em> listing
2826
to show the UIDs and GIDs and then translate with the
2827
<em class="emphasis">wbinfo</em> command:</p>
2829
<blockquote><pre class="code">$ <tt class="userinput"><b>wbinfo -s `wbinfo -U 10004`</b></tt>
2831
$ <tt class="userinput"><b>wbinfo -s `wbinfo -G 10000`</b></tt>
2832
METRAN\Domain Users 2</pre></blockquote>
2834
<p>(It's a bit messy, but it works, and it shows that
2835
the winbind system is working!) At this point, you might want to
2836
modify your <em class="filename">/etc/rc.d/init.d/smb</em> script to start
2837
and stop the <em class="emphasis">winbindd</em> daemon automatically along
2838
with the <em class="emphasis">smbd</em> and <em class="emphasis">nmbd</em>
2839
daemons. Starting with the script we presented in <a href="ch02.html">Chapter 2</a>, we first add this code to the
2840
<em class="emphasis">start( )</em> function:</p>
2842
<blockquote><pre class="code">echo -n $"Starting WINBIND services: "
2843
/usr/local/samba/bin/winbindd
2845
if [ $ERROR2 -ne 0 ]
2849
echo</pre></blockquote>
2851
<p>The previous code should be located after the code that starts
2852
<em class="emphasis">nmbd</em> and before the <em class="emphasis">return</em>
2855
<a name="samba2-CHP-9-NOTE-148"/><blockquote class="note"><h4 class="objtitle">TIP</h4>
2856
<p>We start <em class="emphasis">winbindd</em> after
2857
<em class="emphasis">nmbd</em> because <em class="emphasis">winbindd</em> needs
2858
<em class="emphasis">nmbd</em> to be running to work properly.</p>
2861
<p>In the <tt class="function">stop( )</tt> function, we add the following:</p>
2863
<blockquote><pre class="code">echo -n $"Shutting down WINBIND services: "
2864
/bin/kill -TERM -a winbindd
2866
if [ $ERROR2 -ne 0 ]
2870
echo</pre></blockquote>
2872
<p>Again, this code should be located after the code that stops
2873
<em class="emphasis">nmbd</em> and before the <em class="emphasis">return</em>
2874
statement. <a name="INDEX-107"/></p>
2880
<div class="sect2"><a name="samba2-CHP-9-SECT-5.4"/>
2882
<h3 class="head2">Configuring PAM</h3>
2884
<p><a name="INDEX-108"/>Most
2885
popular Linux distributions use <a name="INDEX-109"/>Pluggable
2886
Authentication Modules (PAM), a suite of shared libraries that
2887
provide a centralized source of authentication for applications
2888
running on the Unix system. PAM can be configured differently for
2889
each application (or service) that uses it, without needing to
2890
recompile the application. As a hypothetical example, if an
2891
organization's security policy mandated the use of
2892
passwords exactly 10 characters in length, a PAM module could be
2893
written to check the length of passwords submitted by users and
2894
reject any attempts to use a longer or shorter password. PAM would
2895
then be reconfigured to include the new module for services such as
2896
<em class="emphasis">ftp</em>, console login, and GUI login that call upon
2897
PAM to authenticate users.</p>
2899
<p>If you are not already familiar with PAM, we suggest you read the
2900
documentation provided with the Linux PAM package before continuing.
2901
On most Linux systems, it is located in the
2902
<em class="filename">/usr/share/doc</em> directory hierarchy. Another
2903
resource is the <em class="citetitle">Linux-PAM System
2905
Guide</em><a name="INDEX-110"/>, which you can find
2906
on the Internet at <a href="http://www.kernel.org/pub/linux/libs/pam">http://www.kernel.org/pub/linux/libs/pam</a>.</p>
2908
<p>The rest of this section is about using the PAM module provided in
2909
the Samba distribution to enable Windows domain users to authenticate
2910
on the Linux system hosting Samba. Depending on which services you
2911
choose to configure, this allows Windows domain users to log in on a
2912
local console (or through <em class="emphasis">telnet</em>), log in to a
2913
GUI desktop on the Linux system, authenticate with an FTP server
2914
running on the Linux system, or use other services normally limited
2915
to users who have an account on the Linux system. The PAM module
2916
authenticates Windows domain users by querying winbind, which passes
2917
the authentication off to a Windows NT domain controller.</p>
2919
<p>As an example, we will show how to allow Windows domain users to log
2920
in to a text console on the Linux system and get a command shell and
2921
home directory. The method used in our example can be applied (with
2922
variations) to other services.</p>
2924
<p>All users who can log in to the Linux system need a shell and a home
2925
directory. Unix and Linux keep this user information in the password
2926
file (<em class="filename">/etc/passwd</em> ), but information about
2927
Windows users isn't located there. Instead, in the
2928
Samba configuration file, we add the following to notify winbind what
2929
the shell and home directory for Windows domain users will be:</p>
2931
<blockquote><pre class="code">[global]
2932
template shell = /bin/bash
2933
template homedir = /home/%D/%U</pre></blockquote>
2935
<p>The first line sets the
2936
<tt class="literal">template</tt><a name="INDEX-111"/> <tt class="literal">shell</tt>
2937
parameter, which tells winbind what shell to use for domain users
2938
that are logging in to the Unix host. The
2939
<tt class="literal">template</tt><a name="INDEX-112"/>
2940
<tt class="literal">homedir</tt> parameter specifies the location of
2941
users' home directories. The <tt class="literal">%D</tt>
2942
variable is replaced by the name of the domain in which the
2943
user's account resides, and <tt class="literal">%U</tt> is
2944
replaced by the user's username in that domain.</p>
2946
<p>Before the domain users can successfully log in, their home
2947
directories must be created manually. To add a single account for
2948
<tt class="literal">linda</tt> in the METRAN domain, we would use these
2951
<blockquote><pre class="code"># <tt class="userinput"><b>mkdir /home/METRAN</b></tt>
2952
# <tt class="userinput"><b>chmod 755 /home/METRAN</b></tt>
2954
# <tt class="userinput"><b>mkdir /home/METRAN/linda</b></tt>
2955
# <tt class="userinput"><b>chown 'METRAN\linda:METRAN\Domain Users' /home/METRAN/linda</b></tt>
2956
# <tt class="userinput"><b>chmod 700 /home/METRAN/linda</b></tt></pre></blockquote>
2957
<a name="samba2-CHP-9-NOTE-149"/><blockquote class="note"><h4 class="objtitle">WARNING</h4>
2958
<p>One side effect of creating the home directories is that if the Samba
2959
server is configured with a <tt class="literal">[homes]</tt> share, the
2960
domain users can see and access their home directories through
2961
Samba's file sharing.</p>
2964
<p>Next, we need to compile and install the PAM module in the Samba
2965
distribution. From the source directory in the Samba distribution,
2966
issue the following commands:</p>
2968
<blockquote><pre class="code"># <tt class="userinput"><b>make nsswitch/pam_winbind.so</b></tt>
2969
# <tt class="userinput"><b>cp nsswitch/pam_winbind.so /lib/security</b></tt></pre></blockquote>
2971
<p>and check that it was copied over correctly:</p>
2973
<blockquote><pre class="code"># <tt class="userinput"><b>ls /lib/security/pam_winbind.so</b></tt>
2974
/lib/security/pam_winbind.so</pre></blockquote>
2976
<p>On Red Hat Linux, the PAM configuration files reside in
2977
<em class="filename">/etc/pam.d</em>. Before making any modifications, we
2978
strongly advise making a backup of this directory:</p>
2980
<blockquote><pre class="code"># cp -pR /etc/pam.d /etc/pam.d.backup</pre></blockquote>
2982
<p>The reason for this is that we will be modifying the Linux
2983
system's means of authenticating logins, and if our
2984
configuration goes awry, all users (including
2985
<tt class="literal">root</tt>) will be locked out of the system. In case
2986
the worst happens, we would reboot into single-user mode (by typing
2987
<tt class="literal">linux</tt> <tt class="literal">single</tt> at the LILO:
2988
prompt) or boot a rescue disk, and then we would issue these two
2991
<blockquote><pre class="code"># <tt class="userinput"><b>mv /etc/pam.d /etc/pam.d.bad</b></tt>
2992
# <tt class="userinput"><b>mv /etc/pam.d.backup /etc/pam.d</b></tt></pre></blockquote>
2994
<p>Be very careful to make sure you can recover from any errors you make
2995
because when PAM encounters any configuration information it
2996
doesn't understand, its action is not to allow
2997
access. This means you must be sure to enter everything correctly!
2998
You might want to leave yourself logged in as root on a spare virtual
2999
terminal while you are modifying your PAM configuration to ensure
3000
yourself a means of easy recovery.</p>
3002
<p>In the <em class="filename">/etc/pam.d</em> directory, you will encounter
3003
a file for each service that uses PAM. We are interested only in the
3004
file corresponding to the login service, which is called
3005
<em class="filename">login</em>. It contains the following lines:</p>
3007
<blockquote><pre class="code">auth required /lib/security/pam_securetty.so
3008
auth required /lib/security/pam_stack.so service=system-auth
3009
auth required /lib/security/pam_nologin.so
3010
account required /lib/security/pam_stack.so service=system-auth
3011
password required /lib/security/pam_stack.so service=system-auth
3012
session required /lib/security/pam_stack.so service=system-auth
3013
session optional /lib/security/pam_console.so</pre></blockquote>
3015
<p>The lines starting with <tt class="literal">auth</tt> are related to the
3016
function of authentication—that is, printing a password prompt,
3017
accepting the password, verifying that it is correct, and matching
3018
the user to a valid user and group ID. The line starting with
3019
<tt class="literal">account</tt> is for account management, which allows
3020
access to be controlled by other factors, such as what times during
3021
the day a user is allowed access. We are not concerned with the lines
3022
starting with <tt class="literal">password</tt> or
3023
<tt class="literal">session</tt> because winbind does not add to either of
3024
those functions.</p>
3026
<p>The third column lists the PAM module, possibly with arguments, that
3027
is called in for the task. The
3028
<em class="filename">pam_stack.so</em><a name="INDEX-113"/> module has been added by Red Hat to act
3029
somewhat like a macro or a subroutine. It calls the file in the
3030
<em class="filename">pam.d</em> directory named by the service argument.
3031
In this case, the file <em class="filename">/etc/pam.d/system-auth</em>
3032
contains a common set of lines that are used as a default for many
3033
services. Because we want to customize the login service for winbind,
3034
we first replace the <em class="filename">pam_stack.so</em> lines for
3035
<tt class="literal">auth</tt> and <tt class="literal">account</tt> with the
3036
<tt class="literal">auth</tt> and <tt class="literal">account</tt> lines from
3037
<em class="filename">/etc/pam.d/system-auth</em>. This yields:</p>
3039
<blockquote><pre class="code">auth required /lib/security/pam_securetty.so
3040
<b class="emphasis-bold">auth required /lib/security/pam_env.so</b>
3041
<b class="emphasis-bold">auth sufficient /lib/security/pam_unix.so likeauth nullok</b>
3042
<b class="emphasis-bold">auth required /lib/security/pam_deny.so</b>
3043
auth required /lib/security/pam_nologin.so
3044
<b class="emphasis-bold">account required /lib/security/pam_unix.so</b>
3045
password required /lib/security/pam_stack.so service=system-auth
3046
session required /lib/security/pam_stack.so service=system-auth
3047
session optional /lib/security/pam_console.so</pre></blockquote>
3049
<p>To add winbind support, we need to add a line in both the
3050
<tt class="literal">auth</tt> and <tt class="literal">account</tt> sections to
3052
<em class="filename">pam_winbind.so</em><a name="INDEX-114"/> module:</p>
3054
<blockquote><pre class="code">auth required /lib/security/pam_securetty.so
3055
auth required /lib/security/pam_env.so
3056
<b class="emphasis-bold">auth sufficient /lib/security/pam_winbind.so</b>
3057
auth sufficient /lib/security/pam_unix.so <b class="emphasis-bold">use_first_pass</b> likeauth nullok
3058
auth required /lib/security/pam_deny.so
3059
auth required /lib/security/pam_nologin.so
3060
<b class="emphasis-bold">account sufficient /lib/security/pam_winbind.so</b>
3061
account required /lib/security/pam_unix.so
3062
password required /lib/security/pam_stack.so service=system-auth
3063
session required /lib/security/pam_stack.so service=system-auth
3064
session optional /lib/security/pam_console.so</pre></blockquote>
3066
<p>The keywords <tt class="literal">required</tt> and
3067
<tt class="literal">sufficient</tt> in the second column are significant.
3068
The keyword <tt class="literal">required</tt> specifies that the result
3069
returned by the module (either to pass or fail the authentication)
3070
must be taken into account, whereas the keyword
3071
<tt class="literal">sufficient</tt> specifies that if the module
3072
successfully authenticates the user, no further lines need to be
3073
processed. By specifying <tt class="literal">sufficient</tt> for the
3074
<em class="filename">pam_winbind.so</em> module, we let winbind attempt to
3075
authenticate users, and if it succeeds, the PAM system returns to the
3076
application. If the <em class="filename">pam_winbind.so</em> module
3077
doesn't find the user or the password does not
3078
match, the PAM system continues with the next line, which performs
3079
authentication according to the usual Linux user authentication. This
3080
way, both domain users and local users can log in.</p>
3082
<p>Notice that we also added the <tt class="literal">use_first_pass</tt>
3083
argument to the <em class="filename">pam_unix.so</em> module in the
3084
<tt class="literal">auth</tt> section. By default, both the
3085
<em class="filename">pam_winbind.so</em> and
3086
<em class="filename">pam_unix.so</em> modules print a password prompt and
3087
accept a password. In cases where users are logging in to the Linux
3088
system using their local accounts, this would require them to enter
3089
their password twice. The <tt class="literal">user_first_pass</tt> argument
3090
tells the <em class="filename">pam_unix.so</em> module to reuse the
3091
password that was given to the <em class="filename">pam_winbind.so</em>
3092
module, which results in users having to enter the password only
3095
<p>After modifying the <em class="filename">login</em> configuration file,
3096
switch to a spare virtual console and make sure you can still log in
3097
using a regular Linux account. If not, check your modifications
3098
carefully and try again until you get it right. Then log in using a
3099
domain user account from the Windows PDC database to check that the
3100
winbind authentication works. You will need to specify the username
3101
in <em class="replaceable">DOMAIN</em>\<em class="replaceable">user</em>
3102
format, like this:</p>
3104
<blockquote><pre class="code">login: METRAN\linda
3105
Password:</pre></blockquote>
3107
<p>More information on configuring winbind can be found in the Samba
3108
source distribution file
3109
<em class="filename">docs/htmldocs/winbind.html</em>, and in the
3110
<em class="emphasis">winbindd</em> manual page. If you would like to learn
3111
more about configuring PAM, we recommend the web page <a href="http://www.kernel.org/pub/linux/libs/pam/">http://www.kernel.org/pub/linux/libs/pam/</a> as
3112
a starting place. Some of the documentation for Linux PAM, including
3113
Red Hat's extensions, can also be found on Red Hat
3115
<em class="filename">/usr/share/doc/pam-</em><em class="replaceable">version</em>.
3116
<a name="INDEX-115"/></p>
3122
<div class="sect2"><a name="samba2-CHP-9-SECT-5.5"/>
3124
<h3 class="head2">winbind Configuration Options</h3>
3126
<p><a href="ch09.html#samba2-CHP-9-TABLE-9">Table 9-9</a> <a name="INDEX-116"/><a name="INDEX-117"/>summarizes some commonly used options
3127
that you can use to configure winbind.</p>
3129
<a name="samba2-CHP-9-TABLE-9"/><h4 class="head4">Table 9-9. winbind options</h4><table border="1">
3157
<p><tt class="literal">winbind</tt> <tt class="literal">separator</tt></p>
3160
<p>string (single character)</p>
3163
<p>Character to use as a separator in domain usernames and group names</p>
3166
<p>Backslash (<tt class="literal">\</tt>)</p>
3174
<p><tt class="literal">winbind uid</tt></p>
3177
<p>string (numeric range)</p>
3180
<p>Range of UIDs for RID-to-UID mapping</p>
3191
<p><tt class="literal">winbind gid</tt></p>
3194
<p>string (numeric range)</p>
3197
<p>Range of GIDs for RID-to-GID mapping</p>
3208
<p><tt class="literal">winbind cache time</tt></p>
3214
<p>Number of seconds the <em class="emphasis">winbindd</em> daemon caches
3215
user and group data</p>
3218
<p><tt class="literal">15</tt></p>
3226
<p><tt class="literal">template</tt> <tt class="literal">homedir</tt></p>
3229
<p>string (directory name)</p>
3232
<p>Directory to be used as the home directory of the logged-in domain
3236
<p><tt class="literal">/home/%D/%U</tt></p>
3244
<p><tt class="literal">template</tt> <tt class="literal">shell</tt></p>
3247
<p>string (command name)</p>
3250
<p>The program to use as the logged-in domain user's
3254
<p><tt class="literal">/bin/false</tt></p>
3264
<div class="sect3"><a name="samba2-CHP-9-SECT-5.5.1"/>
3266
<a name="INDEX-118"/><h3 class="head3">winbind separator</h3>
3268
<p>On Windows systems, the backslash (<tt class="literal">\</tt>) is commonly
3269
used as a separator in file names, UNCs, and the names of domain
3270
users and groups. For example, an account in the METRAN domain with a
3271
username of <tt class="literal">linda</tt> would be written as
3272
<tt class="literal">METRAN\linda</tt>. On Unix systems, the backslash is
3273
commonly used as a metacharacter for quoting, so the account would
3274
have to be specified as <tt class="literal">METRAN\\linda</tt> or
3275
'<tt class="literal">METRAN\linda</tt>'. The winbind separator parameter
3276
allows another character to be used instead of the backslash
3277
character, making it much easier to type in domain user and group
3278
names. For example, with:</p>
3280
<blockquote><pre class="code">[global]
3281
winbind separator = +</pre></blockquote>
3283
<p>the aforementioned account could be written simply as
3284
<tt class="literal">METRAN+linda</tt> on the Unix host, making it
3285
unnecessary to use additional backslashes or single quotes. Winbind
3286
then uses the same format for reporting domain user and group names.</p>
3293
<div class="sect3"><a name="samba2-CHP-9-SECT-5.5.2"/>
3295
<a name="INDEX-119"/><h3 class="head3">winbind uid</h3>
3297
<p>As part of <em class="emphasis">winbindd</em> 's task of
3298
letting Windows NT domain users function as local users on the Unix
3299
host, <em class="emphasis">winbindd</em> supplies a Unix UID that is
3300
linked to the Windows RID of the domain user. The
3301
<tt class="literal">winbind</tt> <tt class="literal">uid</tt> parameter allows
3302
the Unix system administrator to allocate a range of UIDs for this
3303
purpose. It is very important that this range not overlap any UIDs
3304
used for other purposes on the Unix system, so we recommend you begin
3305
your range at a very high number, one much larger than the number of
3306
local users and NIS users that will ever exist. For example,
3307
<tt class="literal">winbind</tt> <tt class="literal">uid</tt> might be defined
3310
<blockquote><pre class="code">[global]
3311
winbind uid = 10000-15000</pre></blockquote>
3313
<p>on a system that would never have more than 9,999 local and NIS
3314
users, or for that matter, any other entries in
3315
<em class="filename">/etc/passwd</em> that would use up another UID.
3316
Because the example allocates 5,000 UIDs to
3317
<em class="emphasis">winbindd</em>, the assumption is that there will
3318
never be more than 5,000 domain users accessing the Samba host.</p>
3320
<p>If your method for adding new local users to the system assigns UIDs
3321
automatically, make sure it does not assign them within the range of
3322
UIDs allocated to winbind. This might happen if the algorithm used
3323
adds 1 to the highest UID assigned thus far.</p>
3325
<p>There is no default for <tt class="literal">winbind</tt>
3326
<tt class="literal">uid</tt>, so you must specify it in your Samba
3327
configuration file for winbind to work.</p>
3334
<div class="sect3"><a name="samba2-CHP-9-SECT-5.5.3"/>
3336
<a name="INDEX-120"/><h3 class="head3">winbind gid</h3>
3338
<p>This option works like <tt class="literal">winbind</tt>
3339
<tt class="literal">uid</tt>, except that it is for allocating a range of
3340
GIDs for use with <em class="emphasis">winbindd</em>. You might not need
3341
to allocate as many GIDs as UIDs because you probably have relatively
3342
few domain groups that need corresponding GIDs. (In many cases, users
3343
are all members of the Domain Users group, requiring only one GID.)
3344
However, it is best to play it safe, so make sure to allocate many
3345
more GIDs than you think you will need.</p>
3347
<p>As with <tt class="literal">winbind</tt> <tt class="literal">uid</tt>, if you are
3348
using a method of adding new local users to your Unix host that
3349
automatically assigns GIDs, either make sure the method used
3350
doesn't conflict with winbind or set the GIDs
3353
<p>There is no default for <tt class="literal">winbind</tt>
3354
<tt class="literal">gid</tt>, so you must specify it in your Samba
3355
configuration file for winbind to work.</p>
3362
<div class="sect3"><a name="samba2-CHP-9-SECT-5.5.4"/>
3364
<a name="INDEX-121"/><h3 class="head3">winbind cache time</h3>
3366
<p>The <em class="emphasis">winbindd</em> daemon maintains a cache of user
3367
and group data that has been retrieved from the Windows PDC to reduce
3368
network queries and increase performance. The
3369
<tt class="literal">winbind</tt> <tt class="literal">cache</tt>
3370
<tt class="literal">time</tt> parameter allows the amount of time (in
3371
seconds) <em class="emphasis">winbindd</em> can use the cached data before
3372
querying the PDC to check for an update. By default, this interval is
3373
set to 15 seconds. This means that when any part of a user or group
3374
account on the PDC is modified, it can take up to 15 seconds for
3375
<em class="emphasis">winbindd</em> to update its own database.</p>
3382
<div class="sect3"><a name="samba2-CHP-9-SECT-5.5.5"/>
3384
<a name="INDEX-122"/><h3 class="head3">template homedir</h3>
3386
<p>When the local Unix system is configured to allow domain users to log
3387
in, the user must be provided with a home directory for many
3388
programs, including command shells, to function properly. The
3389
<tt class="literal">template</tt> <tt class="literal">homedir</tt> option is used
3390
to set the name of the home directory. In the name of the directory,
3391
<tt class="literal">%D</tt> is replaced by the name of the Windows NT
3392
domain the user is in, and <tt class="literal">%U</tt> is replaced by his
3393
username. By default, <tt class="literal">template</tt>
3394
<tt class="literal">homedir</tt> is set to <tt class="literal">/home/%D/%U</tt>,
3395
which works fine for a network in which there might be more than one
3396
Windows NT domain, and it is possible for different people in
3397
different domains to have the same username. If you are sure you will
3398
never have more than one Windows NT domain on your network, or you
3399
have more than one domain but know for sure that unique users have
3400
identical usernames in each multiple domain, you might prefer to set
3401
<tt class="literal">template</tt> <tt class="literal">homedir</tt> like this:</p>
3403
<blockquote><pre class="code">[global]
3404
template homedir = /home/%U</pre></blockquote>
3411
<div class="sect3"><a name="samba2-CHP-9-SECT-5.5.6"/>
3413
<a name="INDEX-123"/><h3 class="head3">template shell</h3>
3415
<p>This option specifies the program to use as the shell for domain
3416
users who are logged in to the Unix host. By default, it is set to
3417
<em class="emphasis">/bin/false</em>, which effectively denies domain
3418
users to log in. If you wish to allow logins for domain users, set
3419
<tt class="literal">template</tt> <tt class="literal">shell</tt> to a valid
3420
command shell (or other program) that you want to act as the textual
3421
interface the domain users will receive when logged in. A common
3422
setting on Linux would be:</p>
3424
<blockquote><pre class="code">[global]
3425
template shell = /bin/bash</pre></blockquote>
3427
<p>which would give users the Bash shell for their interactive login
3428
sessions. <a name="INDEX-124"/><a name="INDEX-125"/> <a name="INDEX-126"/><a name="INDEX-127"/></p>
3439
<hr/><h4 class="head4">Footnotes</h4><blockquote><a name="FOOTNOTE-1"/> <p><a href="#FNPTR-1">[1]</a> Having both encrypted and nonencrypted
3440
password clients on your network is one of the reasons why Samba
3441
allows you to include (or not include) various options in the Samba
3442
configuration file based on the client operating system or machine
3443
name variables.</p> <a name="FOOTNOTE-2"/>
3444
<p><a href="#FNPTR-2">[2]</a> This is because the Unix <em class="emphasis">passwd</em> program,
3445
which is the usual target for this operation, allows
3446
<tt class="literal">root</tt> to change a user's password
3447
without the security restriction that requests the old password of
3448
that user.</p> </blockquote><hr/><h4 class="head4"><a href="toc.html">TOC</a></h4></body></html>