| blob | bc2a5bb007958f5ff6ffd21f6012adf55248b400 |
1 <html>
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
14 network.</p>
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
25 methods of handling user authentication.</p>
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
44 path = /home/dave
45 comment = Dave's home directory
46 writable = yes
47 valid users = dave</pre></blockquote>
50 the users allowed to access the share. In this case, only the user
52 situations it is possible to specify that any user can access a disk
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
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
76 example :</p>
79 comment = %U home directory
80 writable = yes
81 valid users = dave
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
94 comment = Accounting Department Directory
95 writable = yes
96 valid users = @account
97 path = /home/samba/accounting
98 create mode = 0660
101 <p>The first thing we did differently is to specify
103 individual usernames. This is shorthand for saying that the valid
105 These users will need to be added to the group entry
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
115 commands that create the shared directory for the accounting
117 exists):</p>
124 example, both of which we saw in the previous chapter. These options
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
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
144 browsable = no
145 writable = yes</pre></blockquote>
148 Samba configuration file. If a user attempts to connect to an
149 ordinary share that doesn't appear in the
151 in Windows Explorer), Samba will search for a
153 name is assumed to be a username and is queried as such in the
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
163 password database, so Samba takes the following steps:</p>
165 <ol><li>
170 it to her home directory.</p>
171 </li><li>
172 <p>Samba initializes the new share's options from the
176 </li><li>
178 that share.</p>
179 </li></ol>
181 create shares for your user community without having to duplicate the
182 information from the password database file in the
185 point out:</p>
187 <ul><li>
189 the machine, which isn't always desirable. For
190 example, it can potentially create a share for
193 can set a global
195 to protect against this.</p>
196 </li><li>
197 <p>The meaning of the
199 different from other shares; it indicates only that a
203 is created (after the initial connection), it will use the
207 </li></ul>
208 <p>As we mentioned, there is no need for a path statement in
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
217 </div>
220 </div>
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
233 Samba setup.</p>
235 <p>We've seen what happens when you specify valid
236 users. However, you are also allowed to specify a list of
238 allowed access to Samba or its shares. This is done with the
240 option. We hinted at one frequent use of this option earlier: a
242 that various system users and superusers cannot be forged for access.
243 For example:</p>
246 invalid users = root bin daemon adm sync shutdown \
247 halt mail news uucp operator
248 auto services = dave peter bob
250 [homes]
251 browsable = no
252 writable = yes</pre></blockquote>
257 usernames. In the event that a user or group appears in both lists,
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
264 option. An example follows:</p>
267 path = /home/sales
268 comment = Sedona Real Estate Sales Data
269 writable = yes
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
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
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>
292 path = /home/sales
293 comment = Sedona Real Estate Sales Data
294 read only = yes
295 write list = sofie shelby</pre></blockquote>
298 cannot override Unix permissions. If you've created
300 permission on the Unix system, she will be denied write access
310 earlier, you can configure a share using
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
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
322 works well with most Unix versions. However, on some systems the
324 services (e.g., printing), and you might need to set the guest user
328 other words, all clients connect as the guest account when accessing
332 the following example:</p>
335 path = /home/sales
336 comment = Sedona Real Estate Sales Data
337 writable = yes
338 guest ok = yes
339 guest account = ftp
340 guest only = yes</pre></blockquote>
345 not use the guest account that you specify.</p>
348 </div>
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">
365 <tr>
366 <th>
368 </th>
369 <th>
371 </th>
372 <th>
374 </th>
375 <th>
377 </th>
378 <th>
380 </th>
381 </tr>
384 <tr>
385 <td>
387 </td>
388 <td>
390 </td>
391 <td>
393 </td>
394 <td>
396 </td>
397 <td>
399 </td>
400 </tr>
401 <tr>
402 <td>
404 </td>
405 <td>
407 </td>
408 <td>
410 </td>
411 <td>
413 </td>
414 <td>
416 </td>
417 </tr>
418 <tr>
419 <td>
421 </td>
422 <td>
424 </td>
425 <td>
427 </td>
428 <td>
430 </td>
431 <td>
433 </td>
434 </tr>
435 <tr>
436 <td>
438 </td>
439 <td>
441 </td>
442 <td>
444 </td>
445 <td>
447 </td>
448 <td>
450 </td>
451 </tr>
452 <tr>
453 <td>
455 </td>
456 <td>
458 </td>
459 <td>
461 </td>
462 <td>
464 </td>
465 <td>
467 </td>
468 </tr>
469 <tr>
470 <td>
472 </td>
473 <td>
475 </td>
476 <td>
478 </td>
479 <td>
481 </td>
482 <td>
484 </td>
485 </tr>
486 <tr>
487 <td>
489 </td>
490 <td>
492 </td>
493 <td>
495 </td>
496 <td>
498 </td>
499 <td>
501 </td>
502 </tr>
503 <tr>
504 <td>
506 </td>
507 <td>
509 </td>
510 <td>
512 </td>
513 <td>
515 </td>
516 <td>
518 </td>
519 </tr>
521 </table>
528 <p>This option specifies a list of users that perform file operations as
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
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>
539 </div>
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
551 NIS groups searched before Unix groups. If the name is prefixed by a
553 Unix group, and NIS is not searched. If the name is prefixed by an
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>
560 valid users = mary ellen sue &sales +marketing @dbadmin
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
584 </div>
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
599 permissions granted—as well as Unix file permissions on the
600 server system—to deny users write access.
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
607 a default value associated with it.</p>
610 </div>
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
622 unlimited number of connections. You can override it per share as
623 follows:</p>
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
630 concurrently.</p>
633 </div>
647 this option to be recognized by Samba. The default value for this
651 </div>
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
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>
667 </div>
670 </div>
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
679 and Unix.</p>
681 <a name="samba2-CHP-9-TABLE-2"/><h4 class="head4">Table 9-2. Username options</h4><table border="1">
688 <tr>
689 <th>
691 </th>
692 <th>
694 </th>
695 <th>
697 </th>
698 <th>
700 </th>
701 <th>
703 </th>
704 </tr>
707 <tr>
708 <td>
710 </td>
711 <td>
713 </td>
714 <td>
716 </td>
717 <td>
719 </td>
720 <td>
722 </td>
723 </tr>
724 <tr>
725 <td>
727 </td>
728 <td>
730 </td>
731 <td>
732 <p>Indicates the number of capital letters to use when trying to match a
733 username</p>
734 </td>
735 <td>
737 </td>
738 <td>
740 </td>
741 </tr>
743 </table>
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
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
761 file; make the root user the file's owner and deny
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>
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
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
778 examples:</p>
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>
789 <p>Comments can be placed in the file by starting the line with a hash
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>
798 </div>
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
812 doing the following:</p>
814 <ol><li>
816 </li><li>
818 </li><li>
819 <p>Testing the username in lowercase letters with only the first letter
820 capitalized</p>
821 </li></ol>
822 <p>If you wish to have Samba attempt more combinations of upper- and
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>
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>
838 </div>
841 </div>
844 </div>
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
857 Samba does with that password—and consequently the strategy
858 Samba will use to handle user authentication—is the arena of
865 <dl>
867 <dd>
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>
870 </dd>
875 <dd>
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>
879 </dd>
884 <dd>
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>
888 </dd>
893 <dd>
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>
903 </dd>
905 </dl>
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">
917 <tr>
918 <th>
920 </th>
921 <th>
923 </th>
924 <th>
926 </th>
927 <th>
929 </th>
930 <th>
932 </th>
933 </tr>
936 <tr>
937 <td>
939 </td>
940 <td>
943 </td>
944 <td>
946 </td>
947 <td>
949 </td>
950 <td>
952 </td>
953 </tr>
955 </table>
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
971 have access.</p>
975 by first enabling share-level security using the Access Control tab
976 of the Network Control Panel dialog. Then select the
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>
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
990 supplied.</p>
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
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>
1001 <ol><li>
1002 <p>When a connection is requested, Samba will accept the password and
1003 (if sent) the username of the client.</p>
1004 </li><li>
1006 the user is immediately granted access to the share with the rights
1009 performed.</p>
1010 </li><li>
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
1018 </li><li>
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
1025 share under that username.</p>
1026 </li><li>
1029 user will default to access with the rights of the user specified by
1031 </li></ol>
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
1037 security = share
1039 [accounting1]
1040 path = /home/samba/accounting1
1041 guest ok = no
1042 writable = yes
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
1049 the passwords match, the connection is verified, and the user is
1050 allowed. Otherwise, connection to the specific share will fail.</p>
1053 </div>
1060 <p><a href="ch09.html#samba2-CHP-9-TABLE-4">Table 9-4</a> shows the options typically associated
1064 <a name="samba2-CHP-9-TABLE-4"/><h4 class="head4">Table 9-4. Share-level access options</h4><table border="1">
1071 <tr>
1072 <th>
1074 </th>
1075 <th>
1077 </th>
1078 <th>
1080 </th>
1081 <th>
1083 </th>
1084 <th>
1086 </th>
1087 </tr>
1090 <tr>
1091 <td>
1093 </td>
1094 <td>
1096 </td>
1097 <td>
1100 </td>
1101 <td>
1103 </td>
1104 <td>
1106 </td>
1107 </tr>
1108 <tr>
1109 <td>
1112 </td>
1113 <td>
1115 </td>
1116 <td>
1118 </td>
1119 <td>
1121 </td>
1122 <td>
1124 </td>
1125 </tr>
1127 </table>
1134 <p>This Boolean option indicates whether Samba will allow connections to
1135 a share using share-level security based solely on the individuals
1137 users compiled on Samba's internal list. The default
1139 per share as follows:</p>
1142 security = share
1143 [data]
1144 username = andy, peter, valerie
1145 only user = yes</pre></blockquote>
1148 </div>
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
1161 specific user:</p>
1164 security = share
1165 [data]
1166 username = andy, peter, terry</pre></blockquote>
1168 <p>You can enter a list of usernames and/or group names. If a name is
1170 group name, with NIS groups searched before Unix groups. If the name
1172 as the name of a Unix group, and NIS is not searched. If the name 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
1179 inefficient.</p>
1181 <p>We recommend against using this option unless you are implementing a
1182 Samba server with share-level security.</p>
1185 </div>
1188 </div>
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
1204 share:</p>
1207 security = user
1209 [accounting1]
1210 writable = yes
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
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
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>
1232 </div>
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
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
1257 global configuration option, as follows:</p>
1260 security = server
1261 password server = mixtec toltec</pre></blockquote>
1263 <p>Note that you can specify more than one machine as the target of the
1265 down the list of servers in the event that its first choice is
1266 unreachable. The servers identified by the
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
1271 server.</p>
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
1280 asterisk (*).</p>
1283 </div>
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>
1311 </div>
1314 </div>
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
1336 systems encrypt their passwords and which send plain-text passwords
1337 by default.</p>
1339 <a name="samba2-CHP-9-TABLE-5"/><h4 class="head4">Table 9-5. Windows operating systems with encrypted passwords</h4><table border="1">
1343 <tr>
1344 <th>
1346 </th>
1347 <th>
1349 </th>
1350 </tr>
1353 <tr>
1354 <td>
1356 </td>
1357 <td>
1359 </td>
1360 </tr>
1361 <tr>
1362 <td>
1364 </td>
1365 <td>
1367 </td>
1368 </tr>
1369 <tr>
1370 <td>
1372 </td>
1373 <td>
1375 </td>
1376 </tr>
1377 <tr>
1378 <td>
1380 </td>
1381 <td>
1383 </td>
1384 </tr>
1385 <tr>
1386 <td>
1388 </td>
1389 <td>
1391 </td>
1392 </tr>
1393 <tr>
1394 <td>
1396 </td>
1397 <td>
1399 </td>
1400 </tr>
1401 <tr>
1402 <td>
1404 </td>
1405 <td>
1407 </td>
1408 </tr>
1409 <tr>
1410 <td>
1412 </td>
1413 <td>
1415 </td>
1416 </tr>
1417 <tr>
1418 <td>
1420 </td>
1421 <td>
1423 </td>
1424 </tr>
1425 <tr>
1426 <td>
1428 </td>
1429 <td>
1431 </td>
1432 </tr>
1434 </table>
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
1446 directory of the Samba distribution (typically
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>
1457 <ol><li>
1459 </li><li>
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
1463 </li><li>
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>
1467 </li><li>
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>
1471 </li></ol>
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
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
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
1485 that we explicitly name the location of the Samba password file:</p>
1488 security = user
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
1503 in use for decades—including the use of
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
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
1515 files you need for this, located in the source
1517 directory. Depending on the platform, you use one of the following
1518 files:</p>
1532 </blockquote>
1535 2000.) You can perform the installation by copying the appropriate
1537 in the client's floppy drive, and running 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>
1552 security = user
1553 encrypt passwords = no</pre></blockquote>
1556 </div>
1563 <p>Samba stores its encrypted passwords in a file called
1565 which by default resides in the
1568 the Unix system's password file (either
1572 no other users should have access to it at all. In addition, the
1574 all users except for root. When things are set up for good security,
1578 <blockquote><pre class="code"># <tt class="userinput"><b>ls -ld /usr/local/samba/private</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
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
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>
1594 Still, you might like to know how to interpret data within the
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>
1599 <dl>
1601 <dd>
1602 <p>This is the username of the account. It is taken directly from the
1603 system password file.</p>
1604 </dd>
1609 <dd>
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
1612 there.</p>
1613 </dd>
1618 <dd>
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
1626 are concatenated and stored as the password hash.</p>
1630 characters of the hash will consist of the sequence
1634 characters.</p>
1635 </dd>
1639 <dd>
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>
1645 </dd>
1650 <dd>
1652 of the following characters can appear in any order; the remaining
1653 characters should be spaces:</p>
1656 <dl>
1658 <dd>
1660 </dd>
1665 <dd>
1666 <p>This account is currently disabled, and Samba should not allow any
1667 logins.</p>
1668 </dd>
1673 <dd>
1675 </dd>
1680 <dd>
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>
1683 </dd>
1685 </dl>
1686 </dd>
1690 <dd>
1692 by a hexadecimal representation of the number of seconds since the
1695 </dd>
1697 </dl>
1700 </div>
1709 and an encrypted version of the same password (in the
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
1720 unix password sync = yes</pre></blockquote>
1722 <p>With this option enabled, Samba attempts to change the
1724 when the encrypted version is changed with
1726 set correctly for this to work.</p>
1730 command used to change a user's standard system
1733 sufficient, and you do not need to change anything. Others, such as
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
1740 to represent the current Unix username. So the example becomes:</p>
1743 unix password sync = yes
1744 passwd program = changepass %u</pre></blockquote>
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
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
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
1767 handle a variety of similar outputs. Here,
1769 any line from the password program containing the letters
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
1781 the standard input of the password-changing program, and then
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
1788 final pattern is matched.</p>
1790 <p>You can help match the response strings sent from the password
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">
1798 <tr>
1799 <th>
1801 </th>
1802 <th>
1804 </th>
1805 </tr>
1808 <tr>
1809 <td>
1811 </td>
1812 <td>
1814 </td>
1815 </tr>
1816 <tr>
1817 <td>
1819 </td>
1820 <td>
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>
1824 </td>
1825 </tr>
1827 </table>
1829 <a name="samba2-CHP-9-TABLE-7"/><h4 class="head4">Table 9-7. Password chat send characters</h4><table border="1">
1833 <tr>
1834 <th>
1836 </th>
1837 <th>
1839 </th>
1840 </tr>
1843 <tr>
1844 <td>
1846 </td>
1847 <td>
1849 </td>
1850 </tr>
1851 <tr>
1852 <td>
1854 </td>
1855 <td>
1857 </td>
1858 </tr>
1859 <tr>
1860 <td>
1862 </td>
1863 <td>
1865 </td>
1866 </tr>
1867 <tr>
1868 <td>
1870 </td>
1871 <td>
1873 </td>
1874 </tr>
1875 <tr>
1876 <td>
1878 </td>
1879 <td>
1881 </td>
1882 </tr>
1883 <tr>
1884 <td>
1886 </td>
1887 <td>
1889 </td>
1890 </tr>
1892 </table>
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
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
1909 everything during a password chat. This option is a simple Boolean,
1910 as shown here:</p>
1913 unix password sync = yes
1914 passwd chat debug = yes
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
1922 multitudes of error logs, it can be more efficient to use your own
1926 exchange. Be careful because the log file contains the passwords in
1927 plain text. Keeping files containing plain-text passwords can (or
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
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
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
1954 </div>
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">
1970 <tr>
1971 <th>
1973 </th>
1974 <th>
1976 </th>
1977 <th>
1979 </th>
1980 <th>
1982 </th>
1983 <th>
1985 </th>
1986 </tr>
1989 <tr>
1990 <td>
1992 </td>
1993 <td>
1995 </td>
1996 <td>
1998 </td>
1999 <td>
2001 </td>
2002 <td>
2004 </td>
2005 </tr>
2006 <tr>
2007 <td>
2009 </td>
2010 <td>
2012 </td>
2013 <td>
2015 database when a user changes his encrypted password.</p>
2016 </td>
2017 <td>
2019 </td>
2020 <td>
2022 </td>
2023 </tr>
2024 <tr>
2025 <td>
2027 </td>
2028 <td>
2030 </td>
2031 <td>
2033 </td>
2034 <td>
2036 </td>
2037 <td>
2039 </td>
2040 </tr>
2041 <tr>
2042 <td>
2044 </td>
2045 <td>
2047 </td>
2048 <td>
2051 </td>
2052 <td>
2054 </td>
2055 <td>
2057 </td>
2058 </tr>
2059 <tr>
2060 <td>
2062 </td>
2063 <td>
2065 </td>
2066 <td>
2068 </td>
2069 <td>
2071 </td>
2072 <td>
2074 </td>
2075 </tr>
2076 <tr>
2077 <td>
2079 </td>
2080 <td>
2082 </td>
2083 <td>
2084 <p>Number of capital-letter permutations to attempt when matching a
2085 client's password.</p>
2086 </td>
2087 <td>
2089 </td>
2090 <td>
2092 </td>
2093 </tr>
2094 <tr>
2095 <td>
2097 </td>
2098 <td>
2100 </td>
2101 <td>
2103 client connects to a share with a plain-text password.</p>
2104 </td>
2105 <td>
2107 </td>
2108 <td>
2110 </td>
2111 </tr>
2112 <tr>
2113 <td>
2115 </td>
2116 <td>
2118 </td>
2119 <td>
2121 passwords.</p>
2122 </td>
2123 <td>
2125 </td>
2126 <td>
2128 </td>
2129 </tr>
2130 <tr>
2131 <td>
2133 </td>
2134 <td>
2136 </td>
2137 <td>
2139 </td>
2140 <td>
2142 </td>
2143 <td>
2145 </td>
2146 </tr>
2147 <tr>
2148 <td>
2150 </td>
2151 <td>
2153 </td>
2154 <td>
2155 <p>Name of a file that contains hosts and users that can connect without
2156 using a password.</p>
2157 </td>
2158 <td>
2160 </td>
2161 <td>
2163 </td>
2164 </tr>
2165 <tr>
2166 <td>
2168 </td>
2169 <td>
2171 </td>
2172 <td>
2174 connect without using a password.</p>
2175 </td>
2176 <td>
2178 </td>
2179 <td>
2181 </td>
2182 </tr>
2184 </table>
2193 plain-text passwords to encrypted passwords for authentication.
2194 Encrypted passwords will be expected from clients if the option is
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
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
2208 location (typically
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
2221 each client appropriately. To do this, create individual
2223 These host-specific configuration files can contain an
2226 only when those clients are connecting to the server.</p>
2229 </div>
2239 standard Unix password file when a user changes her encrypted
2240 password. The encrypted password is stored on a Samba server in the
2243 feature as follows:</p>
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
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>
2258 </div>
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>
2272 </div>
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
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>
2296 </div>
2306 Samba server that Samba can use to update the standard system
2307 password file when the encrypted password file is updated. This
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>
2317 </div>
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>
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>
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>
2347 </div>
2355 <p>For sites switching over to the encrypted password format, Samba
2356 provides an option that should help with the transition. The
2358 a site to ease into using encrypted passwords from plain-text
2359 passwords. You can activate this option as follows:</p>
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
2367 share. When this option is enabled, you must have the
2370 to Samba to update the files. Once each user has connected at least
2374 passwords. The user must already have a valid entry in the
2378 </div>
2386 <p>This global option tells Samba whether to allow access from users
2387 that have null passwords (encrypted or nonencrypted) set in their
2389 override it as follows:</p>
2393 <p>We highly recommend against doing so because of the security risks
2394 this option can present to your system, including inadvertent access
2396 password file who have null passwords set.</p>
2399 </div>
2407 <p>This global option identifies the location of the encrypted password
2408 database. By default, it is set to
2410 override it as follows:</p>
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>
2419 </div>
2427 <p>This global option specifies the name of a standard Unix
2429 access shares without specifying a password. You can specify the
2430 location of such a file as follows:</p>
2433 hosts equiv = /etc/hosts.equiv</pre></blockquote>
2435 <p>The default value for this option does not specify any
2438 strongly recommend against using this option.</p>
2441 </div>
2449 <p>This global option specifies the name of a standard Unix
2451 foreign hosts to access shares without specifying a password. You can
2452 specify the location of such a file as follows:</p>
2455 use rhosts = /home/dave/.rhosts</pre></blockquote>
2457 <p>The default value for this option does not specify any
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.
2466 </div>
2469 </div>
2472 </div>
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>
2493 server as a domain member server to a network having a Windows
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
2507 not only authentication, but the user and group information as well.
2508 Winbind works by extending the Unix user and group databases beyond
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
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>
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
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>
2538 </blockquote>
2546 and configuring winbind is fairly complicated and involves the
2547 following steps:</p>
2549 <ol><li>
2551 winbind.</p>
2552 </li><li>
2554 </li><li>
2556 </li><li>
2558 </li><li>
2559 <p>Configure the system to start and stop the
2561 </li><li>
2563 </li></ol>
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
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
2576 </div>
2584 Samba is compiled after being configured with the
2586 produces a library called
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
2594 functional:</p>
2596 <blockquote><pre class="code"># <tt class="userinput"><b>ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2</b></tt></pre></blockquote>
2601 extension—in future releases. See the
2603 </blockquote>
2610 group: files winbind</pre></blockquote>
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
2621 we've just installed. We've
2622 specified in our configuration that Samba will search for user and
2625 there, in the winbind service.</p>
2628 </div>
2636 server added to the Windows NT domain as a domain member server (as
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>
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
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
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>
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>
2672 </blockquote>
2675 <p>Be careful when adding local users after domain users have started
2676 accessing the Samba server. The domain users will have entries
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
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
2688 user.</p>
2689 </blockquote>
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>
2705 everything we've done up to this point works, we can
2709 METRAN\Administrator
2710 METRAN\bebe
2711 METRAN\Guest
2712 METRAN\jay
2713 METRAN\linda
2715 METRAN\Domain Admins
2716 METRAN\Domain Guests
2717 METRAN\Domain Users</pre></blockquote>
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
2740 # getent group
2741 root:x:0:root
2742 bin:x:1:root,bin,daemon
2743 daemon:x:2:root,bin,daemon
2745 jay:x:500:
2746 rik:x:501:
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
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
2758 correctly.</p>
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
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
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
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
2778 requested.</p>
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
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
2791 that is specific to your Windows version.</p>
2792 </blockquote>
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
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>
2809 total 4
2816 <blockquote><pre class="code"># <tt class="userinput"><b>chown 'METRAN\linda:METRAN\Domain Users' /u</b></tt>
2822 <p>Notice how the owner and group are listed as being those of the
2824 command won't show the full names of the domain
2826 to show the UIDs and GIDs and then translate with the
2830 METRAN\LINDA 1
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
2839 daemons. Starting with the script we presented in <a href="ch02.html">Chapter 2</a>, we first add this code to the
2843 /usr/local/samba/bin/winbindd
2844 ERROR2=$?
2845 if [ $ERROR2 -ne 0 ]
2846 then
2847 ERROR=1
2848 fi
2849 echo</pre></blockquote>
2851 <p>The previous code should be located after the code that starts
2853 statement.</p>
2859 </blockquote>
2864 /bin/kill -TERM -a winbindd
2865 ERROR2=$?
2866 if [ $ERROR2 -ne 0 ]
2867 then
2868 ERROR=1
2869 fi
2870 echo</pre></blockquote>
2872 <p>Again, this code should be located after the code that stops
2877 </div>
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
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
2904 Administrator's
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
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
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>
2932 template shell = /bin/bash
2933 template homedir = /home/%D/%U</pre></blockquote>
2935 <p>The first line sets the
2937 parameter, which tells winbind what shell to use for domain users
2938 that are logging in to the Unix host. The
2942 variable is replaced by the name of the domain in which the
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
2949 commands:</p>
2955 # <tt class="userinput"><b>chown 'METRAN\linda:METRAN\Domain Users' /home/METRAN/linda</b></tt>
2958 <p>One side effect of creating the home directories is that if the Samba
2960 domain users can see and access their home directories through
2961 Samba's file sharing.</p>
2962 </blockquote>
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>
2969 # <tt class="userinput"><b>cp nsswitch/pam_winbind.so /lib/security</b></tt></pre></blockquote>
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
2978 strongly advise making a backup of this directory:</p>
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
2986 the worst happens, we would reboot into single-user mode (by typing
2988 prompt) or boot a rescue disk, and then we would issue these two
2989 commands:</p>
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>
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
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>
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
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
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
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,
3043 auth required /lib/security/pam_nologin.so
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
3051 call the
3055 auth required /lib/security/pam_env.so
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
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>
3069 returned by the module (either to pass or fail the authentication)
3070 must be taken into account, whereas the keyword
3072 successfully authenticates the user, no further lines need to be
3075 authenticate users, and if it succeeds, the PAM system returns to the
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>
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
3092 module, which results in users having to enter the password only
3093 once.</p>
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
3102 format, like this:</p>
3105 Password:</pre></blockquote>
3107 <p>More information on configuring winbind can be found in the Samba
3108 source distribution file
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
3114 Linux in
3119 </div>
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">
3136 <tr>
3137 <th>
3139 </th>
3140 <th>
3142 </th>
3143 <th>
3145 </th>
3146 <th>
3148 </th>
3149 <th>
3151 </th>
3152 </tr>
3155 <tr>
3156 <td>
3158 </td>
3159 <td>
3161 </td>
3162 <td>
3164 </td>
3165 <td>
3167 </td>
3168 <td>
3170 </td>
3171 </tr>
3172 <tr>
3173 <td>
3175 </td>
3176 <td>
3178 </td>
3179 <td>
3181 </td>
3182 <td>
3184 </td>
3185 <td>
3187 </td>
3188 </tr>
3189 <tr>
3190 <td>
3192 </td>
3193 <td>
3195 </td>
3196 <td>
3198 </td>
3199 <td>
3201 </td>
3202 <td>
3204 </td>
3205 </tr>
3206 <tr>
3207 <td>
3209 </td>
3210 <td>
3212 </td>
3213 <td>
3215 user and group data</p>
3216 </td>
3217 <td>
3219 </td>
3220 <td>
3222 </td>
3223 </tr>
3224 <tr>
3225 <td>
3227 </td>
3228 <td>
3230 </td>
3231 <td>
3232 <p>Directory to be used as the home directory of the logged-in domain
3233 user</p>
3234 </td>
3235 <td>
3237 </td>
3238 <td>
3240 </td>
3241 </tr>
3242 <tr>
3243 <td>
3245 </td>
3246 <td>
3248 </td>
3249 <td>
3250 <p>The program to use as the logged-in domain user's
3251 shell</p>
3252 </td>
3253 <td>
3255 </td>
3256 <td>
3258 </td>
3259 </tr>
3261 </table>
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
3273 commonly used as a metacharacter for quoting, so the account would
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>
3281 winbind separator = +</pre></blockquote>
3283 <p>the aforementioned account could be written simply as
3285 unnecessary to use additional backslashes or single quotes. Winbind
3286 then uses the same format for reporting domain user and group names.</p>
3289 </div>
3298 letting Windows NT domain users function as local users on the Unix
3300 linked to the Windows RID of the domain user. The
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,
3308 as:</p>
3314 users, or for that matter, any other entries in
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
3327 configuration file for winbind to work.</p>
3330 </div>
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>
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
3351 manually.</p>
3355 configuration file for winbind to work.</p>
3358 </div>
3367 and group data that has been retrieved from the Windows PDC to reduce
3368 network queries and increase performance. The
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
3378 </div>
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
3390 to set the name of the home directory. In the name of the directory,
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
3404 template homedir = /home/%U</pre></blockquote>
3407 </div>
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
3418 users to log in. If you wish to allow logins for domain users, set
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>
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>
3431 </div>
3434 </div>
3437 </div>
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
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
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>