diff options
Diffstat (limited to 'docs/htmldocs/using_samba/ch09.html')
| -rw-r--r-- | docs/htmldocs/using_samba/ch09.html | 3448 |
1 files changed, 3448 insertions, 0 deletions
diff --git a/docs/htmldocs/using_samba/ch09.html b/docs/htmldocs/using_samba/ch09.html new file mode 100644 index 0000000000..bc2a5bb007 --- /dev/null +++ b/docs/htmldocs/using_samba/ch09.html @@ -0,0 +1,3448 @@ +<html> +<body bgcolor="#ffffff"> + +<img src="samba2_xs.gif" border="0" alt=" " height="100" width="76" +hspace="10" align="left" /> + +<h1 class="head0">Chapter 9. Users and Security</h1> + + + +<p><a name="INDEX-1"/>In this chapter, we +cover the basic concepts of managing security in Samba so that you +can set up your Samba server with a security policy suited to your +network.</p> + +<p>One of Samba's most complicated tasks lies in +reconciling the security models of Unix and Windows systems. Samba +must identify users by associating them with valid usernames and +groups, authenticate them by checking their passwords, then control +their access to resources by comparing their access rights to the +permissions on files and directories. These are complex topics on +their own, and it doesn't help that there are three +different operating system types to deal with (Unix, Windows +95/98/Me, and Windows NT/2000/XP) and that Samba supports multiple +methods of handling user authentication.</p> + + + +<div class="sect1"><a name="samba2-CHP-9-SECT-1"/> + +<h2 class="head1">Users and Groups</h2> + +<p><a name="INDEX-2"/>Let's start +out as simply as possible and add support for a single user. The +easiest way to set up a client user is to create a Unix account (and +home directory) for that individual on the server and notify Samba of +the user's existence. You can do the latter by +creating a disk share that maps to the user's home +directory in the Samba configuration file and restricting access to +that user with the <tt class="literal">valid</tt><a name="INDEX-3"/> +<tt class="literal">users</tt> option. For example:</p> + +<blockquote><pre class="code">[dave] + path = /home/dave + comment = Dave's home directory + writable = yes + valid users = dave</pre></blockquote> + +<p>The <tt class="literal">valid</tt> <tt class="literal">users</tt> option lists +the users allowed to access the share. In this case, only the user +<tt class="literal">dave</tt> is allowed to access the share. In some +situations it is possible to specify that any user can access a disk +share by using the <tt class="literal">guest</tt> <tt class="literal">ok</tt> +parameter. Because we don't wish to allow guest +access, that option is absent here. If you allow both authenticated +users and guest users access to the same share, you can make some +files accessible to guest users by assigning world-readable +permissions to those files while restricting access to other files to +particular users or groups.</p> + +<p>When client users access a Samba share, they have to pass two levels +of restriction. Unix permissions on files and directories apply as +usual, and configuration parameters specified in the Samba +configuration file apply as well. In other words, a client must first +pass Samba's security mechanisms (e.g., +authenticating with a valid username and password, passing the check +for the <tt class="literal">valid</tt> <tt class="literal">users</tt> parameter +and the <tt class="literal">read</tt> <tt class="literal">only</tt> parameter, +etc.), as well as the normal Unix file and directory permissions of +its Unix-side user, before it can gain read/write access to a share.</p> + +<p>Remember that you can abbreviate the user's home +directory by using the <tt class="literal">%H</tt><a name="INDEX-4"/> variable. In addition, you can use the +Unix username variable <tt class="literal">%u</tt><a name="INDEX-5"/> and/or the client username variable +<tt class="literal">%U</tt><a name="INDEX-6"/> in your options as well. For +example :</p> + +<blockquote><pre class="code">[dave] + comment = %U home directory + writable = yes + valid users = dave + path = %H</pre></blockquote> + +<p>With a single user accessing a home directory, access permissions are +taken care of when the user account is created. The home directory is +owned by the user, and permissions on it are set appropriately. +However, if you're creating a shared directory for +group access, you need to perform a few more steps. +Let's take a stab at a +<a name="INDEX-7"/>group share for the +accounting department in the <em class="emphasis">smb.conf</em> file:</p> + +<blockquote><pre class="code">[accounting] + comment = Accounting Department Directory + writable = yes + valid users = @account + path = /home/samba/accounting + create mode = 0660 + directory mode = 0770</pre></blockquote> + +<p>The first thing we did differently is to specify +<tt class="literal">@account</tt> as the valid user instead of one or more +individual usernames. This is shorthand for saying that the valid +users are represented by the Unix group <tt class="literal">account</tt>. +These users will need to be added to the group entry +<tt class="literal">account</tt> in the +<a name="INDEX-8"/><a name="INDEX-9"/>system group file ( +<em class="filename">/etc/group</em><a name="INDEX-10"/> +or equivalent) to be recognized as part of the group. Once they are, +Samba will recognize those users as valid users for the share.</p> + +<p>In addition, you need to create a shared directory that the members +of the group can access and point to it with the +<tt class="literal">path</tt> configuration option. Here are the Unix +commands that create the shared directory for the accounting +department (assuming <em class="emphasis">/home/samba</em> already +exists):</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>mkdir /home/samba/accounting</b></tt> +# <tt class="userinput"><b>chgrp account /home/samba/accounting</b></tt> +# <tt class="userinput"><b>chmod 770 /home/samba/accounting</b></tt></pre></blockquote> + +<p>There are two other options in this <em class="filename">smb.conf</em> +example, both of which we saw in the previous chapter. These options +are <tt class="literal">create</tt><a name="INDEX-11"/> <tt class="literal">mode</tt> and +<tt class="literal">directory</tt><a name="INDEX-12"/> <tt class="literal">mode</tt>. These +options set the maximum file and directory permissions that a new +file or directory can have. In this case, we have denied all world +access to the contents of this share. (This is reinforced by the +<em class="emphasis">chmod</em> command, shown earlier.)<a name="INDEX-13"/></p> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-1.1"/> + +<h3 class="head2">Handling Multiple Individual Users</h3> + +<p><a name="INDEX-14"/>Let's return +to user shares for a moment. If we have several users for whom to set +up home directory shares, we probably want to use the special +<tt class="literal">[homes]</tt> share that we introduced in <a href="ch08.html">Chapter 8</a>. With the +<tt class="literal">[homes]</tt><a name="INDEX-15"/> share, all we need to say is:</p> + +<blockquote><pre class="code">[homes] + browsable = no + writable = yes</pre></blockquote> + +<p>The <tt class="literal">[homes]</tt> share is a special section of the +Samba configuration file. If a user attempts to connect to an +ordinary share that doesn't appear in the +<em class="filename">smb.conf</em> file (such as specifying it with a UNC +in Windows Explorer), Samba will search for a +<tt class="literal">[homes]</tt> share. If one exists, the incoming share +name is assumed to be a username and is queried as such in the +password database ( <em class="filename">/etc/passwd</em> or equivalent) +file of the Samba server. If it appears, Samba assumes the client is +a Unix user trying to connect to his home directory.</p> + +<p>As an illustration, let's assume that +<tt class="literal">sofia</tt> is attempting to connect to a share called +<tt class="literal">[sofia]</tt> on the Samba server. There is no share by +that name in the configuration file, but a <tt class="literal">[homes]</tt> +share exists and user <tt class="literal">sofia</tt> is present in the +password database, so Samba takes the following steps:</p> + +<ol><li> +<p>Samba creates a new disk share called <tt class="literal">[sofia]</tt> with +the <tt class="literal">path</tt> specified in the +<tt class="literal">[homes]</tt> section. If no <tt class="literal">path</tt> +option is specified in <tt class="literal">[homes]</tt>, Samba initializes +it to her home directory.</p> +</li><li> +<p>Samba initializes the new share's options from the +defaults in <tt class="literal">[globals]</tt>, as well as any overriding +options in <tt class="literal">[homes]</tt> with the exception of +<tt class="literal">browsable</tt>.</p> +</li><li> +<p>Samba connects <tt class="literal">sofia</tt>'s client to +that share.</p> +</li></ol> +<p>The <tt class="literal">[homes]</tt> share is a fast, painless way to +create shares for your user community without having to duplicate the +information from the password database file in the +<em class="filename">smb.conf</em> file. It does have some +<a name="INDEX-16"/>peculiarities, however, that we need to +point out:</p> + +<ul><li> +<p>The <tt class="literal">[homes]</tt> section can represent any account on +the machine, which isn't always desirable. For +example, it can potentially create a share for +<tt class="literal">root</tt>, <tt class="literal">bin</tt>, +<tt class="literal">sys</tt>, <tt class="literal">uucp</tt>, and the like. You +can set a global +<tt class="literal">invalid</tt><a name="INDEX-17"/> <tt class="literal">users</tt> option +to protect against this.</p> +</li><li> +<p>The meaning of the +<tt class="literal">browsable</tt><a name="INDEX-18"/> configuration option is +different from other shares; it indicates only that a +<tt class="literal">[homes]</tt> section won't show up in +the local browse list, not that the <tt class="literal">[alice]</tt> share +won't. When the <tt class="literal">[alice]</tt> section +is created (after the initial connection), it will use the +<tt class="literal">browsable</tt> value from the +<tt class="literal">[globals]</tt> section for that share, not the value +from <tt class="literal">[homes]</tt>.</p> +</li></ul> +<p>As we mentioned, there is no need for a path statement in +<tt class="literal">[homes]</tt> if the users have Unix home directories in +the server's <em class="filename">/etc/passwd</em> file. +You should ensure that a valid home directory does exist, however, as +Samba will not automatically create a home directory for a user and +will refuse a tree connect if the user's directory +does not exist or is not accessible. <a name="INDEX-19"/></p> + + +</div> + + +</div> + + + +<div class="sect1"><a name="samba2-CHP-9-SECT-2"/> + +<h2 class="head1">Controlling Access to Shares</h2> + +<p><a name="INDEX-20"/><a name="INDEX-21"/>Often you will need to restrict the users who +can access a specific share for security reasons. This is very easy +to do with Samba because it contains a wealth of options for creating +practically any security configuration. Let's +introduce a few configurations that you might want to use in your own +Samba setup.</p> + +<p>We've seen what happens when you specify valid +users. However, you are also allowed to specify a list of +<a name="INDEX-22"/>invalid users—users who should never be +allowed access to Samba or its shares. This is done with the +<tt class="literal">invalid</tt><a name="INDEX-23"/> <tt class="literal">users</tt> +option. We hinted at one frequent use of this option earlier: a +global default with the <tt class="literal">[homes]</tt> section to ensure +that various system users and superusers cannot be forged for access. +For example:</p> + +<blockquote><pre class="code">[global] + invalid users = root bin daemon adm sync shutdown \ + halt mail news uucp operator + auto services = dave peter bob + +[homes] + browsable = no + writable = yes</pre></blockquote> + +<p>The <tt class="literal">invalid</tt> <tt class="literal">users</tt> option, like +<tt class="literal">valid</tt> <tt class="literal">users</tt>, can take group +names, preceded by an at sign (<tt class="literal">@</tt>), as well as +usernames. In the event that a user or group appears in both lists, +the <tt class="literal">invalid</tt> <tt class="literal">users</tt> option takes +precedence, and the user or group is denied access to the share.</p> + +<p>At the other end of the spectrum, you can explicitly specify users +who will be allowed <a name="INDEX-24"/><a name="INDEX-25"/>superuser (root) access to a share with +the <tt class="literal">admin</tt><a name="INDEX-26"/> <tt class="literal">users</tt> +option. An example follows:</p> + +<blockquote><pre class="code">[sales] + path = /home/sales + comment = Sedona Real Estate Sales Data + writable = yes + valid users = sofie shelby adilia + admin users = mike</pre></blockquote> + +<p>This option takes both group names and usernames. In addition, you +can specify NIS netgroups by preceding them with an +<tt class="literal">@</tt> as well; if the netgroup is not found, Samba +will assume that you are referring to a standard Unix group.</p> + +<p>Be careful if you assign administrative privileges to a share for an +entire group. The Samba Team highly recommends you avoid using this +option, as it essentially gives root access to the specified users or +groups for that share.</p> + +<p>If you wish to force read-only or read/write access on users who +access a share, you can do so with the +<tt class="literal">read</tt><a name="INDEX-27"/> <tt class="literal">list</tt> and +<tt class="literal">write</tt> <tt class="literal">list</tt> options, +respectively. These options can be used on a per-share basis to +restrict a writable share or to grant write access to specific users +in a read-only share, respectively. For example:</p> + +<blockquote><pre class="code">[sales] + path = /home/sales + comment = Sedona Real Estate Sales Data + read only = yes + write list = sofie shelby</pre></blockquote> + +<p>The <tt class="literal">write</tt><a name="INDEX-28"/> <tt class="literal">list</tt> option +cannot override Unix permissions. If you've created +the share without giving the <tt class="literal">write-list</tt> user write +permission on the Unix system, she will be denied write access +regardless of the setting of <tt class="literal">write</tt> +<tt class="literal">list</tt>.</p> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-2.1"/> + +<h3 class="head2">Guest Access</h3> + +<p><a name="INDEX-29"/>As mentioned +earlier, you can configure a share using +<tt class="literal">guest</tt><a name="INDEX-30"/> <tt class="literal">ok</tt> +<tt class="literal">=</tt> <tt class="literal">yes</tt> to allow access to guest +users. This works only when using share-level security, which we will +cover later in this chapter. When a user connects as a guest, +authenticating with a username and password is unnecessary, but Samba +still needs a way to map the connected client to a user on the local +system. The <tt class="literal">guest</tt><a name="INDEX-31"/> +<tt class="literal">account</tt> parameter can be used in the share to +specify the Unix account that guest users should be assigned when +connecting to the Samba server. The default value for this is set +during compilation and is typically <tt class="literal">nobody</tt>, which +works well with most Unix versions. However, on some systems the +<tt class="literal">nobody</tt><a name="INDEX-32"/> account is not allowed to access some +services (e.g., printing), and you might need to set the guest user +to <tt class="literal">ftp</tt> or some other account instead.</p> + +<p>If you wish to restrict access in a share only to guests—in +other words, all clients connect as the guest account when accessing +the share—you can use the <tt class="literal">guest</tt> +<tt class="literal">only</tt> option in conjunction with the +<tt class="literal">guest</tt> <tt class="literal">ok</tt> option, as shown in +the following example:</p> + +<blockquote><pre class="code">[sales] + path = /home/sales + comment = Sedona Real Estate Sales Data + writable = yes + guest ok = yes + guest account = ftp + guest only = yes</pre></blockquote> + +<p>Make sure you specify <tt class="literal">yes</tt> for both +<tt class="literal">guest</tt> <tt class="literal">only</tt> and +<tt class="literal">guest</tt> <tt class="literal">ok</tt>; otherwise, Samba will +not use the guest account that you specify.</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-2.2"/> + +<h3 class="head2">Access Control Options</h3> + +<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 +to control access to shares.</p> + +<a name="samba2-CHP-9-TABLE-1"/><h4 class="head4">Table 9-1. Share-level access options</h4><table border="1"> + + + + + + +<tr> +<th> +<p>Option</p> +</th> +<th> +<p>Parameters</p> +</th> +<th> +<p>Function</p> +</th> +<th> +<p>Default</p> +</th> +<th> +<p>Scope</p> +</th> +</tr> + + +<tr> +<td> +<p><tt class="literal">admin users</tt></p> +</td> +<td> +<p>string (list of usernames)</p> +</td> +<td> +<p>Users who can perform operations as root</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Share</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">valid users</tt></p> +</td> +<td> +<p>string (list of usernames)</p> +</td> +<td> +<p>Users who can connect to a share</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Share</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">invalid users</tt></p> +</td> +<td> +<p>string (list of usernames)</p> +</td> +<td> +<p>Users who will be denied access to a share</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Share</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">read list</tt></p> +</td> +<td> +<p>string (list of usernames)</p> +</td> +<td> +<p>Users who have read-only access to a writable share</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Share</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">write list</tt></p> +</td> +<td> +<p>string (list of usernames)</p> +</td> +<td> +<p>Users who have read/write access to a read-only share</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Share</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">max connections</tt></p> +</td> +<td> +<p>numeric</p> +</td> +<td> +<p>Maximum number of connections for a share at a given time</p> +</td> +<td> +<p><tt class="literal">0</tt></p> +</td> +<td> +<p>Share</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">guest only</tt> <tt class="literal">(only guest)</tt></p> +</td> +<td> +<p>Boolean</p> +</td> +<td> +<p>If <tt class="literal">yes</tt>, allows only guest access</p> +</td> +<td> +<p><tt class="literal">no</tt></p> +</td> +<td> +<p>Share</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">guest account</tt></p> +</td> +<td> +<p>string (name of account)</p> +</td> +<td> +<p>Unix account that will be used for guest access</p> +</td> +<td> +<p><tt class="literal">nobody</tt></p> +</td> +<td> +<p>Share</p> +</td> +</tr> + +</table> + + +<div class="sect3"><a name="samba2-CHP-9-SECT-2.2.1"/> + +<a name="INDEX-35"/><h3 class="head3">admin users</h3> + +<p>This option specifies a list of users that perform file operations as +if they were <tt class="literal">root</tt>. This means that they can modify +or destroy any other user's files, regardless of the +permissions. Any files that they create will have root ownership and +will use the default group of the admin user. The +<tt class="literal">admin</tt> <tt class="literal">users</tt> option allows PC +users to act as administrators for particular shares. Be very careful +when using this option, and make sure good password and other +security policies are in place.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-2.2.2"/> + +<a name="INDEX-36"/><a name="INDEX-37"/><h3 class="head3">valid users, invalid users</h3> + +<p>These two options let you enumerate the users and groups who are +granted or denied access to a particular share. You can enter a list +of user and/or group names. If a name is prefixed by an at sign +(<tt class="literal">@</tt>), it is interpreted as a group name—with +NIS groups searched before Unix groups. If the name is prefixed by a +plus sign (<tt class="literal">+</tt>), it is interpreted as the name of a +Unix group, and NIS is not searched. If the name is prefixed by an +ampersand (<tt class="literal">&</tt>), it is interpreted as an NIS +group name rather than as a Unix group name. The plus sign and +ampersand can be used together to specify whether NIS or Unix groups +are searched first. For example:</p> + +<blockquote><pre class="code">[database] + valid users = mary ellen sue &sales +marketing @dbadmin + invalid users = gavin syd dana &techies +&helpdesk</pre></blockquote> + +<p>In the <tt class="literal">valid</tt> <tt class="literal">users</tt> parameter, +users <tt class="literal">mary</tt>, <tt class="literal">ellen</tt>, and +<tt class="literal">sue</tt> are allowed access to the +<tt class="literal">[database]</tt> share, as are the members of the Unix +group <tt class="literal">marketing</tt> and NIS/Unix group +<tt class="literal">dbadmin</tt>. The <tt class="literal">invalid</tt> +<tt class="literal">users</tt> parameter denies access to the share by +users <tt class="literal">gavin</tt>, <tt class="literal">syd</tt>, and +<tt class="literal">dana</tt>, as well as members of the NIS group +<tt class="literal">techies</tt> and Unix/NIS group +<tt class="literal">helpdesk</tt>. In this last case, the list of Unix +groups is searched first for the <tt class="literal">helpdesk</tt> group, +and if it is not found there, the list of NIS groups is searched.</p> + +<p>The important rule to remember with these options is that any name or +group in the <tt class="literal">invalid</tt> <tt class="literal">users</tt> list +will <em class="emphasis">always</em> be denied access, even if it is +included (in any form) in the <tt class="literal">valid</tt> +<tt class="literal">users</tt> list.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-2.2.3"/> + +<a name="INDEX-38"/><a name="INDEX-39"/><h3 class="head3">read list, write list</h3> + +<p>Like the <tt class="literal">valid</tt> <tt class="literal">users</tt> +<tt class="literal">and</tt> <tt class="literal">invalid</tt> +<tt class="literal">users</tt> options, this pair of options specifies +which users have read-only access to a writable share and read/write +access to a read-only share, respectively. The value of either +options is a list of users. The <tt class="literal">read</tt> +<tt class="literal">list</tt> parameter overrides any other Samba +permissions granted—as well as Unix file permissions on the +server system—to deny users write access. +<tt class="literal">The</tt> <tt class="literal">write</tt> +<tt class="literal">list</tt> parameter overrides other Samba permissions +to grant write access, but cannot grant write access if the user +lacks write permissions for the file on the Unix system. You can +specify NIS or Unix group names by prefixing the name with an at sign +(such as <tt class="literal">@users</tt>). Neither configuration option has +a default value associated with it.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-2.2.4"/> + +<a name="INDEX-40"/><h3 class="head3">max connections</h3> + +<p>This option specifies the maximum number of client connections that a +share can have at any given time. Any connections that are attempted +after the maximum is reached will be rejected. The default value is +<tt class="literal">0</tt>, which is a special case that allows an +unlimited number of connections. You can override it per share as +follows:</p> + +<blockquote><pre class="code">[accounting] + max connections = 30</pre></blockquote> + +<p>This option is useful in the event that you need to limit the number +of users who are accessing a licensed program or piece of data +concurrently.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-2.2.5"/> + +<a name="INDEX-41"/><h3 class="head3">guest only</h3> + +<p>This share-level option (also called <tt class="literal">only</tt> +<tt class="literal">guest</tt>) forces a connection to a share to be +performed with the user specified by the <tt class="literal">guest</tt> +<tt class="literal">account</tt> option. The share to which this is applied +must explicitly specify <tt class="literal">guest</tt> +<tt class="literal">ok</tt> <tt class="literal">=</tt> <tt class="literal">yes</tt> for +this option to be recognized by Samba. The default value for this +option is <tt class="literal">no</tt>.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-2.2.6"/> + +<a name="INDEX-42"/><h3 class="head3">guest account</h3> + +<p>This option specifies the name of the account to be used for guest +access to shares in Samba. The default for this option varies from +system to system, but it is often set to <tt class="literal">nobody</tt>. +Some default user accounts have trouble connecting as guest users. If +that occurs on your system, the Samba Team recommends using the +<tt class="literal">ftp</tt> account as the guest user. <a name="INDEX-43"/> <a name="INDEX-44"/><a name="INDEX-45"/></p> + + +</div> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-2.3"/> + +<h3 class="head2">Username Options</h3> + +<p><a href="ch09.html#samba2-CHP-9-TABLE-2">Table 9-2</a> shows two additional options that Samba +can use to correct for incompatibilities in usernames between Windows +and Unix.</p> + +<a name="samba2-CHP-9-TABLE-2"/><h4 class="head4">Table 9-2. Username options</h4><table border="1"> + + + + + + +<tr> +<th> +<p>Option</p> +</th> +<th> +<p>Parameters</p> +</th> +<th> +<p>Function</p> +</th> +<th> +<p>Default</p> +</th> +<th> +<p>Scope</p> +</th> +</tr> + + +<tr> +<td> +<p><tt class="literal">username</tt> <tt class="literal">map</tt></p> +</td> +<td> +<p>string (filename)</p> +</td> +<td> +<p>Sets the name of the username mapping file</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">username</tt> <tt class="literal">level</tt></p> +</td> +<td> +<p>numeric</p> +</td> +<td> +<p>Indicates the number of capital letters to use when trying to match a +username</p> +</td> +<td> +<p><tt class="literal">0</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> + +</table> + + +<div class="sect3"><a name="samba2-CHP-9-SECT-2.3.1"/> + +<a name="INDEX-46"/><h3 class="head3">username map</h3> + +<p>Client usernames on an SMB network can be relatively long (up to 255 +characters), while usernames on a Unix network often cannot be longer +than eight characters. This means that an individual user can have +one username on a client and another (shorter) one on the Samba +server. You can get past this issue by<em class="firstterm"> +</em><a name="INDEX-47"/>mapping a free-form client +username to a Unix username of eight or fewer characters. It is +placed in a standard text file, using a format that +we'll describe shortly. You can then specify the +pathname to Samba with the global <tt class="literal">username</tt> +<tt class="literal">map</tt> option. Be sure to restrict access to this +file; make the root user the file's owner and deny +write access to others (with octal permissions of 744 or 644). +Otherwise, an untrusted user with access to the file can easily map +his client username to the root user of the Samba server.</p> + +<p>You can specify this option as follows:</p> + +<blockquote><pre class="code">[global] + username map = /usr/local/samba/private/usermap.txt</pre></blockquote> + +<p>Each entry in the username map file should be listed as follows: the +Unix username, followed by an equal sign (<tt class="literal">=</tt>), +followed by one or more whitespace-separated SMB client usernames. +Note that unless instructed otherwise (i.e., a guest connection), +Samba will expect both the client and the server user to have the +same password. You can also map NT groups to one or more specific +Unix groups using the <tt class="literal">@</tt> sign. Here are some +examples:</p> + +<blockquote><pre class="code">jarwin = JosephArwin +manderso = MarkAnderson +users = @account</pre></blockquote> + +<p>You can also use the asterisk to specify a wildcard that matches any +free-form client username as an entry in the username map file:</p> + +<blockquote><pre class="code">nobody = *</pre></blockquote> + +<p>Comments can be placed in the file by starting the line with a hash +mark (<tt class="literal">#</tt>) or a semicolon (<tt class="literal">;</tt>).</p> + +<p>Note that you can also use this file to redirect one Unix user to +another user. Be careful, though, as Samba and your client might not +notify the user that the mapping has been made and Samba might be +expecting a different password.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-2.3.2"/> + +<a name="INDEX-48"/><h3 class="head3">username level</h3> + +<p>SMB clients (such as Windows) will often send usernames in SMB +connection requests entirely in capital letters; in other words, +client usernames are not necessarily case-sensitive. On a Unix +server, however, usernames <em class="emphasis">are</em> case-sensitive: +the user <tt class="literal">ANDY</tt> is different from the user +<tt class="literal">andy</tt>. By default, Samba attacks this problem by +doing the following:</p> + +<ol><li> +<p>Checking for a user account with the exact name sent by the client</p> +</li><li> +<p>Testing the username in all lowercase letters</p> +</li><li> +<p>Testing the username in lowercase letters with only the first letter +capitalized</p> +</li></ol> +<p>If you wish to have Samba attempt more combinations of upper- and +lowercase letters, you can use the <tt class="literal">username</tt> +<tt class="literal">level</tt> global configuration option. This option +takes an integer value that specifies how many letters in the +username should be capitalized when attempting to connect to a share. +You can specify this option as follows:</p> + +<blockquote><pre class="code">[global] + username level = 3</pre></blockquote> + +<p>In this case, Samba attempts all possible permutations of usernames +having three capital letters. The larger the number, the more +computations Samba has to perform to match the username, and the +longer the authentication will take.</p> + + +</div> + + +</div> + + +</div> + + + +<div class="sect1"><a name="samba2-CHP-9-SECT-3"/> + +<h2 class="head1">Authentication of Clients</h2> + +<p><a name="INDEX-49"/>At +this point, we should discuss how Samba authenticates users. Each +user who attempts to connect to a share not allowing guest access +must provide a password to +<a name="INDEX-50"/>make a successful connection. What +Samba does with that password—and consequently the strategy +Samba will use to handle user authentication—is the arena of +the <tt class="literal">security</tt> configuration option. Samba currently +supports <a name="INDEX-51"/><a name="INDEX-52"/><a name="INDEX-53"/>four +<a name="INDEX-54"/>security levels on its network: +<em class="firstterm">share</em>, <em class="firstterm">user</em>, +<em class="firstterm">server</em>, and <em class="firstterm">domain</em>.</p> + +<dl> +<dt><b><a name="INDEX-55"/>Share-level security</b></dt> +<dd> +<p>Each share in the workgroup has one or more passwords associated with +it. Anyone who knows a valid password for the share can access it.</p> +</dd> + + + +<dt><b><a name="INDEX-56"/>User-level security</b></dt> +<dd> +<p>Each share in the workgroup is configured to allow access from +certain users. With each initial tree connection, the Samba server +verifies users and their passwords to allow them access to the share.</p> +</dd> + + + +<dt><b><a name="INDEX-57"/>Server-level security</b></dt> +<dd> +<p>This is the same as user-level security, except that the Samba server +uses another server to validate users and their passwords before +granting access to the share.</p> +</dd> + + + +<dt><b><a name="INDEX-58"/>Domain-level security</b></dt> +<dd> +<p>Samba becomes a member of a Windows NT domain and uses one of the +domain's domain controllers—either the PDC or +a BDC—to perform authentication. Once authenticated, the user +is given a special token that allows her access to any share with +appropriate access rights. With this token, the domain controller +will not have to revalidate the user's password each +time she attempts to access another share within the domain. The +domain controller can be a Windows NT/2000 PDC or BDC, or Samba +acting as a Windows NT PDC.</p> +</dd> + +</dl> + +<p>Each security policy can be implemented with the global +<tt class="literal">security</tt> option, as shown in <a href="ch09.html#samba2-CHP-9-TABLE-3">Table 9-3</a>.</p> + +<a name="samba2-CHP-9-TABLE-3"/><h4 class="head4">Table 9-3. Security option</h4><table border="1"> + + + + + + +<tr> +<th> +<p>Option</p> +</th> +<th> +<p>Parameters</p> +</th> +<th> +<p>Function</p> +</th> +<th> +<p>Default</p> +</th> +<th> +<p>Scope</p> +</th> +</tr> + + +<tr> +<td> +<p><tt class="literal">security</tt><a name="INDEX-59"/></p> +</td> +<td> +<p><tt class="literal">domain</tt>, <tt class="literal">server</tt>, +<tt class="literal">share</tt>, or <tt class="literal">user</tt></p> +</td> +<td> +<p>Indicates the type of security that the Samba server will use</p> +</td> +<td> +<p><tt class="literal">user</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> + +</table> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-3.1"/> + +<h3 class="head2">Share-Level Security</h3> + +<p>With share-level security, each share has one or more passwords +associated with it, with the client being authenticated when first +connecting to the share. This differs from the other modes of +security in that there are no restrictions as to whom can access a +share, as long as that individual knows the correct password. Shares +often have multiple passwords. For example, one password might grant +read-only access, while another might grant read/write access. +Security is maintained as long as unauthorized users do not discover +the password for a share to which they shouldn't +have access.</p> + +<p>OS/2 and Windows 95/98/Me both support share-level security on their +resources. You can set up share-level security with Windows 95/98/Me +by first enabling share-level security using the Access Control tab +of the Network Control Panel dialog. Then select the +"Share-level access control" radio +button (which deselects the "User-level access +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> + +<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> + +<p>Next, right-click a resource—such as a hard drive or a +CD-ROM—and select the Properties menu item. This will bring up +the Resource Properties dialog box. Select the Sharing tab at the top +of the dialog box, and enable the resource as Shared As. From here, +you can configure how the shared resource will appear to individual +users, as well as assign whether the resource will appear as +read-only, read/write, or a mix, depending on the password that is +supplied.</p> + +<p>You might be thinking that this security model is not a good fit for +Samba—and you would be right. In fact, if you set the +<tt class="literal">security</tt> <tt class="literal">=</tt> +<tt class="literal">share</tt> option in the Samba configuration file, +Samba will still reuse the username/password combinations in the +system password files to authenticate access. More precisely, Samba +will take the following steps when a client requests a connection +using share-level security:</p> + +<ol><li> +<p>When a connection is requested, Samba will accept the password and +(if sent) the username of the client.</p> +</li><li> +<p>If the share is <tt class="literal">guest</tt> <tt class="literal">only</tt> , +the user is immediately granted access to the share with the rights +of the user specified by the <tt class="literal">guest</tt> +<tt class="literal">account</tt> parameter; no password checking is +performed.</p> +</li><li> +<p>For other shares, Samba appends the username to a list of users who +are allowed access to the share. It then attempts to validate the +password given in association with that username. If successful, +Samba grants the user access to the share with the rights assigned to +that user. The user will not need to authenticate again unless a +<tt class="literal">revalidate</tt> <tt class="literal">=</tt> +<tt class="literal">yes</tt> option has been set inside the share.</p> +</li><li> +<p>If the authentication is unsuccessful, Samba attempts to validate the +password against the list of users previously compiled during +attempted connections, as well as those specified under the share in +the configuration file. If the password matches that of any username +(as specified in the system password file, typically +<em class="filename">/etc/passwd </em>), the user is granted access to the +share under that username.</p> +</li><li> +<p>However, if the share has a <tt class="literal">guest</tt> +<tt class="literal">ok</tt> or <tt class="literal">public</tt> option set, the +user will default to access with the rights of the user specified by +the <tt class="literal">guest</tt> <tt class="literal">account</tt> option.</p> +</li></ol> +<p>You can indicate in the configuration file which users should be +initially placed on the share-level security user list by using the +<tt class="literal">username</tt> configuration option, as shown here:</p> + +<blockquote><pre class="code">[global] + security = share + +[accounting1] + path = /home/samba/accounting1 + guest ok = no + writable = yes + username = davecb, pkelly, andyo</pre></blockquote> + +<p>Here, when a user attempts to connect to a share, Samba verifies the +sent password against each user in its own list, in addition to the +passwords of users <tt class="literal">davecb</tt>, +<tt class="literal">pkelly</tt>, and <tt class="literal">andyo</tt>. If any of +the passwords match, the connection is verified, and the user is +allowed. Otherwise, connection to the specific share will fail.</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-3.2"/> + +<h3 class="head2">Share-Level Security Options</h3> + +<p><a href="ch09.html#samba2-CHP-9-TABLE-4">Table 9-4</a> shows the options typically associated +with <em class="firstterm">share-level +security</em><a name="INDEX-60"/>.</p> + +<a name="samba2-CHP-9-TABLE-4"/><h4 class="head4">Table 9-4. Share-level access options</h4><table border="1"> + + + + + + +<tr> +<th> +<p>Option</p> +</th> +<th> +<p>Parameters</p> +</th> +<th> +<p>Function</p> +</th> +<th> +<p>Default</p> +</th> +<th> +<p>Scope</p> +</th> +</tr> + + +<tr> +<td> +<p><tt class="literal">only user</tt></p> +</td> +<td> +<p>Boolean</p> +</td> +<td> +<p>If <tt class="literal">yes</tt>, usernames specified by +<tt class="literal">username</tt> are the only ones allowed</p> +</td> +<td> +<p><tt class="literal">no</tt></p> +</td> +<td> +<p>Share</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">username</tt> (<tt class="literal">user</tt> or +<tt class="literal">users</tt>)</p> +</td> +<td> +<p>string (list of usernames)</p> +</td> +<td> +<p>Users against which a client's password is tested</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Share</p> +</td> +</tr> + +</table> + + +<div class="sect3"><a name="samba2-CHP-9-SECT-3.2.1"/> + +<a name="INDEX-61"/><h3 class="head3">only user</h3> + +<p>This Boolean option indicates whether Samba will allow connections to +a share using share-level security based solely on the individuals +specified in the <tt class="literal">username</tt> option, instead of those +users compiled on Samba's internal list. The default +value for this option is <tt class="literal">no</tt>. You can override it +per share as follows:</p> + +<blockquote><pre class="code">[global] + security = share +[data] + username = andy, peter, valerie + only user = yes</pre></blockquote> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-3.2.2"/> + +<a name="INDEX-62"/><h3 class="head3">username</h3> + +<p>This option presents a list of usernames and/or group names against +which Samba tests a connection password to allow access. It is +typically used with clients that have share-level security to allow +connections to a particular service based solely on a qualifying +password—in this case, one that matches a password set up for a +specific user:</p> + +<blockquote><pre class="code">[global] + security = share +[data] + username = andy, peter, terry</pre></blockquote> + +<p>You can enter a list of usernames and/or group names. If a name is +prefixed by an at sign (<tt class="literal">@</tt>), it is interpreted as a +group name, with NIS groups searched before Unix groups. If the name +is prefixed by a plus sign (<tt class="literal">+</tt>), it is interpreted +as the name of a Unix group, and NIS is not searched. If the name is +prefixed by an ampersand (<tt class="literal">&</tt>), it is +interpreted as an NIS group name rather than a Unix group name. The +plus sign and ampersand can be used together to specify whether NIS +or Unix groups are searched first. When Samba encounters a group name +in this option, it attempts to authenticate each user in the group +until if finds one that succeeds. Beware that this can be very +inefficient.</p> + +<p>We recommend against using this option unless you are implementing a +Samba server with share-level security.</p> + + +</div> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-3.3"/> + +<h3 class="head2">User-Level Security</h3> + +<p>The default mode of security with Samba is <em class="firstterm">user-level +security</em><a name="INDEX-63"/>. With this method, each share is +assigned specific users that can access it. When a user requests a +connection to a share, Samba authenticates by validating the given +username and password with the authorized users in the configuration +file and the passwords in the password database of the Samba server. +As mentioned earlier in the chapter, one way to isolate which users +are allowed access to a specific share is by using the +<tt class="literal">valid</tt> <tt class="literal">users</tt> option for each +share:</p> + +<blockquote><pre class="code">[global] + security = user + +[accounting1] + writable = yes + valid users = bob, joe, sandy</pre></blockquote> + +<p>Each user listed can connect to the share if the password provided +matches the password stored in the system password database on the +server. Once the initial authentication succeeds, the client will not +need to supply a password again to access that share unless the +<tt class="literal">revalidate</tt> <tt class="literal">=</tt> +<tt class="literal">yes</tt> option has been set.</p> + +<p>Passwords can be sent to the Samba server in either an encrypted or a +nonencrypted format. If you have both types of systems on your +network, you should ensure that the passwords represented by each +user are stored both in a traditional account database and +Samba's encrypted password database. This way, +authorized users can gain access to their shares from any type of +client.<a name="FNPTR-1"/><a href="#FOOTNOTE-1">[1]</a> However, we recommend that you +move your system to encrypted passwords and abandon nonencrypted +passwords if security is an issue. <a href="ch09.html#samba2-CHP-9-SECT-4">Section 9.4</a> of this chapter +explains how to use encrypted as well as nonencrypted passwords.</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-3.4"/> + +<h3 class="head2">Server-Level Security</h3> + +<p><em class="firstterm">Server-level +security</em><a name="INDEX-64"/> is similar to user-level security. +However, with server-level security, Samba delegates password +authentication to another SMB password server—typically another +Samba server or a Windows NT/2000 server acting as a PDC on the +network. Note that Samba still maintains its list of shares and their +configuration in its <em class="filename">smb.conf</em> file. When a +client attempts to make a connection to a particular share, Samba +validates that the user is indeed authorized to connect to the share. +Samba then attempts to validate the password by passing the username +and password to the SMB password server. If the password is accepted, +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> + +<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> + +<p>You can configure Samba to use a separate password server under +server-level security with the use of the +<tt class="literal">password</tt><a name="INDEX-65"/> <tt class="literal">server</tt> +global configuration option, as follows:</p> + +<blockquote><pre class="code">[global] + security = server + password server = mixtec toltec</pre></blockquote> + +<p>Note that you can specify more than one machine as the target of the +<tt class="literal">password</tt> <tt class="literal">server</tt>; Samba moves +down the list of servers in the event that its first choice is +unreachable. The servers identified by the +<tt class="literal">password</tt> <tt class="literal">server</tt> option are +given as NetBIOS names, not their DNS names or equivalent IP +addresses. Also, if any of the servers reject the given password, the +connection automatically fails—Samba will not attempt another +server.</p> + +<p>One caveat: when using this option, you still need an account +representing that user on the regular Samba server. This is because +the Unix operating system needs a username to perform various I/O +operations. The preferable method of handling this is to give the +user an account on the Samba server but disable the +account's password by replacing it in the system +password file (e.g., <em class="filename">/etc/passwd </em>) with an +asterisk (*).</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-3.5"/> + +<h3 class="head2">Domain-Level Security</h3> + +<p>With <em class="firstterm">domain-level +security</em><a name="INDEX-66"/>, the Samba server acts as a member of +a Windows domain. Recall from <a href="ch01.html">Chapter 1</a> that each +domain has a primary domain controller, which can be a Windows +NT/2000 or Samba server offering password authentication. The domain +controller keeps track of users and passwords in its own database and +authenticates each user when she first logs on and wishes to access +another machine's shares.</p> + +<p>As mentioned earlier in this chapter, Samba has a similar ability to +offer user-level security, but that option is Unix-centric and +assumes that the authentication occurs via Unix password files. If +the Unix machine is part of an NIS or NIS+ domain, Samba +authenticates users transparently against a shared password file in +typical Unix fashion. Samba then provides access to the NIS or NIS+ +domain from Windows. There is, of course, no relationship between the +NIS concept of a domain and a Windows NT domain.</p> + +<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> + + +</div> + + +</div> + + + +<div class="sect1"><a name="samba2-CHP-9-SECT-4"/> + +<h2 class="head1">Passwords</h2> + +<p><a name="INDEX-68"/>Passwords +are a thorny issue with Samba. So much so, in fact, that they are +often the first major problem that users encounter when they install +Samba. At this point, we need to delve deeper into Samba to discover +what is happening on the network.</p> + +<p>Passwords sent from individual clients can be either encrypted or +nonencrypted. Encrypted passwords are, of course, more secure. A +nonencrypted, plain-text password can be easily read with a +packet-sniffing program, such as the modified +<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 +depends on the operating system that the client is using to connect +to the Samba server. <a href="ch09.html#samba2-CHP-9-TABLE-5">Table 9-5</a> lists which +<a name="INDEX-69"/>Windows operating +systems encrypt their passwords and which send plain-text passwords +by default.</p> + +<a name="samba2-CHP-9-TABLE-5"/><h4 class="head4">Table 9-5. Windows operating systems with encrypted passwords</h4><table border="1"> + + + +<tr> +<th> +<p>Operating system</p> +</th> +<th> +<p>Encrypted or plain text</p> +</th> +</tr> + + +<tr> +<td> +<p>Windows for Workgroups</p> +</td> +<td> +<p>Plain text</p> +</td> +</tr> +<tr> +<td> +<p>Windows 95</p> +</td> +<td> +<p>Plain text</p> +</td> +</tr> +<tr> +<td> +<p>Windows 95 with SMB Update</p> +</td> +<td> +<p>Encrypted</p> +</td> +</tr> +<tr> +<td> +<p>Windows 98</p> +</td> +<td> +<p>Encrypted</p> +</td> +</tr> +<tr> +<td> +<p>Windows Me</p> +</td> +<td> +<p>Encrypted</p> +</td> +</tr> +<tr> +<td> +<p>Windows NT 3.x</p> +</td> +<td> +<p>Plain text</p> +</td> +</tr> +<tr> +<td> +<p>Windows NT 4.0 before SP <tt class="literal">3</tt></p> +</td> +<td> +<p>Plain text</p> +</td> +</tr> +<tr> +<td> +<p>Windows NT 4.0 after SP 3</p> +</td> +<td> +<p>Encrypted</p> +</td> +</tr> +<tr> +<td> +<p>Windows 2000</p> +</td> +<td> +<p>Encrypted</p> +</td> +</tr> +<tr> +<td> +<p>Windows XP</p> +</td> +<td> +<p>Encrypted</p> +</td> +</tr> + +</table> + +<p>Three different encryption methods are used. Windows 95/98/Me clients +use a method inherited from Microsoft's LAN Manager +network software. Windows NT/2000/XP systems use a newer system, +called NT LAN Manager, or NTLM. A newer version of this (called NT +LAN Manager Version 2, or NTLMv2) uses a different method for +password hashing.</p> + +<p>If encrypted passwords are supported, Samba stores the encrypted +passwords in a file called <em class="filename">smbpasswd</em>. By +default, this file is located in the <em class="filename">private</em> +directory of the Samba distribution (typically +<em class="filename">/usr/local/samba/private</em>). At the same time, the +client stores an encrypted version of a user's +password on its own system. The plain-text password is never stored +on either system. Each system encrypts the password automatically +using a standard algorithm when the password is set or changed.</p> + +<p>When a client requests a connection to an SMB server that supports +encrypted passwords (such as Samba or Windows NT/2000/XP), the two +computers undergo the following negotiations:</p> + +<ol><li> +<p>The client attempts to negotiate a protocol with the server.</p> +</li><li> +<p>The server responds with a protocol and indicates that it supports +encrypted passwords. At this time, it sends back a randomly generated +8-byte challenge string.</p> +</li><li> +<p>The client uses the challenge string as a key to encrypt its already +encrypted password using an algorithm predefined by the negotiated +protocol. It then sends the result to the server.</p> +</li><li> +<p>The server does the same thing with the encrypted password stored in +its database. If the results match, the passwords are equivalent, and +the user is authenticated.</p> +</li></ol> +<p>Note that even though the original passwords are not involved in the +authentication process, you need to be very careful that the +encrypted passwords located inside the <em class="filename">smbpasswd</em> +file are guarded from unauthorized users. If they are compromised, an +unauthorized user can break into the system by replaying the steps of +the previous algorithm. The encrypted passwords are just as sensitive +as the plain-text passwords—this is known as +<em class="firstterm">plain-text-equivalent</em> data in the cryptography +world. Of course, your local security policy should require that the +clients safeguard their plain-text-equivalent passwords as well.</p> + +<p>You can configure Samba to accept encrypted passwords with the +following global additions to <em class="filename">smb.conf</em>. Note +that we explicitly name the location of the Samba password file:</p> + +<blockquote><pre class="code">[global] + security = user + encrypt passwords = yes + smb passwd file = /usr/local/samba/private/smbpasswd</pre></blockquote> + +<p>Samba, however, will not accept any users until the +<em class="filename">smbpasswd</em> file has been created and the users +have been added to it with the <em class="emphasis">smbpasswd</em> +command, as we showed you in <a href="ch02.html">Chapter 2</a>.</p> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-4.1"/> + +<h3 class="head2">Disabling Encrypted Passwords on the Client</h3> + +<p><a name="INDEX-70"/><a name="INDEX-71"/>While Unix authentication has been +in use for decades—including the use of +<em class="emphasis">telnet</em> and <em class="emphasis">rlogin</em> access +across the Internet—it embodies well-known security risks. +Plaintext passwords are sent over the Internet and can be retrieved +from TCP packets by malicious snoopers. However, if you feel that +your network is secure and you wish to use standard Unix +<em class="filename">/etc/passwd</em> authentication for all clients, you +can do so, but you must disable encrypted passwords on those Windows +clients that default to using them.</p> + +<p>To do this, you must modify the Windows registry on each client +system. The Samba distribution includes the <em class="filename">.reg</em> +files you need for this, located in the source +distribution's <em class="filename">/docs/Registry</em> +directory. Depending on the platform, you use one of the following +files:</p> + +<blockquote class="simplelist"> + +<p><em class="filename">Win95_PlainPassword.reg</em></p> + +<p><em class="filename">Win98_PlainPassword.reg</em></p> + +<p><em class="filename">WinME_PlainPassword.reg</em></p> + +<p><em class="filename">NT_PlainPassword.reg</em></p> + +<p><em class="filename">Win2000_PlainPassword.reg</em></p> + +</blockquote> + +<p>(For Windows XP, use the <em class="filename">.reg</em> file for Windows +2000.) You can perform the installation by copying the appropriate +<em class="filename">.reg</em> file to a DOS floppy, inserting the floppy +in the client's floppy drive, and running the +<em class="filename">.reg</em> file from the Run menu item in the +client's Start menu. (Or you can just double-click +the file's icon.)</p> + +<p>After you reboot the machine, the client will not encrypt its hashed +passwords before sending them to the server. This means that the +plain-text passwords can been seen in the TCP packets that are +broadcast across the network. Again, we encourage you not to do this +unless you are absolutely sure that your network is secure.</p> + +<p>If passwords are not encrypted, use these two lines in your Samba +configuration file:</p> + +<blockquote><pre class="code">[global] + security = user + encrypt passwords = no</pre></blockquote> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-4.2"/> + +<h3 class="head2">The smbpasswd File</h3> + +<p>Samba stores its encrypted passwords in a file called +<em class="filename">smbpasswd</em><a name="INDEX-72"/>, +which by default resides in the +<em class="filename">/usr/local/samba/private</em> directory. The +<em class="filename">smbpasswd</em> file should be guarded as closely as +the Unix system's password file (either +<em class="filename">/etc/passwd</em> or +<em class="filename">/etc/shadow</em>). Only the root user should have +read/write access to the <em class="filename">private</em> directory, and +no other users should have access to it at all. In addition, the +<em class="filename">smbpasswd</em> file should have all access denied to +all users except for root. When things are set up for good security, +long listings of the <em class="filename">private</em> directory and +<em class="filename">smbpasswd</em> file look like the following:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>ls -ld /usr/local/samba/private</b></tt> +drwx- - - - - - 2 root root 4096 Nov 26 01:11 /usr/local/samba/private +# <tt class="userinput"><b>ls -l /usr/local/samba/private/smbpasswd</b></tt> +-rw- - - - - - - 1 root root 204 Nov 26 01:11 /usr/local/samba/private/smbpasswd</pre></blockquote> + +<p>Before you can use encrypted passwords, you need to create an entry +for each Unix user in the <em class="filename">smbpasswd</em> file. The +structure of the file is somewhat similar to a Unix +<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 +<em class="filename">smbpasswd</em> file; the entry shown is actually one +line in the file.</p> + +<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> + +<p>Normally, entries in the <em class="filename">smbpasswd</em> file are +created automatically by the <em class="emphasis">smbpasswd</em> command. +Still, you might like to know how to interpret data within the +<em class="filename">smbpasswd</em> file, in case you'd +like to see what accounts are stored in it or even modify it +manually. Here is a breakdown of the individual fields:</p> + +<dl> +<dt><b>Username</b></dt> +<dd> +<p>This is the username of the account. It is taken directly from the +system password file.</p> +</dd> + + + +<dt><b>UID</b></dt> +<dd> +<p>This is the user ID (UID) of the account. Like the username, it is +taken directly from the system password file and must match the UID +there.</p> +</dd> + + + +<dt><b>LAN Manager Password Hash</b></dt> +<dd> +<p>This is a 32-bit hexadecimal sequence that represents the password +Windows 95/98/Me clients will use. It is derived by splitting the +password into two 7-character strings, with all lowercase letters +forced into uppercase. If fewer than 14 characters are in the +password, the strings are padded with nulls. Then each 7-character +string is converted to a 56-bit DES key and used to encrypt the +constant string <tt class="literal">KGS!@#$%</tt>. The two 64-bit results +are concatenated and stored as the password hash.</p> + + +<p>If there is currently no password for the user, the first 11 +characters of the hash will consist of the sequence +<tt class="literal">NO</tt> <tt class="literal">PASSWORD</tt> followed by +<tt class="literal">X</tt> characters for the remainder. If the password +has been disabled, it will consist of 32 <tt class="literal">X</tt> +characters.</p> +</dd> + + +<dt><b>NT LAN Manager (NTLM) Password Hash</b></dt> +<dd> +<p>This is a 32-bit hexadecimal sequence that represents the password +Windows NT/2000/XP clients will use. It is derived by hashing the +user's password (represented as a 16-bit +little-endian Unicode sequence) with an MD4 hash. The password is not +converted to uppercase letters first.</p> +</dd> + + + +<dt><b>Account Flags</b></dt> +<dd> +<p>This field consists of 11 characters between two braces ( [ ] ). Any +of the following characters can appear in any order; the remaining +characters should be spaces:</p> + + +<dl> +<dt><b>U</b></dt> +<dd> +<p>This account is a standard user account.</p> +</dd> + + + +<dt><b>D</b></dt> +<dd> +<p>This account is currently disabled, and Samba should not allow any +logins.</p> +</dd> + + + +<dt><b>N</b></dt> +<dd> +<p>This account has no password associated with it.</p> +</dd> + + + +<dt><b>W</b></dt> +<dd> +<p>This is a workstation trust account that can be used to configure +Samba as a PDC when allowing Windows NT machines to join its domain.</p> +</dd> + +</dl> +</dd> + + +<dt><b>Last Change Time</b></dt> +<dd> +<p>This code consists of the characters <tt class="literal">LCT-</tt> followed +by a hexadecimal representation of the number of seconds since the +epoch (midnight on January 1, 1970) that the entry was last changed. +<a name="INDEX-73"/></p> +</dd> + +</dl> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-4.3"/> + +<h3 class="head2">Password Synchronization</h3> + +<p><a name="INDEX-74"/><a name="INDEX-75"/>Having a regular password (either in +<em class="filename">/etc/passwd</em> or <em class="filename">/etc/shadow</em>) +and an encrypted version of the same password (in the +<em class="filename">smbpasswd</em> file) can be troublesome when you need +to change both of them. Luckily, Samba affords you a limited ability +to keep your passwords synchronized. Samba has a pair of +configuration options to update a user's regular +Unix password automatically when the encrypted password is changed on +the system. The feature can be activated by specifying the +<tt class="literal">unix</tt><a name="INDEX-76"/> <tt class="literal">password</tt> +<tt class="literal">sync</tt> global configuration option:</p> + +<blockquote><pre class="code">[global] + unix password sync = yes</pre></blockquote> + +<p>With this option enabled, Samba attempts to change the +user's regular password (as <tt class="literal">root</tt>) +when the encrypted version is changed with +<em class="filename">smbpasswd</em>. However, two other options have to be +set correctly for this to work.</p> + +<p>The easier of the two is <tt class="literal">passwd</tt> +<tt class="literal">program</tt>. This option simply specifies the Unix +command used to change a user's standard system +password. It is set to <tt class="literal">/bin/passwd</tt> +<tt class="literal">%u</tt> by default. With some Unix systems, this is +sufficient, and you do not need to change anything. Others, such as +Red Hat Linux, use <em class="emphasis">/usr/bin/passwd</em> instead. In +addition, you might want to change this to another program or script +at some point in the future. For example, let's +assume that you want to use a script called +<em class="emphasis">changepass</em> to change a user's +password. Recall that you can use the variable <tt class="literal">%u</tt> +to represent the current Unix username. So the example becomes:</p> + +<blockquote><pre class="code">[global] + unix password sync = yes + passwd program = changepass %u</pre></blockquote> + +<p>Note that this program is called as the <tt class="literal">root</tt> user +when the <tt class="literal">unix</tt> <tt class="literal">password</tt> +<tt class="literal">sync</tt> option is set to <tt class="literal">yes</tt>. This +is because Samba does not necessarily have the old plain-text +password of the user.</p> + +<p>The harder option to configure is +<tt class="literal">passwd</tt><a name="INDEX-77"/> <tt class="literal">chat</tt>. The +<tt class="literal">passwd</tt> <tt class="literal">chat</tt> option works like a +Unix chat script. It specifies a series of strings to send, as well +as responses to expect from the program specified by the +<tt class="literal">passwd</tt> <tt class="literal">program</tt> option. For +example, this is what the default <tt class="literal">passwd</tt> +<tt class="literal">chat</tt> looks like. The delimiters are the spaces +between each grouping of characters:</p> + +<blockquote><pre class="code">passwd chat = *old*password* %o\n *new*password* %n\n *new*password* %n\n *changed*</pre></blockquote> + +<p>The first grouping represents a response expected from the +password-changing program. Note that it can contain wildcards +(<tt class="literal">*</tt>), which help to generalize the chat programs to +handle a variety of similar outputs. Here, +<tt class="literal">*old*password*</tt> indicates that Samba is expecting +any line from the password program containing the letters +<tt class="literal">old</tt> followed by the letters +<tt class="literal">password</tt>, without regard for what comes before, +after, or between them. If Samba does not receive the expected +response, the password change will fail.</p> + +<p>The second grouping indicates what Samba should send back once the +data in the first grouping has been matched. In this case, you see +<tt class="literal">%o\n</tt>. This response is actually two items: the +variable <tt class="literal">%o</tt> represents the old password, while the +<tt class="literal">\n</tt> is a newline character. So, in effect, this +will "type" the old password into +the standard input of the password-changing program, and then +"press" Enter.</p> + +<p>Following that is another response grouping, followed by data that +will be sent back to the password-changing program. (In fact, this +response/send pattern continues indefinitely in any standard Unix +<em class="emphasis">chat</em> script.) The script continues until the +final pattern is matched.</p> + +<p>You can help match the response strings sent from the password +program with the characters listed in <a href="ch09.html#samba2-CHP-9-TABLE-6">Table 9-6</a>. +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> + +<a name="samba2-CHP-9-TABLE-6"/><h4 class="head4">Table 9-6. Password chat response characters</h4><table border="1"> + + + +<tr> +<th> +<p>Character</p> +</th> +<th> +<p>Definition</p> +</th> +</tr> + + +<tr> +<td> +<p><tt class="literal">*</tt></p> +</td> +<td> +<p>Zero or more occurrences of any character.</p> +</td> +</tr> +<tr> +<td> +<p>"<tt class="literal"> </tt>"</p> +</td> +<td> +<p>Allows you to include matching strings that contain spaces. Asterisks +are still considered wildcards even inside of quotes, and you can +represent a null response with empty quotes.</p> +</td> +</tr> + +</table> + +<a name="samba2-CHP-9-TABLE-7"/><h4 class="head4">Table 9-7. Password chat send characters</h4><table border="1"> + + + +<tr> +<th> +<p>Character</p> +</th> +<th> +<p>Definition</p> +</th> +</tr> + + +<tr> +<td> +<p><tt class="literal">%o</tt></p> +</td> +<td> +<p>The user's old password</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">%n</tt></p> +</td> +<td> +<p>The user's new password</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">\n</tt></p> +</td> +<td> +<p>The linefeed character</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">\r</tt></p> +</td> +<td> +<p>The carriage-return character</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">\t</tt></p> +</td> +<td> +<p>The tab character</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">\s</tt></p> +</td> +<td> +<p>A space</p> +</td> +</tr> + +</table> + +<p>For example, you might want to change your password chat to the +following entry. This handles scenarios in which you do not have to +enter the old password. In addition, this also handles the new +<tt class="literal">all</tt> <tt class="literal">tokens</tt> +<tt class="literal">updated</tt> <tt class="literal">successfully</tt> string +that Red Hat Linux sends:</p> + +<blockquote><pre class="code">passwd chat = *New password* %n\n *new password* %n\n *success*</pre></blockquote> + +<p>Again, the default chat should be sufficient for many Unix systems. +If it isn't, you can use the +<tt class="literal">passwd</tt> <tt class="literal">chat</tt> +<tt class="literal">debug</tt> global option to set up a new chat script +for the password change program. The <tt class="literal">passwd</tt> +<tt class="literal">chat</tt> <tt class="literal">debug</tt> option logs +everything during a password chat. This option is a simple Boolean, +as shown here:</p> + +<blockquote><pre class="code">[global] + unix password sync = yes + passwd chat debug = yes + log level = 100</pre></blockquote> + +<p>After you activate the password chat debug feature, all I/O received +by Samba through the password chat can be sent to the +<em class="filename">log.smbd</em> Samba log file with a debug level of +100, which is why we entered a new <tt class="literal">log</tt> +<tt class="literal">level</tt> option as well. As this can often generate +multitudes of error logs, it can be more efficient to use your own +script—by setting the <tt class="literal">passwd</tt> +<tt class="literal">program</tt> option—in place of +<em class="filename">/bin/passwd</em> to record what happens during the +exchange. Be careful because the log file contains the passwords in +plain text. Keeping files containing plain-text passwords can (or +<em class="emphasis">should</em>) be against local security policy in your +organization, and it also might raise serious legal issues. Make sure +to protect your log files with strict file permissions and to delete +them as soon as you've grabbed the information you +need. If possible, use the <tt class="literal">passwd</tt> +<tt class="literal">chat</tt> <tt class="literal">debug</tt> option only while +your own password is being changed.</p> + +<p>The operating system on which Samba is running might have strict +requirements for valid passwords to make them more impervious to +dictionary attacks and the like. Users should be made aware of these +restrictions when changing their passwords.</p> + +<p>Earlier we said that password synchronization is limited. This is +because there is no reverse synchronization of the encrypted +<em class="filename">smbpasswd</em> file when a standard Unix password is +updated by a user. There are various strategies to get around this, +including NIS and freely available implementations of the Pluggable +Authentication Modules (PAM) standard, but none of them really solves +all the problems.</p> + +<p>More information regarding passwords can be found in the in the Samba +source distribution file +<em class="filename">docs/htmldocs/ENCRYPTION.html</em>.<a name="INDEX-80"/></p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-4.4"/> + +<h3 class="head2">Password Configuration Options</h3> + +<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> + +<a name="samba2-CHP-9-TABLE-8"/><h4 class="head4">Table 9-8. Password configuration options</h4><table border="1"> + + + + + + +<tr> +<th> +<p>Option</p> +</th> +<th> +<p>Parameters</p> +</th> +<th> +<p>Function</p> +</th> +<th> +<p>Default</p> +</th> +<th> +<p>Scope</p> +</th> +</tr> + + +<tr> +<td> +<p><tt class="literal">encrypt</tt> <tt class="literal">passwords</tt></p> +</td> +<td> +<p>Boolean</p> +</td> +<td> +<p>If <tt class="literal">yes</tt>, enables encrypted passwords.</p> +</td> +<td> +<p><tt class="literal">no</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">unix password</tt> <tt class="literal">sync</tt></p> +</td> +<td> +<p>Boolean</p> +</td> +<td> +<p>If <tt class="literal">yes</tt>, updates the standard Unix password +database when a user changes his encrypted password.</p> +</td> +<td> +<p><tt class="literal">no</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">passwd chat</tt></p> +</td> +<td> +<p>string (chat commands)</p> +</td> +<td> +<p>Sequence of commands sent to the password program.</p> +</td> +<td> +<p>See earlier section on this option</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">passwd chat</tt> <tt class="literal">debug</tt></p> +</td> +<td> +<p>Boolean</p> +</td> +<td> +<p>If <tt class="literal">yes</tt>, sends debug logs of the password-change +process to the log files with a level of 100.</p> +</td> +<td> +<p><tt class="literal">no</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">passwd program</tt></p> +</td> +<td> +<p>string (Unix command)</p> +</td> +<td> +<p>Program to be used to change passwords.</p> +</td> +<td> +<p><tt class="literal">/bin/passwd</tt> <tt class="literal">%u</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">password level</tt></p> +</td> +<td> +<p>numeric</p> +</td> +<td> +<p>Number of capital-letter permutations to attempt when matching a +client's password.</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">update</tt> <tt class="literal">encrypted</tt></p> +</td> +<td> +<p>Boolean</p> +</td> +<td> +<p>If <tt class="literal">yes</tt>, updates the encrypted password file when a +client connects to a share with a plain-text password.</p> +</td> +<td> +<p><tt class="literal">no</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">null passwords</tt></p> +</td> +<td> +<p>Boolean</p> +</td> +<td> +<p>If <tt class="literal">yes</tt>, allows access for users with null +passwords.</p> +</td> +<td> +<p><tt class="literal">no</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">smb passwd file</tt></p> +</td> +<td> +<p>string (filename)</p> +</td> +<td> +<p>Name of the encrypted password file.</p> +</td> +<td> +<p><tt class="literal">/usr/local/samba/private/smbpasswd</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">hosts equiv</tt></p> +</td> +<td> +<p>string (filename)</p> +</td> +<td> +<p>Name of a file that contains hosts and users that can connect without +using a password.</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">use rhosts</tt></p> +</td> +<td> +<p>string (filename)</p> +</td> +<td> +<p>Name of a .<em class="emphasis">rhosts</em> file that allows users to +connect without using a password.</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Global</p> +</td> +</tr> + +</table> + + +<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.1"/> + +<h3 class="head3">encrypt passwords</h3> + +<p>The <tt class="literal">encrypt</tt><a name="INDEX-83"/> +<tt class="literal">passwords</tt> global option switches Samba from using +plain-text passwords to encrypted passwords for authentication. +Encrypted passwords will be expected from clients if the option is +set to <tt class="literal">yes</tt>:</p> + +<blockquote><pre class="code">encrypt passwords = yes</pre></blockquote> + +<p>In Samba 2.2.x versions and with previous versions, encrypted +passwords are disabled by default. This was changed in Samba 3.0 to +make encrypted passwords enabled by default.</p> + +<p>If you use encrypted passwords, you must have a valid +<em class="filename">smbpasswd</em> file in place and populated with +usernames that authenticate with encrypted passwords. (See <a href="ch09.html#samba2-CHP-9-SECT-4.2">Section 9.4.2</a> earlier in +this chapter.) In addition, Samba must know the location of the +<em class="filename">smbpasswd</em> file; if it is not in the default +location (typically +<em class="filename">/usr/local/samba/private/smbpasswd</em> ), you can +explicitly name it using the <tt class="literal">smb</tt> +<tt class="literal">passwd</tt> <tt class="literal">file</tt> option.</p> + +<p>If you wish, you can use <tt class="literal">update</tt> +<tt class="literal">encrypted</tt> to force Samba to update the +<em class="filename">smbpasswd</em> file with encrypted passwords each +time a client connects using a nonencrypted password.</p> + +<p>If you have a mixture of clients on your network, with some of them +using encrypted passwords and others using plain-text passwords, you +can use the <tt class="literal">include</tt> option to make Samba treat +each client appropriately. To do this, create individual +configuration files based on the client name (<tt class="literal">%m</tt>). +These host-specific configuration files can contain an +<tt class="literal">encrypted</tt> <tt class="literal">passwords</tt> +<tt class="literal">=</tt> <tt class="literal">yes</tt> option that activates +only when those clients are connecting to the server.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.2"/> + +<a name="INDEX-84"/><h3 class="head3">unix password sync</h3> + +<p>The <tt class="literal">unix</tt> <tt class="literal">password</tt> +<tt class="literal">sync</tt> global option allows Samba to update the +standard Unix password file when a user changes her encrypted +password. The encrypted password is stored on a Samba server in the +<em class="filename">smbpasswd</em> file, which is located by default in +<em class="filename">/usr/local/samba/private</em>. You can activate this +feature as follows:</p> + +<blockquote><pre class="code">[global] + unix password sync = yes</pre></blockquote> + +<p>If this option is enabled, Samba changes the encrypted password and, +in addition, attempts to change the standard Unix password by passing +the username and new password to the program specified by the +<tt class="literal">passwd</tt> <tt class="literal">program</tt> option +(described earlier). Note that Samba does not necessarily have access +to the plain-text password for this user, so the password changing +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 +succeed, for whatever reason, the SMB password is not changed either.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.3"/> + +<a name="INDEX-85"/><h3 class="head3">passwd chat</h3> + +<p>This option specifies a series of send/response strings similar to a +Unix chat script, which interface with the password-changing program +on the Samba server. <a href="ch09.html#samba2-CHP-9-SECT-4.3">Section 9.4.3</a> earlier in this +chapter covers this option in detail.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.4"/> + +<h3 class="head3">passwd chat debug</h3> + +<p>If set to <tt class="literal">yes</tt>, the +<tt class="literal">passwd</tt><a name="INDEX-86"/> <tt class="literal">chat</tt> +<tt class="literal">debug</tt> global option logs everything sent or +received by Samba during a password chat. All the I/O received by +Samba through the password chat is sent to the Samba logs with a +debug level of 100; you must specify <tt class="literal">log</tt> +<tt class="literal">level</tt> <tt class="literal">=</tt> <tt class="literal">100</tt> +for the information to be recorded. <a href="ch09.html#samba2-CHP-9-SECT-4.3">Section 9.4.3</a> earlier in this +chapter describes this option in more detail. Be aware that if you do +set this option, the plain-text passwords will be visible in the +debugging logs, which could be a security hazard if they are not +properly secured. It is against the security policy of some +organizations for system administrators to have access to +users' passwords.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.5"/> + +<h3 class="head3">passwd program</h3> + +<p>The <tt class="literal">passwd</tt><a name="INDEX-87"/> +<tt class="literal">program</tt> option specifies a program on the Unix +Samba server that Samba can use to update the standard system +password file when the encrypted password file is updated. This +option defaults to the standard <em class="emphasis">passwd</em> program, +usually located in the <em class="filename">/bin</em> directory. The +<tt class="literal">%u</tt> variable is typically used as the requesting +user when the command is executed. The actual handling of input and +output to this program during execution is handled through the +<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 +chapter covers this option in detail.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.6"/> + +<a name="INDEX-88"/><h3 class="head3">password level</h3> + +<p>With SMB, nonencrypted (or plain-text) passwords are sent with +capital letters, just like the usernames mentioned previously. Many +Unix users, however, choose passwords with both upper- and lowercase +letters. Samba, by default, only attempts to match the password +entirely in lowercase letters and not capitalizing the first letter.</p> + +<p>Like <tt class="literal">username</tt> <tt class="literal">level</tt>, a +<tt class="literal">password</tt> <tt class="literal">level</tt> option can be +used to attempt various permutations of the password with capital +letters. This option takes an integer value that specifies how many +letters in the password should be capitalized when attempting to +connect to a share. You can specify this option as follows:</p> + +<blockquote><pre class="code">[global] + password level = 3</pre></blockquote> + +<p>In this case, Samba then attempts all permutations of the password it +can compute having three capital letters. The larger the number, the +more computations Samba has to perform to match the password, and the +longer a connection to a specific share might take.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.7"/> + +<a name="INDEX-89"/><h3 class="head3">update encrypted</h3> + +<p>For sites switching over to the encrypted password format, Samba +provides an option that should help with the transition. The +<tt class="literal">update</tt> <tt class="literal">encrypted</tt> option allows +a site to ease into using encrypted passwords from plain-text +passwords. You can activate this option as follows:</p> + +<blockquote><pre class="code">[global] + update encrypted = yes</pre></blockquote> + +<p>This instructs Samba to create an encrypted version of each +user's Unix password in the +<em class="filename">smbpasswd</em> file each time she connects to a +share. When this option is enabled, you must have the +<tt class="literal">encrypt</tt> <tt class="literal">passwords</tt> option set to +<tt class="literal">no</tt> so that the client passes plain-text passwords +to Samba to update the files. Once each user has connected at least +once, you can set <tt class="literal">encrypted</tt> +<tt class="literal">passwords</tt> <tt class="literal">=</tt> +<tt class="literal">yes</tt>, allowing you to use only the encrypted +passwords. The user must already have a valid entry in the +<em class="filename">smbpasswd</em> file for this option to work.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.8"/> + +<a name="INDEX-90"/><h3 class="head3">null passwords</h3> + +<p>This global option tells Samba whether to allow access from users +that have null passwords (encrypted or nonencrypted) set in their +accounts. The default value is <tt class="literal">no</tt>. You can +override it as follows:</p> + +<blockquote><pre class="code">null passwords = yes</pre></blockquote> + +<p>We highly recommend against doing so because of the security risks +this option can present to your system, including inadvertent access +to system users (such as <tt class="literal">bin</tt>) in the system +password file who have null passwords set.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.9"/> + +<a name="INDEX-91"/><h3 class="head3">smb passwd file</h3> + +<p>This global option identifies the location of the encrypted password +database. By default, it is set to +<em class="filename">/usr/local/samba/private/smbpasswd</em>. You can +override it as follows:</p> + +<blockquote><pre class="code">[global] + smb passwd file = /etc/samba/smbpasswd</pre></blockquote> + +<p>This location, for example, is common on many Red Hat distributions +on which Samba has been installed using an RPM package.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.10"/> + +<a name="INDEX-92"/><h3 class="head3">hosts equiv</h3> + +<p>This global option specifies the name of a standard Unix +<em class="filename">hosts.equiv</em> file that allows hosts or users to +access shares without specifying a password. You can specify the +location of such a file as follows:</p> + +<blockquote><pre class="code">[global] + hosts equiv = /etc/hosts.equiv</pre></blockquote> + +<p>The default value for this option does not specify any +<em class="filename">hosts.equiv</em> file. Because using a +<em class="filename">hosts.equiv</em> file is a huge security risk, we +strongly recommend against using this option.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-4.4.11"/> + +<a name="INDEX-93"/><h3 class="head3">use rhosts</h3> + +<p>This global option specifies the name of a standard Unix +user's <em class="filename">.rhosts</em> file that allows +foreign hosts to access shares without specifying a password. You can +specify the location of such a file as follows:</p> + +<blockquote><pre class="code">[global] + use rhosts = /home/dave/.rhosts</pre></blockquote> + +<p>The default value for this option does not specify any +<em class="filename">.rhosts</em> file. Like the <tt class="literal">hosts</tt> +<tt class="literal">equiv</tt> option discussed earlier, using such a file +is a security risk. We highly recommend that you do not use this +option unless you are confident in the security of your network. +<a name="INDEX-94"/> +<a name="INDEX-95"/><a name="INDEX-96"/></p> + + +</div> + + +</div> + + +</div> + + + +<div class="sect1"><a name="samba2-CHP-9-SECT-5"/> + +<h2 class="head1">Authentication with winbind</h2> + +<p><a name="INDEX-97"/><a name="INDEX-98"/>In <a href="ch03.html">Chapter 3</a>, we +showed you how to add Windows clients to a network in which user +accounts were maintained on the Samba server. We added a user account +to the Windows client using the same username and password as an +account on the Unix system. This method works well in many computing +environments. However, if a Samba server is added to a Windows +network that already has a Windows NT/2000 primary domain controller, +the PDC has a preexisting database of user accounts and group +information that is used for authentication. It can be a big chore to +transfer that database manually to the Unix server, and later +maintain and synchronize the Unix and Windows databases.</p> + +<p>In <a href="ch04.html">Chapter 4</a>, we showed you how to add a Samba +server as a domain member server to a network having a Windows +NT/2000 primary domain controller. We set <tt class="literal">security</tt> +<tt class="literal">=</tt> <tt class="literal">domain</tt> in the Samba +configuration file to have the Samba server hand off authentication +to the Windows PDC. Using that method, passwords are kept only on the +PDC, but it is still necessary to set up user accounts on the Unix +side to make sure each client has a valid Unix UID and group ID +(GID). This is necessary for maintaining the file ownerships and +permissions of the Unix security model. Whenever Samba performs an +operation on the Unix filesystem on behalf of the Windows client, the +user must have a valid UID and GID on the local Unix system.</p> + +<p>A facility that has recently been added to Samba, winbind, allows the +Windows <a name="INDEX-99"/>PDC to handle +not only authentication, but the user and group information as well. +Winbind works by extending the Unix user and group databases beyond +the standard <em class="filename">/etc/passwd</em> and +<em class="filename">/etc/group</em> files such that users and groups on +the Windows PDC also exist as valid users and groups on the Unix +system. The extension applies to the entire Unix system and allows +users who are members of a Windows domain to perform any action on +the Unix system that a local user would, including logging in to the +Unix system by <em class="emphasis">telnet</em> or even on the local +system, using their domain usernames and passwords.</p> + +<p>When winbind is in use, administration of user accounts can be done +on the Windows PDC, without having to repeat the tasks on the Unix +side. This includes password expiration and allowing users to change +their passwords, which would otherwise not be practical. Aside from +simplifying domain administration and being a great time saver, +winbind lets Samba be used in computing environments where it +otherwise might not be allowed.</p> +<a name="samba2-CHP-9-NOTE-143"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p>Because this is a chapter on security, we want to point out that some +issues might relate to allowing a Windows system to authenticate +users accessing a Unix system! Whatever you might think of the +relative merits of Unix and Windows security models (and even more +importantly, their <em class="emphasis">implementations</em>), one thing +is certain: adding winbind support to your Samba server greatly +complicates the authentication system overall—and quite +possibly allows more opportunities for crackers.</p> + +<p>We present winbind in this chapter not as a means of improving +security, but rather as a further example of Samba's +ability to integrate itself into a modern Windows environment.</p> +</blockquote> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-5.1"/> + +<h3 class="head2">Installing winbind</h3> + +<p><a name="INDEX-100"/>Installing +and configuring winbind is fairly complicated and involves the +following steps:</p> + +<ol><li> +<p>Reconfigure, recompile, and reinstall Samba—to add support for +winbind.</p> +</li><li> +<p>Configure the Unix name server switch.</p> +</li><li> +<p>Modify the Samba configuration file.</p> +</li><li> +<p>Start and test the <em class="emphasis">winbindd</em> daemon.</p> +</li><li> +<p>Configure the system to start and stop the +<em class="emphasis">winbindd</em> daemon automatically.</p> +</li><li> +<p>Optionally, configure PAM for use with winbind.</p> +</li></ol> +<p>At the time this book was written, winbind was supported only on +Linux, so all of the following directions are specific to it. Other +Unix flavors might be supported at a later time. In addition, we +assume you have a Windows NT/2000 primary domain controller running +on your network.</p> + +<p>First, you will need to configure and compile Samba using the +<tt class="literal">--with-winbind</tt> configure option. Directions for +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 +<em class="emphasis">make install</em> to reinstall the Samba binaries.</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-5.2"/> + +<h3 class="head2">Configuring nsswitch</h3> + +<p><a name="INDEX-101"/>When +Samba is compiled after being configured with the +<tt class="literal">--with-winbind</tt> option, the compilation process +produces a library called +<em class="filename">libnss_winbind.so</em><a name="INDEX-102"/> in the +<em class="filename">source/nsswitch</em> directory. This library needs to +be copied to the <em class="filename">/lib</em> directory:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>cp nsswitch/libnss_winbind.so /lib</b></tt></pre></blockquote> + +<p>Also, a symbolic link must be created for winbind to be fully +functional:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2</b></tt></pre></blockquote> + +<a name="samba2-CHP-9-NOTE-144"/><blockquote class="note"><h4 class="objtitle">TIP</h4> +<p>The name of this symbolic link is correct for Samba 2.2.3 and Red Hat +7.1. The name might change—with a higher version number in the +extension—in future releases. See the +<em class="emphasis">winbindd</em> manual page for details.</p> +</blockquote> + +<p>Next, we need to modify <em class="filename">/etc/nsswitch.conf</em> to +make the lines for <tt class="literal">passwd</tt> and +<tt class="literal">group</tt> look like this:</p> + +<blockquote><pre class="code">passwd: files winbind +group: files winbind</pre></blockquote> + +<p>Then activate these changes by issuing the following command:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>/sbin/ldconfig</b></tt></pre></blockquote> + +<p>What we've just done is reconfigure the Linux name +service switch, which allows name service and other tasks to be +configured to use the traditional method (files in the +<em class="filename">/etc</em> directory) or an extension coded in a +library, such as the <em class="filename">libnss_winbind.so</em> library +we've just installed. We've +specified in our configuration that Samba will search for user and +group information first in the <em class="filename">/etc/passwd</em> and +<em class="filename">/etc/group files</em>, and if they are not found +there, in the winbind service.</p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-5.3"/> + +<h3 class="head2">Modifying smb.conf</h3> + +<p><a name="INDEX-103"/><a name="INDEX-104"/>To use winbind, we must have our Samba +server added to the Windows NT domain as a domain member server (as +we described in <a href="ch04.html">Chapter 4</a>) and also add some +parameters to the Samba configuration file to configure winbind. In +addition to the options required to configure Samba as a domain +member server, we need:</p> + +<blockquote><pre class="code">[global] + winbind uid = 10000-20000 + winbind gid = 10000-20000</pre></blockquote> + +<p>The <tt class="literal">winbind</tt> <tt class="literal">uid</tt> and +<tt class="literal">winbind</tt> <tt class="literal">gid</tt> options tell +winbind how to map between Windows relative identifiers (RIDs) and +Unix UIDs and GIDs. Windows uses RIDs to identify users and groups +within the domain, and to function, the Unix system must have a UID +and GID associated with every user and group RID that is received +from the Windows primary domain controller. The +<tt class="literal">winbind</tt> <tt class="literal">uid</tt> and +<tt class="literal">winbind</tt> <tt class="literal">gid</tt> parameters simply +provide winbind with a range of UIDs and GIDs, respectively, that are +allocated by the system administrator for Windows NT domain users and +groups. You can use whatever range you want for each; just make sure +the lowest number in the range does not conflict with any entries in +your <em class="filename">/etc/passwd</em> or +<em class="filename">/etc/group</em> files at any time, either now or in +the future. It is important to be conservative about this. Once +winbind adds an RID to UID/GID mapping to its database, it is very +difficult to modify the mapping.</p> +<a name="samba2-CHP-9-NOTE-145"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p><a name="INDEX-105"/>The file +<em class="filename">/usr/local/samba/locks/winbindd_idmap.tdb</em> +contains winbind's RID mapping file by default. We +suggest you regard this file as extremely sensitive and make sure to +guard it carefully against any kind of harm or loss. If you lose it, +you will have to re-create it manually, which can be a very +labor-intensive task.</p> +</blockquote> + +<a name="samba2-CHP-9-NOTE-145a"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p>Be careful when adding local users after domain users have started +accessing the Samba server. The domain users will have entries +created for them by winbind in <em class="filename">/etc/passwd,</em> with +UIDs in the range you specify. If you are using a method of creating +new accounts that automatically assigns UIDs, it might choose UIDs by +adding 1 to the highest UID assigned thus far, which will be the most +recent UID added by winbind. (This is the case on Red Hat Linux, with +the <em class="emphasis">useradd</em> script, for example.) The UID for +the new local user will be within the range allocated for winbind, +which will have undesired effects. Make sure to add new local users +using a method that assigns them UIDs in the proper range. For +example, you can use the <em class="emphasis">-u</em> option of +<em class="emphasis">useradd</em> to specify the UID to assign to the new +user.</p> +</blockquote> + +<p>Restart the Samba daemons to put your changes to the configuration +file into effect. If you have not already done so while adding your +Samba server as a domain member server, you must issue the command:</p> + +<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> + +<p>as we described in <a href="ch04.html">Chapter 4</a>. At this point, you +can start the <em class="emphasis">winbindd</em> daemon:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>winbindd</b></tt></pre></blockquote> + +<p><a name="INDEX-106"/>You might want to +run a <em class="emphasis">ps ax</em> command to see that the +<em class="emphasis">winbindd</em> daemon is running. Now, to make sure +everything we've done up to this point works, we can +use Samba's <em class="emphasis">wbinfo</em> command:</p> + +<blockquote><pre class="code">$ <tt class="userinput"><b>wbinfo -u</b></tt> +METRAN\Administrator +METRAN\bebe +METRAN\Guest +METRAN\jay +METRAN\linda +$ <tt class="userinput"><b>wbinfo -g</b></tt> +METRAN\Domain Admins +METRAN\Domain Guests +METRAN\Domain Users</pre></blockquote> + +<p>The <em class="emphasis">-u</em> option queries the domain controller for +a list of domain users, and the <em class="emphasis">-g</em> option asks +for the list of groups. The output shows that the Samba host system +can query the Windows PDC through winbind.</p> + +<p>Another thing to check is the list of users and groups, using the +<em class="emphasis">getent</em> command:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>getent passwd</b></tt> +root:x:0:0:root:/root:/bin/bash +bin:x:1:1:bin:/bin: +daemon:x:2:2:daemon:/sbin: + <i class="lineannotation">... deleted ...</i> +jay:x:500:500:Jay Ts:/home/jay:/bin/bash +rik:x:501:501::/home/rik:/bin/bash +METRAN\Administrator:x:10000:10000::/home/METRAN/administrator:/bin/bash +METRAN\bebe:x:10001:10000:Bebe Larta:/home/METRAN/bebe:/bin/bash +METRAN\Guest:x:10002:10000::/home/METRAN/guest:/bin/bash +METRAN\jay:x:10003:10000:Jay Ts:/home/METRAN/jay:/bin/bash +METRAN\linda:x:10004:10000:Linda Lewis:/home/METRAN/linda:/bin/bash + +# getent group +root:x:0:root +bin:x:1:root,bin,daemon +daemon:x:2:root,bin,daemon + <i class="lineannotation">... deleted ...</i> +jay:x:500: +rik:x:501: +METRAN\Domain Admins:x:10001:METRAN\Administrator +METRAN\Domain Guests:x:10002:METRAN\Guest +METRAN\Domain Users:x:10000:METRAN\Administrator,METRAN\jay,METRAN\linda,METRAN\bebe</pre></blockquote> + +<p>This shows that the Linux system is finding the domain users and +groups through winbind, in addition to those in the +<em class="filename">/etc/passwd</em> and <em class="filename">/etc/group</em> +files. If this part doesn't work as shown earlier, +with the domain users and groups listed after the local ones, check +to make sure you made the symbolic link to +<em class="filename">libnss_winbind.so</em> in <em class="filename">/lib</em> +correctly.</p> + +<p>Now you can try connecting to a Samba share from a Windows system +using a domain account. You can either log on to the domain from a +Windows NT/2000/XP workstation or use <em class="emphasis">smbclient</em> +with the <em class="emphasis">-U</em> option to specify a username.</p> + +<a name="samba2-CHP-9-NOTE-147"/><blockquote class="note"><h4 class="objtitle">NOTE</h4> +<p>If you get errors while attempting to log on to the domain, it is +probably because you had previously configured the client system with +a computer account on another domain controller. Commonly, you get a +dialog box that says, "The domain +<em class="replaceable">NAME</em> is not available." +On a Windows 2000 system, the fix is to log in to the system as an +administrative user and open the Control Panel, double-click the +System icon, click the Network Identification tab, then click the +Properties button. In the dialog that comes up, click the +"Workgroup:" radio button and fill +in the name of the workgroup (you can use the same name as the +domain). Click the OK buttons in the dialogs, and reboot if +requested.</p> + +<p>This removes the computer account from the primary domain controller. +Now log in again as the administrative user and repeat the previous +directions, but change from the workgroup back to the domain. This +creates a new computer account that +"fits" the workstation to the new +primary domain controller. If your network has backup domain +controllers, it will take up to 15 minutes for the new computer +account to propagate to the BDCs.</p> + +<p>If you are using Windows NT/XP, the method is slightly different. For +the exact procedure, see the section in <a href="ch04.html">Chapter 4</a> +that is specific to your Windows version.</p> +</blockquote> + +<p>After logging in as a domain user, try creating a file or two in a +Samba share. (You might need to change the permissions on the shared +directory—say, to 777—to allow this access. This is very +permissive, but after you finish reading this section, you will +understand how to change ownership and permissions on the directory +to restrict access to selected domain users.) After +you've created files by one or more domain users, +take a look at the directory's contents from a Linux +shell. You will see something like this:</p> + +<blockquote><pre class="code">$ <tt class="userinput"><b>ls -l /u</b></tt> +-rwxrw-rw- 1 METRAN\b METRAN\D 0 Apr 13 00:00 bebes-file.doc +-rwxrw-rw- 1 METRAN\l METRAN\D 0 Apr 12 23:58 lindas-file.doc +drwxrwxr-x 6 jay jay 4096 Jan 15 05:12 snd +<b class="emphasis-bold">$ ls -ln /u</b> +total 4 +-rwxrw-rw- 1 10001 10000 0 Apr 13 00:00 bebes-file.doc +-rwxrw-rw- 1 10004 10000 0 Apr 12 23:58 lindas-file.doc +drwxrwxr-x 6 500 500 4096 Jan 15 05:12 snd</pre></blockquote> + +<p>We can even use the domain usernames and groups from the Linux shell:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>chown 'METRAN\linda:METRAN\Domain Users' /u</b></tt> +# <tt class="userinput"><b>ls -ldu /u</b></tt> +drwxrwxrwx 3 METRAN\l METRAN\D 4096 Apr 13 00:44 /u +# <tt class="userinput"><b>ls -ldn /u</b></tt> +drwxrwxrwx 3 10004 10000 4096 Apr 13 00:00 /u</pre></blockquote> + +<p>Notice how the owner and group are listed as being those of the +domain user and group. Unfortunately, the GNU <em class="emphasis">ls</em> +command won't show the full names of the domain +users and groups, but we can use the <em class="emphasis">-ln</em> listing +to show the UIDs and GIDs and then translate with the +<em class="emphasis">wbinfo</em> command:</p> + +<blockquote><pre class="code">$ <tt class="userinput"><b>wbinfo -s `wbinfo -U 10004`</b></tt> +METRAN\LINDA 1 +$ <tt class="userinput"><b>wbinfo -s `wbinfo -G 10000`</b></tt> +METRAN\Domain Users 2</pre></blockquote> + +<p>(It's a bit messy, but it works, and it shows that +the winbind system is working!) At this point, you might want to +modify your <em class="filename">/etc/rc.d/init.d/smb</em> script to start +and stop the <em class="emphasis">winbindd</em> daemon automatically along +with the <em class="emphasis">smbd</em> and <em class="emphasis">nmbd</em> +daemons. Starting with the script we presented in <a href="ch02.html">Chapter 2</a>, we first add this code to the +<em class="emphasis">start( )</em> function:</p> + +<blockquote><pre class="code">echo -n $"Starting WINBIND services: " +/usr/local/samba/bin/winbindd +ERROR2=$? +if [ $ERROR2 -ne 0 ] +then + ERROR=1 +fi +echo</pre></blockquote> + +<p>The previous code should be located after the code that starts +<em class="emphasis">nmbd</em> and before the <em class="emphasis">return</em> +statement.</p> + +<a name="samba2-CHP-9-NOTE-148"/><blockquote class="note"><h4 class="objtitle">TIP</h4> +<p>We start <em class="emphasis">winbindd</em> after +<em class="emphasis">nmbd</em> because <em class="emphasis">winbindd</em> needs +<em class="emphasis">nmbd</em> to be running to work properly.</p> +</blockquote> + +<p>In the <tt class="function">stop( )</tt> function, we add the following:</p> + +<blockquote><pre class="code">echo -n $"Shutting down WINBIND services: " +/bin/kill -TERM -a winbindd +ERROR2=$? +if [ $ERROR2 -ne 0 ] +then + ERROR=1 +fi +echo</pre></blockquote> + +<p>Again, this code should be located after the code that stops +<em class="emphasis">nmbd</em> and before the <em class="emphasis">return</em> +statement. <a name="INDEX-107"/></p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-5.4"/> + +<h3 class="head2">Configuring PAM</h3> + +<p><a name="INDEX-108"/>Most +popular Linux distributions use <a name="INDEX-109"/>Pluggable +Authentication Modules (PAM), a suite of shared libraries that +provide a centralized source of authentication for applications +running on the Unix system. PAM can be configured differently for +each application (or service) that uses it, without needing to +recompile the application. As a hypothetical example, if an +organization's security policy mandated the use of +passwords exactly 10 characters in length, a PAM module could be +written to check the length of passwords submitted by users and +reject any attempts to use a longer or shorter password. PAM would +then be reconfigured to include the new module for services such as +<em class="emphasis">ftp</em>, console login, and GUI login that call upon +PAM to authenticate users.</p> + +<p>If you are not already familiar with PAM, we suggest you read the +documentation provided with the Linux PAM package before continuing. +On most Linux systems, it is located in the +<em class="filename">/usr/share/doc</em> directory hierarchy. Another +resource is the <em class="citetitle">Linux-PAM System +Administrator's +Guide</em><a name="INDEX-110"/>, which you can find +on the Internet at <a href="http://www.kernel.org/pub/linux/libs/pam">http://www.kernel.org/pub/linux/libs/pam</a>.</p> + +<p>The rest of this section is about using the PAM module provided in +the Samba distribution to enable Windows domain users to authenticate +on the Linux system hosting Samba. Depending on which services you +choose to configure, this allows Windows domain users to log in on a +local console (or through <em class="emphasis">telnet</em>), log in to a +GUI desktop on the Linux system, authenticate with an FTP server +running on the Linux system, or use other services normally limited +to users who have an account on the Linux system. The PAM module +authenticates Windows domain users by querying winbind, which passes +the authentication off to a Windows NT domain controller.</p> + +<p>As an example, we will show how to allow Windows domain users to log +in to a text console on the Linux system and get a command shell and +home directory. The method used in our example can be applied (with +variations) to other services.</p> + +<p>All users who can log in to the Linux system need a shell and a home +directory. Unix and Linux keep this user information in the password +file (<em class="filename">/etc/passwd</em> ), but information about +Windows users isn't located there. Instead, in the +Samba configuration file, we add the following to notify winbind what +the shell and home directory for Windows domain users will be:</p> + +<blockquote><pre class="code">[global] + template shell = /bin/bash + template homedir = /home/%D/%U</pre></blockquote> + +<p>The first line sets the +<tt class="literal">template</tt><a name="INDEX-111"/> <tt class="literal">shell</tt> +parameter, which tells winbind what shell to use for domain users +that are logging in to the Unix host. The +<tt class="literal">template</tt><a name="INDEX-112"/> +<tt class="literal">homedir</tt> parameter specifies the location of +users' home directories. The <tt class="literal">%D</tt> +variable is replaced by the name of the domain in which the +user's account resides, and <tt class="literal">%U</tt> is +replaced by the user's username in that domain.</p> + +<p>Before the domain users can successfully log in, their home +directories must be created manually. To add a single account for +<tt class="literal">linda</tt> in the METRAN domain, we would use these +commands:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>mkdir /home/METRAN</b></tt> +# <tt class="userinput"><b>chmod 755 /home/METRAN</b></tt> + +# <tt class="userinput"><b>mkdir /home/METRAN/linda</b></tt> +# <tt class="userinput"><b>chown 'METRAN\linda:METRAN\Domain Users' /home/METRAN/linda</b></tt> +# <tt class="userinput"><b>chmod 700 /home/METRAN/linda</b></tt></pre></blockquote> +<a name="samba2-CHP-9-NOTE-149"/><blockquote class="note"><h4 class="objtitle">WARNING</h4> +<p>One side effect of creating the home directories is that if the Samba +server is configured with a <tt class="literal">[homes]</tt> share, the +domain users can see and access their home directories through +Samba's file sharing.</p> +</blockquote> + +<p>Next, we need to compile and install the PAM module in the Samba +distribution. From the source directory in the Samba distribution, +issue the following commands:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>make nsswitch/pam_winbind.so</b></tt> +# <tt class="userinput"><b>cp nsswitch/pam_winbind.so /lib/security</b></tt></pre></blockquote> + +<p>and check that it was copied over correctly:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>ls /lib/security/pam_winbind.so</b></tt> +/lib/security/pam_winbind.so</pre></blockquote> + +<p>On Red Hat Linux, the PAM configuration files reside in +<em class="filename">/etc/pam.d</em>. Before making any modifications, we +strongly advise making a backup of this directory:</p> + +<blockquote><pre class="code"># cp -pR /etc/pam.d /etc/pam.d.backup</pre></blockquote> + +<p>The reason for this is that we will be modifying the Linux +system's means of authenticating logins, and if our +configuration goes awry, all users (including +<tt class="literal">root</tt>) will be locked out of the system. In case +the worst happens, we would reboot into single-user mode (by typing +<tt class="literal">linux</tt> <tt class="literal">single</tt> at the LILO: +prompt) or boot a rescue disk, and then we would issue these two +commands:</p> + +<blockquote><pre class="code"># <tt class="userinput"><b>mv /etc/pam.d /etc/pam.d.bad</b></tt> +# <tt class="userinput"><b>mv /etc/pam.d.backup /etc/pam.d</b></tt></pre></blockquote> + +<p>Be very careful to make sure you can recover from any errors you make +because when PAM encounters any configuration information it +doesn't understand, its action is not to allow +access. This means you must be sure to enter everything correctly! +You might want to leave yourself logged in as root on a spare virtual +terminal while you are modifying your PAM configuration to ensure +yourself a means of easy recovery.</p> + +<p>In the <em class="filename">/etc/pam.d</em> directory, you will encounter +a file for each service that uses PAM. We are interested only in the +file corresponding to the login service, which is called +<em class="filename">login</em>. It contains the following lines:</p> + +<blockquote><pre class="code">auth required /lib/security/pam_securetty.so +auth required /lib/security/pam_stack.so service=system-auth +auth required /lib/security/pam_nologin.so +account required /lib/security/pam_stack.so service=system-auth +password required /lib/security/pam_stack.so service=system-auth +session required /lib/security/pam_stack.so service=system-auth +session optional /lib/security/pam_console.so</pre></blockquote> + +<p>The lines starting with <tt class="literal">auth</tt> are related to the +function of authentication—that is, printing a password prompt, +accepting the password, verifying that it is correct, and matching +the user to a valid user and group ID. The line starting with +<tt class="literal">account</tt> is for account management, which allows +access to be controlled by other factors, such as what times during +the day a user is allowed access. We are not concerned with the lines +starting with <tt class="literal">password</tt> or +<tt class="literal">session</tt> because winbind does not add to either of +those functions.</p> + +<p>The third column lists the PAM module, possibly with arguments, that +is called in for the task. The +<em class="filename">pam_stack.so</em><a name="INDEX-113"/> module has been added by Red Hat to act +somewhat like a macro or a subroutine. It calls the file in the +<em class="filename">pam.d</em> directory named by the service argument. +In this case, the file <em class="filename">/etc/pam.d/system-auth</em> +contains a common set of lines that are used as a default for many +services. Because we want to customize the login service for winbind, +we first replace the <em class="filename">pam_stack.so</em> lines for +<tt class="literal">auth</tt> and <tt class="literal">account</tt> with the +<tt class="literal">auth</tt> and <tt class="literal">account</tt> lines from +<em class="filename">/etc/pam.d/system-auth</em>. This yields:</p> + +<blockquote><pre class="code">auth required /lib/security/pam_securetty.so +<b class="emphasis-bold">auth required /lib/security/pam_env.so</b> +<b class="emphasis-bold">auth sufficient /lib/security/pam_unix.so likeauth nullok</b> +<b class="emphasis-bold">auth required /lib/security/pam_deny.so</b> +auth required /lib/security/pam_nologin.so +<b class="emphasis-bold">account required /lib/security/pam_unix.so</b> +password required /lib/security/pam_stack.so service=system-auth +session required /lib/security/pam_stack.so service=system-auth +session optional /lib/security/pam_console.so</pre></blockquote> + +<p>To add winbind support, we need to add a line in both the +<tt class="literal">auth</tt> and <tt class="literal">account</tt> sections to +call the +<em class="filename">pam_winbind.so</em><a name="INDEX-114"/> module:</p> + +<blockquote><pre class="code">auth required /lib/security/pam_securetty.so +auth required /lib/security/pam_env.so +<b class="emphasis-bold">auth sufficient /lib/security/pam_winbind.so</b> +auth sufficient /lib/security/pam_unix.so <b class="emphasis-bold">use_first_pass</b> likeauth nullok +auth required /lib/security/pam_deny.so +auth required /lib/security/pam_nologin.so +<b class="emphasis-bold">account sufficient /lib/security/pam_winbind.so</b> +account required /lib/security/pam_unix.so +password required /lib/security/pam_stack.so service=system-auth +session required /lib/security/pam_stack.so service=system-auth +session optional /lib/security/pam_console.so</pre></blockquote> + +<p>The keywords <tt class="literal">required</tt> and +<tt class="literal">sufficient</tt> in the second column are significant. +The keyword <tt class="literal">required</tt> specifies that the result +returned by the module (either to pass or fail the authentication) +must be taken into account, whereas the keyword +<tt class="literal">sufficient</tt> specifies that if the module +successfully authenticates the user, no further lines need to be +processed. By specifying <tt class="literal">sufficient</tt> for the +<em class="filename">pam_winbind.so</em> module, we let winbind attempt to +authenticate users, and if it succeeds, the PAM system returns to the +application. If the <em class="filename">pam_winbind.so</em> module +doesn't find the user or the password does not +match, the PAM system continues with the next line, which performs +authentication according to the usual Linux user authentication. This +way, both domain users and local users can log in.</p> + +<p>Notice that we also added the <tt class="literal">use_first_pass</tt> +argument to the <em class="filename">pam_unix.so</em> module in the +<tt class="literal">auth</tt> section. By default, both the +<em class="filename">pam_winbind.so</em> and +<em class="filename">pam_unix.so</em> modules print a password prompt and +accept a password. In cases where users are logging in to the Linux +system using their local accounts, this would require them to enter +their password twice. The <tt class="literal">user_first_pass</tt> argument +tells the <em class="filename">pam_unix.so</em> module to reuse the +password that was given to the <em class="filename">pam_winbind.so</em> +module, which results in users having to enter the password only +once.</p> + +<p>After modifying the <em class="filename">login</em> configuration file, +switch to a spare virtual console and make sure you can still log in +using a regular Linux account. If not, check your modifications +carefully and try again until you get it right. Then log in using a +domain user account from the Windows PDC database to check that the +winbind authentication works. You will need to specify the username +in <em class="replaceable">DOMAIN</em>\<em class="replaceable">user</em> +format, like this:</p> + +<blockquote><pre class="code">login: METRAN\linda +Password:</pre></blockquote> + +<p>More information on configuring winbind can be found in the Samba +source distribution file +<em class="filename">docs/htmldocs/winbind.html</em>, and in the +<em class="emphasis">winbindd</em> manual page. If you would like to learn +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 +a starting place. Some of the documentation for Linux PAM, including +Red Hat's extensions, can also be found on Red Hat +Linux in +<em class="filename">/usr/share/doc/pam-</em><em class="replaceable">version</em>. +<a name="INDEX-115"/></p> + + +</div> + + +<div class="sect2"><a name="samba2-CHP-9-SECT-5.5"/> + +<h3 class="head2">winbind Configuration Options</h3> + +<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 +that you can use to configure winbind.</p> + +<a name="samba2-CHP-9-TABLE-9"/><h4 class="head4">Table 9-9. winbind options</h4><table border="1"> + + + + + + +<tr> +<th> +<p>Option</p> +</th> +<th> +<p>Parameters</p> +</th> +<th> +<p>Function</p> +</th> +<th> +<p>Default</p> +</th> +<th> +<p>Scope</p> +</th> +</tr> + + +<tr> +<td> +<p><tt class="literal">winbind</tt> <tt class="literal">separator</tt></p> +</td> +<td> +<p>string (single character)</p> +</td> +<td> +<p>Character to use as a separator in domain usernames and group names</p> +</td> +<td> +<p>Backslash (<tt class="literal">\</tt>)</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">winbind uid</tt></p> +</td> +<td> +<p>string (numeric range)</p> +</td> +<td> +<p>Range of UIDs for RID-to-UID mapping</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">winbind gid</tt></p> +</td> +<td> +<p>string (numeric range)</p> +</td> +<td> +<p>Range of GIDs for RID-to-GID mapping</p> +</td> +<td> +<p>None</p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">winbind cache time</tt></p> +</td> +<td> +<p>numeric</p> +</td> +<td> +<p>Number of seconds the <em class="emphasis">winbindd</em> daemon caches +user and group data</p> +</td> +<td> +<p><tt class="literal">15</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">template</tt> <tt class="literal">homedir</tt></p> +</td> +<td> +<p>string (directory name)</p> +</td> +<td> +<p>Directory to be used as the home directory of the logged-in domain +user</p> +</td> +<td> +<p><tt class="literal">/home/%D/%U</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> +<tr> +<td> +<p><tt class="literal">template</tt> <tt class="literal">shell</tt></p> +</td> +<td> +<p>string (command name)</p> +</td> +<td> +<p>The program to use as the logged-in domain user's +shell</p> +</td> +<td> +<p><tt class="literal">/bin/false</tt></p> +</td> +<td> +<p>Global</p> +</td> +</tr> + +</table> + + +<div class="sect3"><a name="samba2-CHP-9-SECT-5.5.1"/> + +<a name="INDEX-118"/><h3 class="head3">winbind separator</h3> + +<p>On Windows systems, the backslash (<tt class="literal">\</tt>) is commonly +used as a separator in file names, UNCs, and the names of domain +users and groups. For example, an account in the METRAN domain with a +username of <tt class="literal">linda</tt> would be written as +<tt class="literal">METRAN\linda</tt>. On Unix systems, the backslash is +commonly used as a metacharacter for quoting, so the account would +have to be specified as <tt class="literal">METRAN\\linda</tt> or +'<tt class="literal">METRAN\linda</tt>'. The winbind separator parameter +allows another character to be used instead of the backslash +character, making it much easier to type in domain user and group +names. For example, with:</p> + +<blockquote><pre class="code">[global] + winbind separator = +</pre></blockquote> + +<p>the aforementioned account could be written simply as +<tt class="literal">METRAN+linda</tt> on the Unix host, making it +unnecessary to use additional backslashes or single quotes. Winbind +then uses the same format for reporting domain user and group names.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-5.5.2"/> + +<a name="INDEX-119"/><h3 class="head3">winbind uid</h3> + +<p>As part of <em class="emphasis">winbindd</em> 's task of +letting Windows NT domain users function as local users on the Unix +host, <em class="emphasis">winbindd</em> supplies a Unix UID that is +linked to the Windows RID of the domain user. The +<tt class="literal">winbind</tt> <tt class="literal">uid</tt> parameter allows +the Unix system administrator to allocate a range of UIDs for this +purpose. It is very important that this range not overlap any UIDs +used for other purposes on the Unix system, so we recommend you begin +your range at a very high number, one much larger than the number of +local users and NIS users that will ever exist. For example, +<tt class="literal">winbind</tt> <tt class="literal">uid</tt> might be defined +as:</p> + +<blockquote><pre class="code">[global] + winbind uid = 10000-15000</pre></blockquote> + +<p>on a system that would never have more than 9,999 local and NIS +users, or for that matter, any other entries in +<em class="filename">/etc/passwd</em> that would use up another UID. +Because the example allocates 5,000 UIDs to +<em class="emphasis">winbindd</em>, the assumption is that there will +never be more than 5,000 domain users accessing the Samba host.</p> + +<p>If your method for adding new local users to the system assigns UIDs +automatically, make sure it does not assign them within the range of +UIDs allocated to winbind. This might happen if the algorithm used +adds 1 to the highest UID assigned thus far.</p> + +<p>There is no default for <tt class="literal">winbind</tt> +<tt class="literal">uid</tt>, so you must specify it in your Samba +configuration file for winbind to work.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-5.5.3"/> + +<a name="INDEX-120"/><h3 class="head3">winbind gid</h3> + +<p>This option works like <tt class="literal">winbind</tt> +<tt class="literal">uid</tt>, except that it is for allocating a range of +GIDs for use with <em class="emphasis">winbindd</em>. You might not need +to allocate as many GIDs as UIDs because you probably have relatively +few domain groups that need corresponding GIDs. (In many cases, users +are all members of the Domain Users group, requiring only one GID.) +However, it is best to play it safe, so make sure to allocate many +more GIDs than you think you will need.</p> + +<p>As with <tt class="literal">winbind</tt> <tt class="literal">uid</tt>, if you are +using a method of adding new local users to your Unix host that +automatically assigns GIDs, either make sure the method used +doesn't conflict with winbind or set the GIDs +manually.</p> + +<p>There is no default for <tt class="literal">winbind</tt> +<tt class="literal">gid</tt>, so you must specify it in your Samba +configuration file for winbind to work.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-5.5.4"/> + +<a name="INDEX-121"/><h3 class="head3">winbind cache time</h3> + +<p>The <em class="emphasis">winbindd</em> daemon maintains a cache of user +and group data that has been retrieved from the Windows PDC to reduce +network queries and increase performance. The +<tt class="literal">winbind</tt> <tt class="literal">cache</tt> +<tt class="literal">time</tt> parameter allows the amount of time (in +seconds) <em class="emphasis">winbindd</em> can use the cached data before +querying the PDC to check for an update. By default, this interval is +set to 15 seconds. This means that when any part of a user or group +account on the PDC is modified, it can take up to 15 seconds for +<em class="emphasis">winbindd</em> to update its own database.</p> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-5.5.5"/> + +<a name="INDEX-122"/><h3 class="head3">template homedir</h3> + +<p>When the local Unix system is configured to allow domain users to log +in, the user must be provided with a home directory for many +programs, including command shells, to function properly. The +<tt class="literal">template</tt> <tt class="literal">homedir</tt> option is used +to set the name of the home directory. In the name of the directory, +<tt class="literal">%D</tt> is replaced by the name of the Windows NT +domain the user is in, and <tt class="literal">%U</tt> is replaced by his +username. By default, <tt class="literal">template</tt> +<tt class="literal">homedir</tt> is set to <tt class="literal">/home/%D/%U</tt>, +which works fine for a network in which there might be more than one +Windows NT domain, and it is possible for different people in +different domains to have the same username. If you are sure you will +never have more than one Windows NT domain on your network, or you +have more than one domain but know for sure that unique users have +identical usernames in each multiple domain, you might prefer to set +<tt class="literal">template</tt> <tt class="literal">homedir</tt> like this:</p> + +<blockquote><pre class="code">[global] + template homedir = /home/%U</pre></blockquote> + + +</div> + + + +<div class="sect3"><a name="samba2-CHP-9-SECT-5.5.6"/> + +<a name="INDEX-123"/><h3 class="head3">template shell</h3> + +<p>This option specifies the program to use as the shell for domain +users who are logged in to the Unix host. By default, it is set to +<em class="emphasis">/bin/false</em>, which effectively denies domain +users to log in. If you wish to allow logins for domain users, set +<tt class="literal">template</tt> <tt class="literal">shell</tt> to a valid +command shell (or other program) that you want to act as the textual +interface the domain users will receive when logged in. A common +setting on Linux would be:</p> + +<blockquote><pre class="code">[global] + template shell = /bin/bash</pre></blockquote> + +<p>which would give users the Bash shell for their interactive login +sessions. <a name="INDEX-124"/><a name="INDEX-125"/> <a name="INDEX-126"/><a name="INDEX-127"/></p> + + +</div> + + +</div> + + +</div> + +<hr/><h4 class="head4">Footnotes</h4><blockquote><a name="FOOTNOTE-1"/> <p><a href="#FNPTR-1">[1]</a> Having both encrypted and nonencrypted +password clients on your network is one of the reasons why Samba +allows you to include (or not include) various options in the Samba +configuration file based on the client operating system or machine +name variables.</p> <a name="FOOTNOTE-2"/> +<p><a href="#FNPTR-2">[2]</a> This is because the Unix <em class="emphasis">passwd</em> program, +which is the usual target for this operation, allows +<tt class="literal">root</tt> to change a user's password +without the security restriction that requests the old password of +that user.</p> </blockquote><hr/><h4 class="head4"><a href="toc.html">TOC</a></h4></body></html> |