--- /dev/null
+<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>
projects / samba / blobdiff