summaryrefslogtreecommitdiff
path: root/docs-xml/Samba3-HOWTO/TOSHARG-Passdb.xml
diff options
context:
space:
mode:
Diffstat (limited to 'docs-xml/Samba3-HOWTO/TOSHARG-Passdb.xml')
-rw-r--r--docs-xml/Samba3-HOWTO/TOSHARG-Passdb.xml2675
1 files changed, 2675 insertions, 0 deletions
diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-Passdb.xml b/docs-xml/Samba3-HOWTO/TOSHARG-Passdb.xml
new file mode 100644
index 0000000000..957abbfdad
--- /dev/null
+++ b/docs-xml/Samba3-HOWTO/TOSHARG-Passdb.xml
@@ -0,0 +1,2675 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
+<chapter id="passdb">
+<chapterinfo>
+ &author.jelmer;
+ &author.jht;
+ &author.jerry;
+ &author.jeremy;
+ <author>&person.gd;<contrib>LDAP updates</contrib></author>
+ <author>
+ <firstname>Olivier (lem)</firstname><surname>Lemaire</surname>
+ <affiliation>
+ <orgname>IDEALX</orgname>
+ <address><email>olem@IDEALX.org</email></address>
+ </affiliation>
+ </author>
+
+ <pubdate>May 24, 2003</pubdate>
+</chapterinfo>
+<title>Account Information Databases</title>
+
+<para>
+<indexterm><primary>account backends</primary></indexterm>
+<indexterm><primary>password backends</primary></indexterm>
+<indexterm><primary>scalability</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+Early releases of Samba-3 implemented new capability to work concurrently with multiple account backends. This
+capability was removed beginning with release of Samba 3.0.23. Commencing with Samba 3.0.23 it is possible to
+work with only one specified passwd backend.
+</para>
+
+<para>
+<indexterm><primary>passdb backend</primary></indexterm>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>tdbsam</primary></indexterm>
+<indexterm><primary>ldapsam</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>single repository</primary></indexterm>
+The three passdb backends that are fully maintained (actively supported) by the Samba Team are:
+<literal>smbpasswd</literal> (being obsoleted), <literal>tdbsam</literal> (a tdb-based binary file format),
+and <literal>ldapsam</literal> (LDAP directory). Of these, only the <literal>ldapsam</literal> backend
+stores both POSIX (UNIX) and Samba user and group account information in a single repository. The
+<literal>smbpasswd</literal> and <literal>tdbsam</literal> backends store only Samba user accounts.
+</para>
+
+<para>
+In a strict sense, there are three supported account storage and access systems. One of these is considered
+obsolete (smbpasswd). It is recommended to use the <literal>tdbsam</literal> method for all simple systems. Use
+<literal>ldapsam</literal> for larger and more complex networks.
+</para>
+
+<para>
+<indexterm><primary>passdb backend</primary></indexterm>
+<indexterm><primary>account storage mechanisms</primary></indexterm>
+<indexterm><primary>account storage system</primary></indexterm>
+<indexterm><primary>user and trust accounts</primary></indexterm>
+<indexterm><primary>machine trust accounts</primary></indexterm>
+<indexterm><primary>computer accounts</primary></indexterm>
+<indexterm><primary>interdomain trust accounts</primary></indexterm>
+In a strict and literal sense, the passdb backends are account storage mechanisms (or methods) alone. The choice
+of terminology can be misleading, however we are stuck with this choice of wording. This chapter documents the
+nature of the account storage system with a focus on user and trust accounts. Trust accounts have two forms,
+machine trust accounts (computer accounts) and interdomain trust accounts. These are all treated as user-like
+entities.
+</para>
+
+<sect1>
+<title>Features and Benefits</title>
+
+<para>
+Samba-3 provides for complete backward compatibility with Samba-2.2.x functionality
+as follows:
+<indexterm><primary>SAM backend</primary><secondary>smbpasswd</secondary></indexterm>
+<indexterm><primary>SAM backend</primary><secondary>ldapsam_compat</secondary></indexterm>
+<indexterm><primary>encrypted passwords</primary></indexterm>
+</para>
+
+<sect2>
+ <title>Backward Compatibility Account Storage Systems</title>
+
+<variablelist>
+ <varlistentry><term>Plaintext</term>
+ <listitem>
+ <para>
+<indexterm><primary>plaintext</primary></indexterm>
+<indexterm><primary>plaintext authentication</primary></indexterm>
+<indexterm><primary>/etc/passwd</primary></indexterm>
+<indexterm><primary>/etc/shadow</primary></indexterm>
+<indexterm><primary>PAM</primary></indexterm>
+ This isn't really a backend at all, but is listed here for simplicity. Samba can be configured to pass
+ plaintext authentication requests to the traditional UNIX/Linux <filename>/etc/passwd</filename> and
+ <filename>/etc/shadow</filename>-style subsystems. On systems that have Pluggable Authentication Modules
+ (PAM) support, all PAM modules are supported. The behavior is just as it was with Samba-2.2.x, and the
+ protocol limitations imposed by MS Windows clients apply likewise. Please refer to <link
+ linkend="passdbtech">Technical Information</link>, for more information regarding the limitations of plaintext
+ password usage.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry><term>smbpasswd</term>
+ <listitem>
+ <para>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>LanMan passwords</primary></indexterm>
+<indexterm><primary>NT-encrypted passwords</primary></indexterm>
+<indexterm><primary>SAM</primary></indexterm>
+ This option allows continued use of the <filename>smbpasswd</filename>
+ file that maintains a plain ASCII (text) layout that includes the MS Windows
+ LanMan and NT-encrypted passwords as well as a field that stores some
+ account information. This form of password backend does not store any of
+ the MS Windows NT/200x SAM (Security Account Manager) information required to
+ provide the extended controls that are needed for more comprehensive
+ interoperation with MS Windows NT4/200x servers.
+ </para>
+
+ <para>
+ This backend should be used only for backward compatibility with older
+ versions of Samba. It may be deprecated in future releases.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry><term>ldapsam_compat (Samba-2.2 LDAP Compatibility)</term>
+ <listitem>
+ <para>
+<indexterm><primary>ldapsam_compat</primary></indexterm>
+<indexterm><primary>Samba-2.2.x LDAP schema</primary></indexterm>
+<indexterm><primary>OpenLDAP backend</primary></indexterm>
+ There is a password backend option that allows continued operation with
+ an existing OpenLDAP backend that uses the Samba-2.2.x LDAP schema extension.
+ This option is provided primarily as a migration tool, although there is
+ no reason to force migration at this time. This tool will eventually
+ be deprecated.
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
+
+</sect2>
+
+<sect2>
+<title>New Account Storage Systems</title>
+
+<para>
+Samba-3 introduces a number of new password backend capabilities.
+<indexterm><primary>SAM backend</primary><secondary>tdbsam</secondary></indexterm>
+<indexterm><primary>SAM backend</primary><secondary>ldapsam</secondary></indexterm>
+</para>
+
+<variablelist>
+ <varlistentry><term>tdbsam</term>
+ <listitem>
+ <para>
+<indexterm><primary>rich database backend</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+ This backend provides a rich database backend for local servers. This
+ backend is not suitable for multiple domain controllers (i.e., PDC + one
+ or more BDC) installations.
+ </para>
+
+ <para>
+<indexterm><primary>extended SAM</primary></indexterm>
+<indexterm><primary>TDB</primary></indexterm>
+<indexterm><primary>binary format TDB</primary></indexterm>
+<indexterm><primary>trivial database</primary></indexterm>
+<indexterm><primary>system access controls</primary></indexterm>
+<indexterm><primary>MS Windows NT4/200x</primary></indexterm>
+ The <emphasis>tdbsam</emphasis> password backend stores the old <emphasis>
+ smbpasswd</emphasis> information plus the extended MS Windows NT/200x
+ SAM information into a binary format TDB (trivial database) file.
+ The inclusion of the extended information makes it possible for Samba-3
+ to implement the same account and system access controls that are possible
+ with MS Windows NT4/200x-based systems.
+ </para>
+
+ <para>
+<indexterm><primary>simple operation</primary></indexterm>
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+ The inclusion of the <emphasis>tdbsam</emphasis> capability is a direct
+ response to user requests to allow simple site operation without the overhead
+ of the complexities of running OpenLDAP. It is recommended to use this only
+ for sites that have fewer than 250 users. For larger sites or implementations,
+ the use of OpenLDAP or of Active Directory integration is strongly recommended.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry><term>ldapsam</term>
+ <listitem>
+ <para>
+<indexterm><primary>rich directory backend</primary></indexterm>
+<indexterm><primary>distributed account</primary></indexterm>
+ This provides a rich directory backend for distributed account installation.
+ </para>
+
+ <para>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>Samba schema</primary></indexterm>
+<indexterm><primary>schema file</primary></indexterm>
+<indexterm><primary>examples/LDAP</primary></indexterm>
+ Samba-3 has a new and extended LDAP implementation that requires configuration
+ of OpenLDAP with a new format Samba schema. The new format schema file is
+ included in the <filename class="directory">examples/LDAP</filename> directory of the Samba distribution.
+ </para>
+
+ <para>
+<indexterm><primary>expands control abilities</primary></indexterm>
+<indexterm><primary>profile</primary></indexterm>
+<indexterm><primary>home directories</primary></indexterm>
+<indexterm><primary>account access controls</primary></indexterm>
+<indexterm><primary>greater scalability</primary></indexterm>
+ The new LDAP implementation significantly expands the control abilities that
+ were possible with prior versions of Samba. It is now possible to specify
+ <quote>per-user</quote> profile settings, home directories, account access controls, and
+ much more. Corporate sites will see that the Samba Team has listened to their
+ requests both for capability and greater scalability.
+ </para>
+ </listitem>
+ </varlistentry>
+
+</variablelist>
+
+</sect2>
+
+</sect1>
+
+<sect1 id="passdbtech">
+ <title>Technical Information</title>
+
+ <para>
+<indexterm><primary>plaintext passwords</primary></indexterm>
+<indexterm><primary>encrypted passwords</primary></indexterm>
+ Old Windows clients send plaintext passwords over the wire. Samba can check these
+ passwords by encrypting them and comparing them to the hash stored in the UNIX user database.
+ </para>
+
+ <para>
+<indexterm><primary>encrypted passwords</primary></indexterm>
+<indexterm><primary>LanMan</primary></indexterm>
+<indexterm><primary>plaintext passwords</primary></indexterm>
+<indexterm><primary>registry</primary></indexterm>
+ Newer Windows clients send encrypted passwords (LanMan and NT hashes) instead of plaintext passwords over
+ the wire. The newest clients will send only encrypted passwords and refuse to send plaintext passwords unless
+ their registry is tweaked.
+ </para>
+
+ <para>
+<indexterm><primary>UNIX-style encrypted passwords</primary></indexterm>
+<indexterm><primary>converted</primary></indexterm>
+ Many people ask why Samba cannot simply use the UNIX password database. Windows requires
+ passwords that are encrypted in its own format. The UNIX passwords can't be converted to
+ UNIX-style encrypted passwords. Because of that, you can't use the standard UNIX user
+ database, and you have to store the LanMan and NT hashes somewhere else.
+ </para>
+
+ <para>
+<indexterm><primary>differently encrypted passwords</primary></indexterm>
+<indexterm><primary>profile</primary></indexterm>
+<indexterm><primary>workstations</primary></indexterm>
+<indexterm><primary>tdbsam</primary></indexterm>
+ In addition to differently encrypted passwords, Windows also stores certain data for each
+ user that is not stored in a UNIX user database: for example, workstations the user may logon from,
+ the location where the user's profile is stored, and so on. Samba retrieves and stores this
+ information using a <smbconfoption name="passdb backend"/>. Commonly available backends are LDAP,
+ tdbsam, and plain text file. For more information, see the man page for &smb.conf; regarding the
+ <smbconfoption name="passdb backend"/> parameter.
+ </para>
+
+
+ <figure id="idmap-sid2uid">
+ <title>IDMAP: Resolution of SIDs to UIDs.</title>
+ <imagefile scale="40">idmap-sid2uid</imagefile>
+ </figure>
+
+ <para>
+ <indexterm><primary>SID</primary></indexterm>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>SID</primary></indexterm>
+ The resolution of SIDs to UIDs is fundamental to correct operation of Samba. In both cases shown, if winbindd
+ is not running or cannot be contacted, then only local SID/UID resolution is possible. See <link
+ linkend="idmap-sid2uid">resolution of SIDs to UIDs</link> and <link linkend="idmap-uid2sid">resolution of UIDs
+ to SIDs</link> diagrams.
+ </para>
+
+ <figure id="idmap-uid2sid">
+ <title>IDMAP: Resolution of UIDs to SIDs.</title>
+ <imagefile scale="50">idmap-uid2sid</imagefile>
+ </figure>
+
+ <sect2>
+ <title>Important Notes About Security</title>
+
+ <para>
+<indexterm><primary>SMB password encryption</primary></indexterm>
+<indexterm><primary>clear-text passwords</primary></indexterm>
+<indexterm><primary>hashed password equivalent</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>secret</primary></indexterm>
+ The UNIX and SMB password encryption techniques seem similar on the surface. This
+ similarity is, however, only skin deep. The UNIX scheme typically sends clear-text
+ passwords over the network when logging in. This is bad. The SMB encryption scheme
+ never sends the clear-text password over the network, but it does store the 16-byte
+ hashed values on disk. This is also bad. Why? Because the 16 byte hashed values
+ are a <quote>password equivalent.</quote> You cannot derive the user's password from them, but
+ they could potentially be used in a modified client to gain access to a server.
+ This would require considerable technical knowledge on behalf of the attacker but
+ is perfectly possible. You should therefore treat the data stored in whatever passdb
+ backend you use (smbpasswd file, LDAP) as though it contained the clear-text
+ passwords of all your users. Its contents must be kept secret, and the file should
+ be protected accordingly.
+ </para>
+
+ <para>
+<indexterm><primary>password scheme</primary></indexterm>
+<indexterm><primary>plaintext passwords</primary></indexterm>
+<indexterm><primary>compatible</primary></indexterm>
+ Ideally, we would like a password scheme that involves neither plaintext passwords
+ on the network nor plaintext passwords on disk. Unfortunately, this is not available because Samba is stuck with
+ having to be compatible with other SMB systems (Windows NT, Windows for Workgroups, Windows 9x/Me).
+ </para>
+
+ <para>
+<indexterm><primary>encrypted passwords</primary></indexterm>
+<indexterm><primary>plaintext passwords</primary></indexterm>
+ Windows NT 4.0 Service Pack 3 changed the default setting so plaintext passwords
+ are disabled from being sent over the wire. This mandates either the use of encrypted
+ password support or editing the Windows NT registry to re-enable plaintext passwords.
+ </para>
+
+ <para>
+<indexterm><primary>domain security</primary></indexterm>
+<indexterm><primary>domain environment</primary></indexterm>
+ The following versions of Microsoft Windows do not support full domain security protocols,
+ although they may log onto a domain environment:
+ </para>
+
+ <itemizedlist>
+ <listitem><para>MS DOS Network client 3.0 with the basic network redirector installed.</para></listitem>
+ <listitem><para>Windows 95 with the network redirector update installed.</para></listitem>
+ <listitem><para>Windows 98 [Second Edition].</para></listitem>
+ <listitem><para>Windows Me.</para></listitem>
+ </itemizedlist>
+
+ <note>
+ <para>
+<indexterm><primary>Windows XP Home</primary></indexterm>
+<indexterm><primary>domain member</primary></indexterm>
+<indexterm><primary>domain logons</primary></indexterm>
+ MS Windows XP Home does not have facilities to become a domain member, and it cannot participate in domain logons.
+ </para>
+ </note>
+
+ <para>
+ The following versions of MS Windows fully support domain security protocols.
+ </para>
+
+ <itemizedlist>
+ <listitem><para>Windows NT 3.5x.</para></listitem>
+ <listitem><para>Windows NT 4.0.</para></listitem>
+ <listitem><para>Windows 2000 Professional.</para></listitem>
+ <listitem><para>Windows 200x Server/Advanced Server.</para></listitem>
+ <listitem><para>Windows XP Professional.</para></listitem>
+ </itemizedlist>
+
+ <para>
+<indexterm><primary>SMB/CIFS</primary></indexterm>
+<indexterm><primary>authentication</primary></indexterm>
+<indexterm><primary>challenge/response mechanis</primary></indexterm>
+<indexterm><primary>clear-text</primary></indexterm>
+<indexterm><primary>encrypted</primary></indexterm>
+<indexterm><primary>negotiate</primary></indexterm>
+ All current releases of Microsoft SMB/CIFS clients support authentication via the
+ SMB challenge/response mechanism described here. Enabling clear-text authentication
+ does not disable the ability of the client to participate in encrypted authentication.
+ Instead, it allows the client to negotiate either plaintext or encrypted password
+ handling.
+ </para>
+
+ <para>
+<indexterm><primary>cached encrypted password</primary></indexterm>
+<indexterm><primary>plaintext passwords</primary></indexterm>
+<indexterm><primary>registry change</primary></indexterm>
+<indexterm><primary>auto-reconnect</primary></indexterm>
+<indexterm><primary>encrypted passwords</primary></indexterm>
+ MS Windows clients will cache the encrypted password alone. Where plaintext passwords
+ are re-enabled through the appropriate registry change, the plaintext password is never
+ cached. This means that in the event that a network connections should become disconnected
+ (broken), only the cached (encrypted) password will be sent to the resource server to
+ effect an auto-reconnect. If the resource server does not support encrypted passwords, the
+ auto-reconnect will fail. Use of encrypted passwords is strongly advised.
+ </para>
+
+ <sect3>
+ <title>Advantages of Encrypted Passwords</title>
+
+ <itemizedlist>
+ <listitem><para>
+<indexterm><primary>passed across the network</primary></indexterm>
+<indexterm><primary>network sniffer</primary></indexterm>
+<indexterm><primary>SMB server</primary></indexterm>
+ Plaintext passwords are not passed across the network. Someone using a network sniffer
+ cannot just record passwords going to the SMB server.
+ </para></listitem>
+
+ <listitem><para>
+<indexterm><primary>not stored anywhere</primary></indexterm>
+<indexterm><primary>memory</primary></indexterm>
+<indexterm><primary>disk</primary></indexterm>
+ Plaintext passwords are not stored anywhere in memory or on disk.
+ </para></listitem>
+
+ <listitem><para>
+<indexterm><primary>encrypted passwords</primary></indexterm>
+<indexterm><primary>user-level security</primary></indexterm>
+<indexterm><primary>password prompt</primary></indexterm>
+<indexterm><primary>SMB encryption</primary></indexterm>
+ Windows NT does not like talking to a server that does not support encrypted passwords. It will refuse to
+ browse the server if the server is also in user-level security mode. It will insist on prompting the user for
+ the password on each connection, which is very annoying. The only thing you can do to stop this is to use SMB
+ encryption.
+ </para></listitem>
+
+ <listitem><para>
+<indexterm><primary>encrypted password</primary></indexterm>
+<indexterm><primary>automatic reconnects</primary></indexterm>
+ Encrypted password support allows automatic share (resource) reconnects.
+ </para></listitem>
+
+ <listitem><para>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+ Encrypted passwords are essential for PDC/BDC operation.
+ </para></listitem>
+ </itemizedlist>
+ </sect3>
+
+
+ <sect3>
+ <title>Advantages of Non-Encrypted Passwords</title>
+
+ <itemizedlist>
+ <listitem><para>
+<indexterm><primary>cached in memory</primary></indexterm>
+ Plaintext passwords are not kept on disk and are not cached in memory.
+ </para></listitem>
+
+ <listitem><para>
+<indexterm><primary>Login</primary></indexterm>
+<indexterm><primary>FTP</primary></indexterm>
+ Plaintext passwords use the same password file as other UNIX services, such as Login and FTP.
+ </para></listitem>
+
+ <listitem><para>
+<indexterm><primary>Telnet</primary></indexterm>
+<indexterm><primary>FTP</primary></indexterm>
+ Use of other services (such as Telnet and FTP) that send plaintext passwords over
+ the network makes sending them for SMB not such a big deal.
+ </para></listitem>
+ </itemizedlist>
+ </sect3>
+ </sect2>
+
+ <sect2>
+ <title>Mapping User Identifiers between MS Windows and UNIX</title>
+
+ <para>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>SID</primary></indexterm>
+<indexterm><primary>mapping</primary></indexterm>
+ Every operation in UNIX/Linux requires a user identifier (UID), just as in
+ MS Windows NT4/200x this requires a security identifier (SID). Samba provides
+ two means for mapping an MS Windows user to a UNIX/Linux UID.
+ </para>
+
+ <para>
+<indexterm><primary>Samba SAM</primary></indexterm>
+<indexterm><primary>SAM</primary></indexterm>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>account information database</primary></indexterm>
+<indexterm><primary>local user account</primary></indexterm>
+ First, all Samba SAM database accounts require a UNIX/Linux UID that the account will map to. As users are
+ added to the account information database, Samba will call the <smbconfoption name="add user script"/>
+ interface to add the account to the Samba host OS. In essence all accounts in the local SAM require a local
+ user account.
+ </para>
+
+ <para>
+ <indexterm><primary>idmap uid</primary></indexterm>
+ <indexterm><primary>idmap gid</primary></indexterm>
+ <indexterm><primary>UID</primary></indexterm>
+ <indexterm><primary>SAM</primary></indexterm>
+ <indexterm><primary>foreign domain</primary></indexterm>
+ <indexterm><primary>non-member Windows client</primary></indexterm>
+ <indexterm><primary>SID</primary></indexterm>
+ The second way to map Windows SID to UNIX UID is via the <emphasis>idmap uid</emphasis> and
+ <emphasis>idmap gid</emphasis> parameters in &smb.conf;. Please refer to the man page for information about
+ these parameters. These parameters are essential when mapping users from a remote (non-member Windows client
+ or a member of a foreign domain) SAM server.
+ </para>
+
+ </sect2>
+
+ <sect2 id="idmapbackend">
+ <title>Mapping Common UIDs/GIDs on Distributed Machines</title>
+
+ <para>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>GID</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>domain member servers</primary></indexterm>
+<indexterm><primary>NFS</primary></indexterm>
+<indexterm><primary>rsync</primary></indexterm>
+ Samba-3 has a special facility that makes it possible to maintain identical UIDs and GIDs
+ on all servers in a distributed network. A distributed network is one where there exists
+ a PDC, one or more BDCs, and/or one or more domain member servers. Why is this important?
+ This is important if files are being shared over more than one protocol (e.g., NFS) and where
+ users are copying files across UNIX/Linux systems using tools such as <command>rsync</command>.
+ </para>
+
+ <para>
+<indexterm><primary>LDAP-based</primary></indexterm>
+<indexterm><primary>idmap backend</primary></indexterm>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>GID</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>SAM backend</primary></indexterm>
+<indexterm><primary>LDAP idmap Backend</primary></indexterm>
+ <indexterm><primary>idmap backend</primary></indexterm>
+ The special facility is enabled using a parameter called <parameter>idmap backend</parameter>.
+ The default setting for this parameter is an empty string. Technically it is possible to use
+ an LDAP-based idmap backend for UIDs and GIDs, but it makes most sense when this is done for
+ network configurations that also use LDAP for the SAM backend.
+ <link linkend="idmapbackendexample">Example Configuration with the LDAP idmap Backend</link>
+ shows that configuration.
+ </para>
+
+<indexterm><primary>SAM backend</primary><secondary>ldapsam</secondary></indexterm>
+<example id="idmapbackendexample">
+<title>Example Configuration with the LDAP idmap Backend</title>
+<smbconfblock>
+<smbconfsection name="[global]"/>
+<smbconfoption name="idmap backend">ldap:ldap://ldap-server.quenya.org:636</smbconfoption>
+<smbconfcomment>Alternatively, this could be specified as:</smbconfcomment>
+<smbconfoption name="idmap backend">ldap:ldaps://ldap-server.quenya.org</smbconfoption>
+</smbconfblock>
+</example>
+
+ <para>
+<indexterm><primary>LDAP backends</primary></indexterm>
+<indexterm><primary>PADL Software</primary></indexterm>
+ A network administrator who wants to make significant use of LDAP backends will sooner or later be
+ exposed to the excellent work done by PADL Software. PADL <ulink url="http://www.padl.com"/> have
+ produced and released to open source an array of tools that might be of interest. These tools include:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+<indexterm><primary>nss_ldap</primary></indexterm>
+<indexterm><primary>NSS</primary></indexterm>
+<indexterm><primary>AIX</primary></indexterm>
+<indexterm><primary>Linux</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>Solaris</primary></indexterm>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>GID</primary></indexterm>
+ <emphasis>nss_ldap:</emphasis> An LDAP name service switch (NSS) module to provide native
+ name service support for AIX, Linux, Solaris, and other operating systems. This tool
+ can be used for centralized storage and retrieval of UIDs and GIDs.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+<indexterm><primary>pam_ldap</primary></indexterm>
+<indexterm><primary>PAM</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>access authentication</primary></indexterm>
+ <emphasis>pam_ldap:</emphasis> A PAM module that provides LDAP integration for UNIX/Linux
+ system access authentication.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+<indexterm><primary>idmap_ad</primary></indexterm>
+<indexterm><primary>IDMAP backend</primary></indexterm>
+<indexterm><primary>RFC 2307</primary></indexterm>
+<indexterm><primary>PADL</primary></indexterm>
+ <emphasis>idmap_ad:</emphasis> An IDMAP backend that supports the Microsoft Services for
+ UNIX RFC 2307 schema available from the PADL Web
+ <ulink url="http://www.padl.com/download/xad_oss_plugins.tar.gz">site</ulink>.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ </sect2>
+
+ <sect2>
+ <title>Comments Regarding LDAP</title>
+
+ <para>
+<indexterm><primary>LDAP</primary><secondary>directories</secondary></indexterm>
+<indexterm><primary>architecture</primary></indexterm>
+<indexterm><primary>FIM</primary></indexterm>
+<indexterm><primary>SSO</primary></indexterm>
+ There is much excitement and interest in LDAP directories in the information technology world
+ today. The LDAP architecture was designed to be highly scalable. It was also designed for
+ use across a huge number of potential areas of application encompassing a wide range of operating
+ systems and platforms. LDAP technologies are at the heart of the current generations of Federated
+ Identity Management (FIM) solutions that can underlie a corporate Single Sign-On (SSO) environment.
+ </para>
+
+ <para>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>eDirectory</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>authentication</primary></indexterm>
+ LDAP implementations have been built across a wide variety of platforms. It lies at the core of Microsoft
+ Windows Active Directory services (ADS), Novell's eDirectory, as well as many others. Implementation of the
+ directory services LDAP involves interaction with legacy as well as new generation applications, all of which
+ depend on some form of authentication services.
+ </para>
+
+ <para>
+<indexterm><primary>LDAP directory</primary></indexterm>
+<indexterm><primary>authentication</primary></indexterm>
+<indexterm><primary>access controls</primary></indexterm>
+<indexterm><primary>intermediate tools</primary></indexterm>
+<indexterm><primary>middle-ware</primary></indexterm>
+<indexterm><primary>central environment</primary></indexterm>
+<indexterm><primary>infrastructure</primary></indexterm>
+<indexterm><primary>login shells</primary></indexterm>
+<indexterm><primary>mail</primary></indexterm>
+<indexterm><primary>messaging systems</primary></indexterm>
+<indexterm><primary>quota controls</primary></indexterm>
+<indexterm><primary>printing systems</primary></indexterm>
+<indexterm><primary>DNS servers</primary></indexterm>
+<indexterm><primary>DHCP servers</primary></indexterm>
+ UNIX services can utilize LDAP directory information for authentication and access controls
+ through intermediate tools and utilities. The total environment that consists of the LDAP directory
+ and the middle-ware tools and utilities makes it possible for all user access to the UNIX platform
+ to be managed from a central environment and yet distributed to wherever the point of need may
+ be physically located. Applications that benefit from this infrastructure include: UNIX login
+ shells, mail and messaging systems, quota controls, printing systems, DNS servers, DHCP servers,
+ and also Samba.
+ </para>
+
+ <para>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>passdb backend</primary></indexterm>
+<indexterm><primary>scalable</primary></indexterm>
+<indexterm><primary>SAM backend</primary></indexterm>
+<indexterm><primary>LDAP directory</primary></indexterm>
+<indexterm><primary>management costs</primary></indexterm>
+ Many sites are installing LDAP for the first time in order to provide a scalable passdb backend
+ for Samba. Others are faced with the need to adapt an existing LDAP directory to new uses such
+ as for the Samba SAM backend. Whatever your particular need and attraction to Samba may be,
+ decisions made in respect of the design of the LDAP directory structure and its implementation
+ are of a durable nature for the site. These have far-reaching implications that affect long-term
+ information systems management costs.
+ </para>
+
+ <para>
+<indexterm><primary>LDAP deployment</primary></indexterm>
+<indexterm><primary>Directory Information Tree</primary><see>DIT</see></indexterm>
+ Do not rush into an LDAP deployment. Take the time to understand how the design of the Directory
+ Information Tree (DIT) may impact current and future site needs, as well as the ability to meet
+ them. The way that Samba SAM information should be stored within the DIT varies from site to site
+ and with each implementation new experience is gained. It is well understood by LDAP veterans that
+ first implementations create awakening, second implementations of LDAP create fear, and
+ third-generation deployments bring peace and tranquility.
+ </para>
+
+ <sect3>
+ <title>Caution Regarding LDAP and Samba</title>
+
+ <para>
+<indexterm><primary>POSIX identity</primary></indexterm>
+<indexterm><primary>networking environment</primary></indexterm>
+<indexterm><primary>user accounts</primary></indexterm>
+<indexterm><primary>group accounts</primary></indexterm>
+<indexterm><primary>machine trust accounts</primary></indexterm>
+<indexterm><primary>interdomain trust accounts</primary></indexterm>
+<indexterm><primary>intermediate information</primary></indexterm>
+ Samba requires UNIX POSIX identity information as well as a place to store information that is
+ specific to Samba and the Windows networking environment. The most used information that must
+ be dealt with includes: user accounts, group accounts, machine trust accounts, interdomain
+ trust accounts, and intermediate information specific to Samba internals.
+ </para>
+
+ <para>
+<indexterm><primary>deployment guidelines</primary></indexterm>
+<indexterm><primary>HOWTO documents</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+ The example deployment guidelines in this book, as well as other books and HOWTO documents
+ available from the internet may not fit with established directory designs and implementations.
+ The existing DIT may not be able to accommodate the simple information layout proposed in common
+ sources. Additionally, you may find that the common scripts and tools that are used to provision
+ the LDAP directory for use with Samba may not suit your needs.
+ </para>
+
+ <para>
+<indexterm><primary>existing LDAP DIT</primary></indexterm>
+ It is not uncommon, for sites that have existing LDAP DITs to find necessity to generate a
+ set of site-specific scripts and utilities to make it possible to deploy Samba within the
+ scope of site operations. The way that user and group accounts are distributed throughout
+ the DIT may make this a challenging matter. The solution will, of course, be rewarding, but
+ the journey to it may be challenging. Take time to understand site needs and do not rush
+ into deployment.
+ </para>
+
+ <para>
+<indexterm><primary>scripts</primary></indexterm>
+<indexterm><primary>tools</primary></indexterm>
+ Above all, do not blindly use scripts and tools that are not suitable for your site. Check
+ and validate all scripts before you execute them to make sure that the existing infrastructure
+ will not be damaged by inadvertent use of an inappropriate tool.
+ </para>
+
+ </sect3>
+
+ </sect2>
+
+ <sect2>
+ <title>LDAP Directories and Windows Computer Accounts</title>
+
+ <para>
+<indexterm><primary>turnkey solution</primary></indexterm>
+<indexterm><primary>LDAP.</primary></indexterm>
+<indexterm><primary>frustrating experience</primary></indexterm>
+ Samba doesn't provide a turnkey solution to LDAP. It is best to deal with the design and
+ configuration of an LDAP directory prior to integration with Samba. A working knowledge
+ of LDAP makes Samba integration easy, and the lack of a working knowledge of LDAP can make
+ it a frustrating experience.
+ </para>
+
+ <para>
+<indexterm><primary>computer accounts</primary></indexterm>
+<indexterm><primary>machine accounts</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+ Computer (machine) accounts can be placed wherever you like in an LDAP directory subject
+ to some constraints that are described in this chapter.
+ </para>
+
+ <para>
+<indexterm><primary>POSIX</primary></indexterm>
+<indexterm><primary>sambaSamAccount</primary></indexterm>
+<indexterm><primary>computer accounts</primary></indexterm>
+<indexterm><primary>machine accounts</primary></indexterm>
+<indexterm><primary>Windows NT4/200X</primary></indexterm>
+<indexterm><primary>user account</primary></indexterm>
+<indexterm><primary>trust accounts</primary></indexterm>
+ The POSIX and sambaSamAccount components of computer (machine) accounts are both used by Samba.
+ Thus, machine accounts are treated inside Samba in the same way that Windows NT4/200X treats
+ them. A user account and a machine account are indistinquishable from each other, except that
+ the machine account ends in a $ character, as do trust accounts.
+ </para>
+
+ <para>
+<indexterm><primary>user</primary></indexterm>
+<indexterm><primary>group</primary></indexterm>
+<indexterm><primary>machine</primary></indexterm>
+<indexterm><primary>trust</primary></indexterm>
+<indexterm><primary>UID</primary></indexterm>
+ The need for Windows user, group, machine, trust, and other accounts to be tied to a valid UNIX
+ UID is a design decision that was made a long way back in the history of Samba development. It
+ is unlikely that this decision will be reversed or changed during the remaining life of the
+ Samba-3.x series.
+ </para>
+
+ <para>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>SID</primary></indexterm>
+<indexterm><primary>NSS</primary></indexterm>
+ The resolution of a UID from the Windows SID is achieved within Samba through a mechanism that
+ must refer back to the host operating system on which Samba is running. The NSS is the preferred
+ mechanism that shields applications (like Samba) from the need to know everything about every
+ host OS it runs on.
+ </para>
+
+ <para>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>passwd</primary></indexterm>
+<indexterm><primary>shadow</primary></indexterm>
+<indexterm><primary>group</primary></indexterm>
+<indexterm><primary>NSS</primary></indexterm>
+<indexterm><primary>winbindd</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+ Samba asks the host OS to provide a UID via the <quote>passwd</quote>, <quote>shadow</quote>,
+ and <quote>group</quote> facilities in the NSS control (configuration) file. The best tool
+ for achieving this is left up to the UNIX administrator to determine. It is not imposed by
+ Samba. Samba provides winbindd with its support libraries as one method. It is
+ possible to do this via LDAP, and for that Samba provides the appropriate hooks so that
+ all account entities can be located in an LDAP directory.
+ </para>
+
+ <para>
+<indexterm><primary>PADL</primary></indexterm>
+<indexterm><primary>nss_ldap</primary></indexterm>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>documentation</primary></indexterm>
+ For many the weapon of choice is to use the PADL nss_ldap utility. This utility must
+ be configured so that computer accounts can be resolved to a POSIX/UNIX account UID. That
+ is fundamentally an LDAP design question. The information provided on the Samba list and
+ in the documentation is directed at providing working examples only. The design
+ of an LDAP directory is a complex subject that is beyond the scope of this documentation.
+ </para>
+
+ </sect2>
+
+</sect1>
+
+<sect1 id="acctmgmttools">
+<title>Account Management Tools</title>
+
+<para>
+<indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>machine accounts</primary></indexterm>
+<indexterm><primary>management tools</primary></indexterm>
+Samba provides two tools for management of user and machine accounts:
+<command>smbpasswd</command> and <command>pdbedit</command>.
+</para>
+
+<para>
+<indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>password aging</primary></indexterm>
+<indexterm><primary>failed logins</primary></indexterm>
+The <command>pdbedit</command> can be used to manage account policies in addition to
+Samba user account information. The policy management capability is used to administer
+domain default settings for password aging and management controls to handle failed login
+attempts.
+</para>
+
+<para>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>storage mechanism</primary></indexterm>
+<indexterm><primary>SambaSAMAccount</primary></indexterm>
+<indexterm><primary>net</primary></indexterm>
+Some people are confused when reference is made to <literal>smbpasswd</literal> because the
+name refers to a storage mechanism for SambaSAMAccount information, but it is also the name
+of a utility tool. That tool is destined to eventually be replaced by new functionality that
+is being added to the <command>net</command> toolset (see <link linkend="NetCommand">the Net Command</link>.
+</para>
+
+ <sect2>
+ <title>The <command>smbpasswd</command> Tool</title>
+
+ <para>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>passwd</primary></indexterm>
+<indexterm><primary>yppasswd</primary></indexterm>
+<indexterm><primary>passdb backend</primary></indexterm>
+<indexterm><primary>storage methods</primary></indexterm>
+ The <command>smbpasswd</command> utility is similar to the <command>passwd</command>
+ and <command>yppasswd</command> programs. It maintains the two 32 byte password
+ fields in the passdb backend. This utility operates independently of the actual
+ account and password storage methods used (as specified by the <parameter>passdb
+ backend</parameter> in the &smb.conf; file.
+ </para>
+
+ <para>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>client-server mode</primary></indexterm>
+ <command>smbpasswd</command> works in a client-server mode where it contacts the
+ local smbd to change the user's password on its behalf. This has enormous benefits.
+ </para>
+
+ <para>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>change passwords</primary></indexterm>
+ <command>smbpasswd</command> has the capability to change passwords on Windows NT
+ servers (this only works when the request is sent to the NT PDC if changing an NT
+ domain user's password).
+ </para>
+
+ <para>
+ <indexterm><primary>user management</primary></indexterm>
+ <indexterm><primary>user account</primary><secondary>Adding/Deleting</secondary></indexterm>
+ <command>smbpasswd</command> can be used to:
+ </para>
+
+ <itemizedlist>
+ <listitem><para><emphasis>add</emphasis> user or machine accounts.</para></listitem>
+ <listitem><para><emphasis>delete</emphasis> user or machine accounts.</para></listitem>
+ <listitem><para><emphasis>enable</emphasis> user or machine accounts.</para></listitem>
+ <listitem><para><emphasis>disable</emphasis> user or machine accounts.</para></listitem>
+ <listitem><para><emphasis>set to NULL</emphasis> user passwords.</para></listitem>
+ <listitem><para><emphasis>manage</emphasis> interdomain trust accounts.</para></listitem>
+ </itemizedlist>
+
+ <para>
+ To run smbpasswd as a normal user, just type:
+ </para>
+
+ <para>
+<screen>
+&prompt;<userinput>smbpasswd</userinput>
+<prompt>Old SMB password: </prompt><userinput><replaceable>secret</replaceable></userinput>
+</screen>
+ For <replaceable>secret</replaceable>, type the old value here or press return if
+ there is no old password.
+<screen>
+<prompt>New SMB Password: </prompt><userinput><replaceable>new secret</replaceable></userinput>
+<prompt>Repeat New SMB Password: </prompt><userinput><replaceable>new secret</replaceable></userinput>
+</screen>
+ </para>
+
+ <para>
+ If the old value does not match the current value stored for that user, or the two
+ new values do not match each other, then the password will not be changed.
+ </para>
+
+ <para>
+<indexterm><primary>SMB password</primary></indexterm>
+ When invoked by an ordinary user, the command will allow only the user to change his or her own
+ SMB password.
+ </para>
+
+ <para>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>SMB password</primary></indexterm>
+ When run by root, <command>smbpasswd</command> may take an optional argument specifying
+ the username whose SMB password you wish to change. When run as root, <command>smbpasswd</command>
+ does not prompt for or check the old password value, thus allowing root to set passwords
+ for users who have forgotten their passwords.
+ </para>
+
+ <para>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>passwd</primary></indexterm>
+<indexterm><primary>yppasswd</primary></indexterm>
+<indexterm><primary>change capabilities</primary></indexterm>
+ <command>smbpasswd</command> is designed to work in the way familiar to UNIX
+ users who use the <command>passwd</command> or <command>yppasswd</command> commands.
+ While designed for administrative use, this tool provides essential user-level
+ password change capabilities.
+ </para>
+
+ <para>
+<indexterm><primary>smbpasswd</primary></indexterm>
+ For more details on using <command>smbpasswd</command>, refer to the man page (the
+ definitive reference).
+ </para>
+ </sect2>
+
+ <sect2 id="pdbeditthing">
+ <title>The <command>pdbedit</command> Tool</title>
+
+ <para>
+ <indexterm><primary>pdbedit</primary></indexterm>
+ <indexterm><primary>User Management</primary></indexterm>
+ <indexterm><primary>account policy</primary></indexterm>
+ <indexterm><primary>User Accounts</primary><secondary>Adding/Deleting</secondary></indexterm>
+ <command>pdbedit</command> is a tool that can be used only by root. It is used to
+ manage the passdb backend, as well as domain-wide account policy settings. <command>pdbedit</command>
+ can be used to:
+ </para>
+
+ <itemizedlist>
+ <listitem><para>add, remove, or modify user accounts.</para></listitem>
+ <listitem><para>list user accounts.</para></listitem>
+ <listitem><para>migrate user accounts.</para></listitem>
+ <listitem><para>migrate group accounts.</para></listitem>
+ <listitem><para>manage account policies.</para></listitem>
+ <listitem><para>manage domain access policy settings.</para></listitem>
+ </itemizedlist>
+
+ <para>
+ <indexterm><primary>Sarbanes-Oxley</primary></indexterm>
+ Under the terms of the Sarbanes-Oxley Act of 2002, American businesses and organizations are mandated to
+ implement a series of <literal>internal controls</literal> and procedures to communicate, store,
+ and protect financial data. The Sarbanes-Oxley Act has far reaching implications in respect of:
+ </para>
+
+ <orderedlist>
+ <listitem><para>Who has access to information systems that store financial data.</para></listitem>
+ <listitem><para>How personal and financial information is treated among employees and business
+ partners.</para></listitem>
+ <listitem><para>How security vulnerabilities are managed.</para></listitem>
+ <listitem><para>Security and patch level maintenance for all information systems.</para></listitem>
+ <listitem><para>How information systems changes are documented and tracked.</para></listitem>
+ <listitem><para>How information access controls are implemented and managed.</para></listitem>
+ <listitem><para>Auditability of all information systems in respect of change and security.</para></listitem>
+ <listitem><para>Disciplinary procedures and controls to ensure privacy.</para></listitem>
+ </orderedlist>
+
+ <para>
+ <indexterm><primary>accountability</primary></indexterm>
+ <indexterm><primary>compliance</primary></indexterm>
+ In short, the Sarbanes-Oxley Act of 2002 is an instrument that enforces accountability in respect of
+ business related information systems so as to ensure the compliance of all information systems that
+ are used to store personal information and particularly for financial records processing. Similar
+ accountabilities are being demanded around the world.
+ </para>
+
+ <para>
+ <indexterm><primary>laws</primary></indexterm>
+ <indexterm><primary>regulations</primary></indexterm>
+ <indexterm><primary>pdbedit</primary></indexterm>
+ <indexterm><primary>access controls</primary></indexterm>
+ <indexterm><primary>manage accounts</primary></indexterm>
+ The need to be familiar with the Samba tools and facilities that permit information systems operation
+ in compliance with government laws and regulations is clear to all. The <command>pdbedit</command> is
+ currently the only Samba tool that provides the capacity to manage account and systems access controls
+ and policies. During the remaining life-cycle of the Samba-3 series it is possible the new tools may
+ be implemented to aid in this important area.
+ </para>
+
+ <para>
+ Domain global policy controls available in Windows NT4 compared with Samba
+ is shown in <link linkend="policycontrols">NT4 Domain v's Samba Policy Controls</link>.
+ </para>
+
+ <table id="policycontrols">
+ <title>NT4 Domain v's Samba Policy Controls</title>
+ <tgroup cols="5">
+ <colspec align="left" colwidth="2*"/>
+ <colspec align="left" colwidth="2*"/>
+ <colspec align="center" colwidth="1*"/>
+ <colspec align="center" colwidth="1*"/>
+ <colspec align="center" colwidth="1*"/>
+ <thead>
+ <row>
+ <entry><para>NT4 policy Name</para></entry>
+ <entry><para>Samba Policy Name</para></entry>
+ <entry><para>NT4 Range</para></entry>
+ <entry><para>Samba Range</para></entry>
+ <entry><para>Samba Default</para></entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><para>Maximum Password Age</para></entry>
+ <entry><para>maximum password age</para></entry>
+ <entry><para>0 - 999 (days)</para></entry>
+ <entry><para>0 - 4294967295 (sec)</para></entry>
+ <entry><para>4294967295</para></entry>
+ </row>
+ <row>
+ <entry><para>Minimum Password Age</para></entry>
+ <entry><para>minimum password age</para></entry>
+ <entry><para>0 - 999 (days)</para></entry>
+ <entry><para>0 - 4294967295 (sec)</para></entry>
+ <entry><para>0</para></entry>
+ </row>
+ <row>
+ <entry><para>Mimimum Password Length</para></entry>
+ <entry><para>min password length</para></entry>
+ <entry><para>1 - 14 (Chars)</para></entry>
+ <entry><para>0 - 4294967295 (Chars)</para></entry>
+ <entry><para>5</para></entry>
+ </row>
+ <row>
+ <entry><para>Password Uniqueness</para></entry>
+ <entry><para>password history</para></entry>
+ <entry><para>0 - 23 (#)</para></entry>
+ <entry><para>0 - 4294967295 (#)</para></entry>
+ <entry><para>0</para></entry>
+ </row>
+ <row>
+ <entry><para>Account Lockout - Reset count after</para></entry>
+ <entry><para>reset count minutes</para></entry>
+ <entry><para>1 - 99998 (min)</para></entry>
+ <entry><para>0 - 4294967295 (min)</para></entry>
+ <entry><para>30</para></entry>
+ </row>
+ <row>
+ <entry><para>Lockout after bad logon attempts</para></entry>
+ <entry><para>bad lockout attempt</para></entry>
+ <entry><para>0 - 998 (#)</para></entry>
+ <entry><para>0 - 4294967295 (#)</para></entry>
+ <entry><para>0</para></entry>
+ </row>
+ <row>
+ <entry><para>*** Not Known ***</para></entry>
+ <entry><para>disconnect time</para></entry>
+ <entry><para>TBA</para></entry>
+ <entry><para>0 - 4294967295</para></entry>
+ <entry><para>0</para></entry>
+ </row>
+ <row>
+ <entry><para>Lockout Duration</para></entry>
+ <entry><para>lockout duration</para></entry>
+ <entry><para>1 - 99998 (min)</para></entry>
+ <entry><para>0 - 4294967295 (min)</para></entry>
+ <entry><para>30</para></entry>
+ </row>
+ <row>
+ <entry><para>Users must log on in order to change password</para></entry>
+ <entry><para>user must logon to change password</para></entry>
+ <entry><para>0/1</para></entry>
+ <entry><para>0 - 4294967295</para></entry>
+ <entry><para>0</para></entry>
+ </row>
+ <row>
+ <entry><para>*** Registry Setting ***</para></entry>
+ <entry><para>refuse machine password change</para></entry>
+ <entry><para>0/1</para></entry>
+ <entry><para>0 - 4294967295</para></entry>
+ <entry><para>0</para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>policy settings</primary></indexterm>
+<indexterm><primary>account security</primary></indexterm>
+<indexterm><primary>smbpasswd</primary></indexterm>
+ The <command>pdbedit</command> tool is the only one that can manage the account
+ security and policy settings. It is capable of all operations that smbpasswd can
+ do as well as a superset of them.
+ </para>
+
+ <para>
+ <indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>account import/export</primary></indexterm>
+<indexterm><primary>passdb backend</primary></indexterm>
+ One particularly important purpose of the <command>pdbedit</command> is to allow
+ the import/export of account information from one passdb backend to another.
+ </para>
+
+ <sect3>
+ <title>User Account Management</title>
+
+ <para>
+<indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>system accounts</primary></indexterm>
+<indexterm><primary>user account</primary></indexterm>
+<indexterm><primary>domain user manager</primary></indexterm>
+<indexterm><primary>add user script</primary></indexterm>
+<indexterm><primary>interface scripts</primary></indexterm>
+ The <command>pdbedit</command> tool, like the <command>smbpasswd</command> tool, requires
+ that a POSIX user account already exists in the UNIX/Linux system accounts database (backend).
+ Neither tool will call out to the operating system to create a user account because this is
+ considered to be the responsibility of the system administrator. When the Windows NT4 domain
+ user manager is used to add an account, Samba will implement the <literal>add user script</literal>
+ (as well as the other interface scripts) to ensure that user, group and machine accounts are
+ correctly created and changed. The use of the <command>pdbedit</command> tool does not
+ make use of these interface scripts.
+ </para>
+
+ <para>
+<indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>POSIX account</primary></indexterm>
+ Before attempting to use the <command>pdbedit</command> tool to manage user and machine
+ accounts, make certain that a system (POSIX) account has already been created.
+ </para>
+
+ <sect4>
+ <title>Listing User and Machine Accounts</title>
+
+ <para>
+<indexterm><primary>tdbsam</primary></indexterm>
+<indexterm><primary>password backend</primary></indexterm>
+ The following is an example of the user account information that is stored in
+ a tdbsam password backend. This listing was produced by running:
+<screen>
+&prompt;<userinput>pdbedit -Lv met</userinput>
+UNIX username: met
+NT username: met
+Account Flags: [U ]
+User SID: S-1-5-21-1449123459-1407424037-3116680435-2004
+Primary Group SID: S-1-5-21-1449123459-1407424037-3116680435-1201
+Full Name: Melissa E Terpstra
+Home Directory: \\frodo\met\Win9Profile
+HomeDir Drive: H:
+Logon Script: scripts\logon.bat
+Profile Path: \\frodo\Profiles\met
+Domain: &example.workgroup;
+Account desc:
+Workstations: melbelle
+Munged dial:
+Logon time: 0
+Logoff time: Mon, 18 Jan 2038 20:14:07 GMT
+Kickoff time: Mon, 18 Jan 2038 20:14:07 GMT
+Password last set: Sat, 14 Dec 2002 14:37:03 GMT
+Password can change: Sat, 14 Dec 2002 14:37:03 GMT
+Password must change: Mon, 18 Jan 2038 20:14:07 GMT
+</screen>
+ </para>
+
+ <para>
+<indexterm><primary>smbpasswd format</primary></indexterm>
+ Accounts can also be listed in the older <literal>smbpasswd</literal> format:
+<screen>
+&rootprompt;<userinput>pdbedit -Lw</userinput>
+root:0:84B0D8E14D158FF8417EAF50CFAC29C3:
+ AF6DD3FD4E2EA8BDE1695A3F05EFBF52:[U ]:LCT-42681AB8:
+jht:1000:6BBC4159020A52741486235A2333E4D2:
+ CC099521AD554A3C3CF2556274DBCFBC:[U ]:LCT-40D75B5B:
+rcg:1002:E95D4331A6F23AF8AAD3B435B51404EE:
+ BB0F2C39B04CA6100F0E535DF8314B43:[U ]:LCT-40D7C5A3:
+afw:1003:1AAFA7F9F6DC1DEAAAD3B435B51404EE:
+ CE92C2F9471594CDC4E7860CA6BC62DB:[T ]:LCT-40DA501F:
+met:1004:A2848CB7E076B435AAD3B435B51404EE:
+ F25F5D3405085C555236B80B7B22C0D2:[U ]:LCT-4244FAB8:
+aurora$:1005:060DE593EA638B8ACC4A19F14D2FF2BB:
+ 060DE593EA638B8ACC4A19F14D2FF2BB:[W ]:LCT-4173E5CC:
+temptation$:1006:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
+ A96703C014E404E33D4049F706C45EE9:[W ]:LCT-42BF0C57:
+vaioboss$:1001:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
+ 88A30A095160072784C88F811E89F98A:[W ]:LCT-41C3878D:
+frodo$:1008:15891DC6B843ECA41249940C814E316B:
+ B68EADCCD18E17503D3DAD3E6B0B9A75:[W ]:LCT-42B7979F:
+marvel$:1011:BF709959C3C94E0B3958B7B84A3BB6F3:
+ C610EFE9A385A3E8AA46ADFD576E6881:[W ]:LCT-40F07A4
+</screen>
+<indexterm><primary>login id</primary></indexterm>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>LanManger password</primary></indexterm>
+<indexterm><primary>NT password</primary></indexterm>
+<indexterm><primary>Account Flags</primary></indexterm>
+<indexterm><primary>LCT</primary><see>last change time</see></indexterm>
+ The account information that was returned by this command in order from left to right
+ consists of the following colon separated data:
+ </para>
+
+ <itemizedlist>
+ <listitem><para>Login ID.</para></listitem>
+ <listitem><para>UNIX UID.</para></listitem>
+ <listitem>
+ <para>Microsoft LanManager password hash (password converted to upper-case then hashed.</para>
+ </listitem>
+ <listitem><para>Microsoft NT password hash (hash of the case-preserved password).</para></listitem>
+ <listitem><para>Samba SAM Account Flags.</para></listitem>
+ <listitem><para>The LCT data (password last change time).</para></listitem>
+ </itemizedlist>
+
+ <para>
+<indexterm><primary>Account Flags</primary></indexterm>
+<indexterm><primary>pdbedit</primary></indexterm>
+ The Account Flags parameters are documented in the <command>pdbedit</command> man page, and are
+ briefly documented in <link linkend="TOSHARG-acctflags">the Account Flags Management section</link>.
+ </para>
+
+ <para>
+<indexterm><primary>last change time</primary></indexterm>
+ The LCT data consists of 8 hexadecimal characters representing the time since January 1, 1970, of
+ the time when the password was last changed.
+ </para>
+
+ </sect4>
+
+ <sect4>
+ <title>Adding User Accounts</title>
+
+ <para>
+<indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>add a user account</primary></indexterm>
+<indexterm><primary>standalone server</primary></indexterm>
+<indexterm><primary>domain</primary></indexterm>
+<indexterm><primary>SambaSAMAccount</primary></indexterm>
+ The <command>pdbedit</command> can be used to add a user account to a standalone server
+ or to a domain. In the example shown here the account for the user <literal>vlaan</literal>
+ has been created before attempting to add the SambaSAMAccount.
+<screen>
+&rootprompt; pdbedit -a vlaan
+new password: secretpw
+retype new password: secretpw
+Unix username: vlaan
+NT username: vlaan
+Account Flags: [U ]
+User SID: S-1-5-21-726309263-4128913605-1168186429-3014
+Primary Group SID: S-1-5-21-726309263-4128913605-1168186429-513
+Full Name: Victor Laan
+Home Directory: \\frodo\vlaan
+HomeDir Drive: H:
+Logon Script: scripts\logon.bat
+Profile Path: \\frodo\profiles\vlaan
+Domain: &example.workgroup;
+Account desc: Guest User
+Workstations:
+Munged dial:
+Logon time: 0
+Logoff time: Mon, 18 Jan 2038 20:14:07 GMT
+Kickoff time: Mon, 18 Jan 2038 20:14:07 GMT
+Password last set: Wed, 29 Jun 2005 19:35:12 GMT
+Password can change: Wed, 29 Jun 2005 19:35:12 GMT
+Password must change: Mon, 18 Jan 2038 20:14:07 GMT
+Last bad password : 0
+Bad password count : 0
+Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+</screen>
+ </para>
+
+ </sect4>
+
+ <sect4>
+ <title>Deleting Accounts</title>
+
+ <para>
+<indexterm><primary>account deleted</primary></indexterm>
+<indexterm><primary>SambaSAMAccount</primary></indexterm>
+<indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>passdb backend</primary></indexterm>
+ An account can be deleted from the SambaSAMAccount database
+<screen>
+&rootprompt; pdbedit -x vlaan
+</screen>
+ The account is removed without further screen output. The account is removed only from the
+ SambaSAMAccount (passdb backend) database, it is not removed from the UNIX account backend.
+ </para>
+
+ <para>
+<indexterm><primary>delete user script</primary></indexterm>
+<indexterm><primary>pdbedit</primary></indexterm>
+ The use of the NT4 domain user manager to delete an account will trigger the <parameter>delete user
+ script</parameter>, but not the <command>pdbedit</command> tool.
+ </para>
+
+ </sect4>
+
+ <sect4>
+ <title>Changing User Accounts</title>
+
+ <para>
+<indexterm><primary>pdbedit</primary></indexterm>
+ Refer to the <command>pdbedit</command> man page for a full synopsis of all operations
+ that are available with this tool.
+ </para>
+
+ <para>
+<indexterm><primary>pdbedit</primary></indexterm>
+ An example of a simple change in the user account information is the change of the full name
+ information shown here:
+<screen>
+&rootprompt; pdbedit -r --fullname="Victor Aluicious Laan" vlaan
+...
+Primary Group SID: S-1-5-21-726309263-4128913605-1168186429-513
+Full Name: Victor Aluicious Laan
+Home Directory: \\frodo\vlaan
+...
+</screen>
+ </para>
+
+ <para>
+<indexterm><primary>grace time</primary></indexterm>
+<indexterm><primary>password expired</primary></indexterm>
+<indexterm><primary>expired password</primary></indexterm>
+ Let us assume for a moment that a user's password has expired and the user is unable to
+ change the password at this time. It may be necessary to give the user additional grace time
+ so that it is possible to continue to work with the account and the original password. This
+ demonstrates how the password expiration settings may be updated
+<screen>
+&rootprompt; pdbedit -Lv vlaan
+...
+Password last set: Sun, 09 Sep 2001 22:21:40 GMT
+Password can change: Thu, 03 Jan 2002 15:08:35 GMT
+Password must change: Thu, 03 Jan 2002 15:08:35 GMT
+Last bad password : Thu, 03 Jan 2002 15:08:35 GMT
+Bad password count : 2
+...
+</screen>
+<indexterm><primary>bad logon attempts</primary></indexterm>
+<indexterm><primary>lock the account</primary></indexterm>
+ The user has recorded 2 bad logon attempts and the next will lock the account, but the
+ password is also expired. Here is how this account can be reset:
+<screen>
+&rootprompt; pdbedit -z vlaan
+...
+Password last set: Sun, 09 Sep 2001 22:21:40 GMT
+Password can change: Thu, 03 Jan 2002 15:08:35 GMT
+Password must change: Thu, 03 Jan 2002 15:08:35 GMT
+Last bad password : 0
+Bad password count : 0
+...
+</screen>
+ The <literal>Password must change:</literal> parameter can be reset like this:
+<screen>
+&rootprompt; pdbedit --pwd-must-change-time=1200000000 vlaan
+...
+Password last set: Sun, 09 Sep 2001 22:21:40 GMT
+Password can change: Thu, 03 Jan 2002 15:08:35 GMT
+Password must change: Thu, 10 Jan 2008 14:20:00 GMT
+...
+</screen>
+ Another way to use this tools is to set the date like this:
+<screen>
+&rootprompt; pdbedit --pwd-must-change-time="2010-01-01" \
+ --time-format="%Y-%m-%d" vlaan
+...
+Password last set: Sun, 09 Sep 2001 22:21:40 GMT
+Password can change: Thu, 03 Jan 2002 15:08:35 GMT
+Password must change: Fri, 01 Jan 2010 00:00:00 GMT
+...
+</screen>
+<indexterm><primary>strptime</primary></indexterm>
+<indexterm><primary>time format</primary></indexterm>
+ Refer to the strptime man page for specific time format information.
+ </para>
+
+ <para>
+<indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>SambaSAMAccount</primary></indexterm>
+ Please refer to the pdbedit man page for further information relating to SambaSAMAccount
+ management.
+ </para>
+
+ <sect5 id="TOSHARG-acctflags">
+ <title>Account Flags Management</title>
+
+ <para>
+<indexterm><primary>Samba SAM account flags</primary></indexterm>
+<indexterm><primary>account control block</primary><see>ACB</see></indexterm>
+<indexterm><primary>account encode_bits</primary></indexterm>
+<indexterm><primary>account control flags</primary></indexterm>
+ The Samba SAM account flags are properly called the ACB (account control block) within
+ the Samba source code. In some parts of the Samba source code they are referred to as the
+ account encode_bits, and also as the account control flags.
+ </para>
+
+ <para>
+<indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>user account</primary></indexterm>
+<indexterm><primary>machine account</primary></indexterm>
+<indexterm><primary>trust account</primary></indexterm>
+<indexterm><primary>damaged data</primary></indexterm>
+ The manual adjustment of user, machine (workstation or server) or an inter-domain trust
+ account account flgas should not be necessary under normal conditions of use of Samba. On the other hand,
+ where this information becomes corrupted for some reason, the ability to correct the damaged data is certainly
+ useful. The tool of choice by which such correction can be affected is the <command>pdbedit</command> utility.
+ </para>
+
+ <para>
+<indexterm><primary>account flags</primary></indexterm>
+<indexterm><primary>LDAP directory</primary></indexterm>
+ There have been a few requests for information regarding the account flags from developers
+ who are creating their own Samba management tools. An example of a need for information regarding
+ the proper management of the account flags is evident when developing scripts that will be used
+ to manage an LDAP directory.
+ </para>
+
+ <para>
+<indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>account flag order</primary></indexterm>
+ The account flag field can contain up to 16 characters. Presently, only 11 are in use.
+ These are listed in <link linkend="accountflags">Samba SAM Account Control Block Flags</link>.
+ The order in which the flags are specified to the <command>pdbedit</command> command is not important.
+ In fact, they can be set without problem in any order in the SambaAcctFlags record in the LDAP directory.
+ </para>
+
+ <table frame="all" id="accountflags">
+ <title>Samba SAM Account Control Block Flags</title>
+ <tgroup cols="2" align="center">
+ <thead>
+ <row><entry align="center">Flag</entry><entry>Description</entry></row>
+ </thead>
+ <tbody>
+ <row>
+ <entry align="center">D</entry>
+ <entry align="left">Account is disabled.</entry>
+ </row>
+ <row>
+ <entry align="center">H</entry>
+ <entry align="left">A home directory is required.</entry>
+ </row>
+ <row>
+ <entry align="center">I</entry>
+ <entry align="left">An inter-domain trust account.</entry>
+ </row>
+ <row>
+ <entry align="center">L</entry>
+ <entry align="left">Account has been auto-locked.</entry>
+ </row>
+ <row>
+ <entry align="center">M</entry>
+ <entry align="left">An MNS (Microsoft network service) logon account.</entry>
+ </row>
+ <row>
+ <entry align="center">N</entry>
+ <entry align="left">Password not required.</entry>
+ </row>
+ <row>
+ <entry align="center">S</entry>
+ <entry align="left">A server trust account.</entry>
+ </row>
+ <row>
+ <entry align="center">T</entry>
+ <entry align="left">Temporary duplicate account entry.</entry>
+ </row>
+ <row>
+ <entry align="center">U</entry>
+ <entry align="left">A normal user account.</entry>
+ </row>
+ <row>
+ <entry align="center">W</entry>
+ <entry align="left">A workstation trust account.</entry>
+ </row>
+ <row>
+ <entry align="center">X</entry>
+ <entry align="left">Password does not expire.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+<indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>account control flags</primary></indexterm>
+ An example of use of the <command>pdbedit</command> utility to set the account control flags
+ is shown here:
+<screen>
+&rootprompt; pdbedit -r -c "[DLX]" jht
+Unix username: jht
+NT username: jht
+Account Flags: [DHULX ]
+User SID: S-1-5-21-729263-4123605-1186429-3000
+Primary Group SID: S-1-5-21-729263-4123605-1186429-513
+Full Name: John H Terpstra,Utah Office
+Home Directory: \\aurora\jht
+HomeDir Drive: H:
+Logon Script: scripts\logon.bat
+Profile Path: \\aurora\profiles\jht
+Domain: MIDEARTH
+Account desc: BluntObject
+Workstations:
+Logon time: 0
+Logoff time: Mon, 18 Jan 2038 20:14:07 GMT
+Kickoff time: 0
+Password last set: Sun, 03 Jul 2005 23:19:18 GMT
+Password can change: Sun, 03 Jul 2005 23:19:18 GMT
+Password must change: Mon, 18 Jan 2038 20:14:07 GMT
+Last bad password : 0
+Bad password count : 0
+Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+</screen>
+<indexterm><primary>default settings</primary></indexterm>
+ The flags can be reset to the default settings by executing:
+<screen>
+&rootprompt; pdbedit -r -c "[]" jht
+Unix username: jht
+NT username: jht
+Account Flags: [U ]
+User SID: S-1-5-21-729263-4123605-1186429-3000
+Primary Group SID: S-1-5-21-729263-4123605-1186429-513
+Full Name: John H Terpstra,Utah Office
+Home Directory: \\aurora\jht
+HomeDir Drive: H:
+Logon Script: scripts\logon.bat
+Profile Path: \\aurora\profiles\jht
+Domain: MIDEARTH
+Account desc: BluntObject
+Workstations:
+Logon time: 0
+Logoff time: Mon, 18 Jan 2038 20:14:07 GMT
+Kickoff time: 0
+Password last set: Sun, 03 Jul 2005 23:19:18 GMT
+Password can change: Sun, 03 Jul 2005 23:19:18 GMT
+Password must change: Mon, 18 Jan 2038 20:14:07 GMT
+Last bad password : 0
+Bad password count : 0
+Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+</screen>
+ </para>
+
+ </sect5>
+
+ </sect4>
+
+ <sect4>
+ <title>Domain Account Policy Managment</title>
+
+ <para>
+<indexterm><primary>domain account access policies</primary></indexterm>
+<indexterm><primary>access policies</primary></indexterm>
+ To view the domain account access policies that may be configured execute:
+<screen>
+&rootprompt; pdbedit -P ?
+No account policy by that name
+Account policy names are :
+min password length
+password history
+user must logon to change password
+maximum password age
+minimum password age
+lockout duration
+reset count minutes
+bad lockout attempt
+disconnect time
+refuse machine password change
+</screen>
+ </para>
+
+ <para>
+ Commands will be executed to establish controls for our domain as follows:
+ </para>
+
+ <orderedlist>
+ <listitem><para>min password length = 8 characters.</para></listitem>
+ <listitem><para>password history = last 4 passwords.</para></listitem>
+ <listitem><para>maximum password age = 90 days.</para></listitem>
+ <listitem><para>minimum password age = 7 days.</para></listitem>
+ <listitem><para>bad lockout attempt = 8 bad logon attempts.</para></listitem>
+ <listitem><para>lockout duration = forever, account must be manually reenabled.</para></listitem>
+ </orderedlist>
+
+ <para>
+ The following command execution will achieve these settings:
+<screen>
+&rootprompt; pdbedit -P "min password length" -C 8
+account policy value for min password length was 5
+account policy value for min password length is now 8
+&rootprompt; pdbedit -P "password history" -C 4
+account policy value for password history was 0
+account policy value for password history is now 4
+&rootprompt; pdbedit -P "maximum password age" -C 7776000
+account policy value for maximum password age was 4294967295
+account policy value for maximum password age is now 7776000
+&rootprompt; pdbedit -P "minimum password age" -C 7
+account policy value for minimum password age was 0
+account policy value for minimum password age is now 7
+&rootprompt; pdbedit -P "bad lockout attempt" -C 8
+account policy value for bad lockout attempt was 0
+account policy value for bad lockout attempt is now 8
+&rootprompt; pdbedit -P "lockout duration" -C -1
+account policy value for lockout duration was 30
+account policy value for lockout duration is now 4294967295
+</screen>
+ </para>
+
+<note><para>
+To set the maximum (infinite) lockout time use the value of -1.
+</para></note>
+
+<warning><para>
+Account policies must be set individually on each PDC and BDC. At this time (Samba 3.0.11 to Samba 3.0.14a)
+account policies are not replicated automatically. This may be fixed before Samba 3.0.20 ships or some
+time there after. Please check the WHATSNEW.txt file in the Samba-3 tarball for specific update notiations
+regarding this facility.
+</para></warning>
+
+ </sect4>
+
+ </sect3>
+
+ <sect3>
+ <title>Account Import/Export</title>
+
+ <para>
+ <indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>account import/export</primary></indexterm>
+<indexterm><primary>authentication</primary></indexterm>
+ The <command>pdbedit</command> tool allows import/export of authentication (account)
+ databases from one backend to another. For example, to import/export accounts from an
+ old <filename>smbpasswd</filename> database to a <parameter>tdbsam</parameter>
+ backend:
+ </para>
+
+ <procedure>
+ <step><para>
+<indexterm><primary>pdbedit</primary></indexterm>
+<screen>
+&rootprompt;<userinput>pdbedit -i smbpasswd -e tdbsam</userinput>
+</screen>
+ </para></step>
+
+ <step><para>
+<indexterm><primary>smbpasswd</primary></indexterm>
+ Replace the <parameter>smbpasswd</parameter> with <parameter>tdbsam</parameter> in the
+ <parameter>passdb backend</parameter> configuration in &smb.conf;.
+ </para></step>
+ </procedure>
+
+ </sect3>
+ </sect2>
+</sect1>
+
+<sect1>
+<title>Password Backends</title>
+
+<para>
+<indexterm><primary>account database</primary></indexterm>
+<indexterm><primary>SMB/CIFS server</primary></indexterm>
+Samba offers flexibility in backend account database design. The flexibility is immediately obvious as one
+begins to explore this capability. Recent changes to Samba (since 3.0.23) have removed the mulitple backend
+feature in order to simplify problems that broke some installations. This removal has made the internal
+operation of Samba-3 more consistent and predictable.
+</para>
+
+<para>
+<indexterm><primary>multiple backends</primary></indexterm>
+<indexterm><primary>tdbsam databases</primary></indexterm>
+Beginning with Samba 3.0.23 it is no longer possible to specify use of mulitple passdb backends. Earlier
+versions of Samba-3 made it possible to specify multiple password backends, and even multiple
+backends of the same type. The multiple passdb backend capability caused many problems with name to SID and
+SID to name ID resolution. The Samba team wrestled with the challenges and decided that this feature needed
+to be removed.
+</para>
+
+ <sect2>
+ <title>Plaintext</title>
+
+ <para>
+<indexterm><primary>user database</primary></indexterm>
+<indexterm><primary>/etc/samba/smbpasswd</primary></indexterm>
+<indexterm><primary>/etc/smbpasswd</primary></indexterm>
+<indexterm><primary>password encryption</primary></indexterm>
+<indexterm><primary>/etc/passwd</primary></indexterm>
+<indexterm><primary>PAM</primary></indexterm>
+ Older versions of Samba retrieved user information from the UNIX user database
+ and eventually some other fields from the file <filename>/etc/samba/smbpasswd</filename>
+ or <filename>/etc/smbpasswd</filename>. When password encryption is disabled, no
+ SMB-specific data is stored at all. Instead, all operations are conducted via the way
+ that the Samba host OS will access its <filename>/etc/passwd</filename> database.
+ On most Linux systems, for example, all user and group resolution is done via PAM.
+ </para>
+
+ </sect2>
+
+ <sect2>
+ <title>smbpasswd: Encrypted Password Database</title>
+
+ <para>
+ <indexterm><primary>SAM backend</primary><secondary>smbpasswd</secondary></indexterm>
+<indexterm><primary>user account</primary></indexterm>
+<indexterm><primary>LM/NT password hashes</primary></indexterm>
+<indexterm><primary>smbpasswd</primary></indexterm>
+ Traditionally, when configuring <smbconfoption name="encrypt passwords">yes</smbconfoption>
+ in Samba's &smb.conf; file, user account information such as username, LM/NT password hashes,
+ password change times, and account flags have been stored in the <filename>smbpasswd(5)</filename>
+ file. There are several disadvantages to this approach for sites with large numbers of users
+ (counted in the thousands).
+ </para>
+
+ <itemizedlist>
+ <listitem><para>
+<indexterm><primary>lookups</primary></indexterm>
+ The first problem is that all lookups must be performed sequentially. Given that
+ there are approximately two lookups per domain logon (one during intial logon validation
+ and one for a session connection setup, such as when mapping a network drive or printer), this
+ is a performance bottleneck for large sites. What is needed is an indexed approach
+ such as that used in databases.
+ </para></listitem>
+
+ <listitem><para>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>replicate</primary></indexterm>
+<indexterm><primary>rsync</primary></indexterm>
+<indexterm><primary>ssh</primary></indexterm>
+<indexterm><primary>custom scripts</primary></indexterm>
+ The second problem is that administrators who desire to replicate an smbpasswd file
+ to more than one Samba server are left to use external tools such as
+ <command>rsync(1)</command> and <command>ssh(1)</command> and write custom,
+ in-house scripts.
+ </para></listitem>
+
+ <listitem><para>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>home directory</primary></indexterm>
+<indexterm><primary>password expiration</primary></indexterm>
+<indexterm><primary>relative identifier</primary></indexterm>
+<indexterm><primary>relative identifier</primary><see>RID</see></indexterm>
+ Finally, the amount of information that is stored in an smbpasswd entry leaves
+ no room for additional attributes such as a home directory, password expiration time,
+ or even a relative identifier (RID).
+ </para></listitem>
+ </itemizedlist>
+
+ <para>
+<indexterm><primary>user attributes</primary></indexterm>
+<indexterm><primary>smbd</primary></indexterm>
+<indexterm><primary>API</primary></indexterm>
+<indexterm><primary>samdb interface</primary></indexterm>
+ As a result of these deficiencies, a more robust means of storing user attributes
+ used by smbd was developed. The API that defines access to user accounts
+ is commonly referred to as the samdb interface (previously, this was called the passdb
+ API and is still so named in the Samba source code trees).
+ </para>
+
+ <para>
+<indexterm><primary>passdb backends</primary></indexterm>
+<indexterm><primary>smbpasswd plaintext database</primary></indexterm>
+<indexterm><primary>tdbsam</primary></indexterm>
+<indexterm><primary>ldapsam</primary></indexterm>
+<indexterm><primary>enterprise</primary></indexterm>
+ Samba provides an enhanced set of passdb backends that overcome the deficiencies
+ of the smbpasswd plaintext database. These are tdbsam and ldapsam.
+ Of these, ldapsam will be of most interest to large corporate or enterprise sites.
+ </para>
+
+ </sect2>
+
+ <sect2>
+ <title>tdbsam</title>
+
+ <para>
+ <indexterm><primary>SAM backend</primary><secondary>tdbsam</secondary></indexterm>
+<indexterm><primary>trivial database</primary><see>TDB</see></indexterm>
+<indexterm><primary>machine account</primary></indexterm>
+ Samba can store user and machine account data in a <quote>TDB</quote> (trivial database).
+ Using this backend does not require any additional configuration. This backend is
+ recommended for new installations that do not require LDAP.
+ </para>
+
+ <para>
+<indexterm><primary>tdbsam</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>scalability</primary></indexterm>
+ As a general guide, the Samba Team does not recommend using the tdbsam backend for sites
+ that have 250 or more users. Additionally, tdbsam is not capable of scaling for use
+ in sites that require PDB/BDC implementations that require replication of the account
+ database. Clearly, for reason of scalability, the use of ldapsam should be encouraged.
+ </para>
+
+ <para>
+<indexterm><primary>250-user limit</primary></indexterm>
+<indexterm><primary>performance-based</primary></indexterm>
+<indexterm><primary>tdbsam</primary></indexterm>
+ The recommendation of a 250-user limit is purely based on the notion that this
+ would generally involve a site that has routed networks, possibly spread across
+ more than one physical location. The Samba Team has not at this time established
+ the performance-based scalability limits of the tdbsam architecture.
+ </para>
+
+ <para>
+<indexterm><primary>4,500 user accounts</primary></indexterm>
+<indexterm><primary>passdb backend</primary></indexterm>
+<indexterm><primary>tdbsam</primary></indexterm>
+<indexterm><primary>SambaSAMAccount</primary></indexterm>
+ There are sites that have thousands of users and yet require only one server.
+ One site recently reported having 4,500 user accounts on one UNIX system and
+ reported excellent performance with the <literal>tdbsam</literal> passdb backend.
+ The limitation of where the <literal>tdbsam</literal> passdb backend can be used
+ is not one pertaining to a limitation in the TDB storage system, it is based
+ only on the need for a reliable distribution mechanism for the SambaSAMAccount
+ backend.
+ </para>
+
+ </sect2>
+
+ <sect2>
+ <title>ldapsam</title>
+
+ <para>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>ldapsam</primary></indexterm>
+ <indexterm><primary>SAM backend</primary><secondary>ldapsam</secondary></indexterm>
+ There are a few points to stress that the ldapsam does not provide. The LDAP
+ support referred to in this documentation does not include:
+ </para>
+
+ <itemizedlist>
+ <listitem><para>A means of retrieving user account information from
+ a Windows 200x Active Directory server.</para></listitem>
+ <listitem><para>A means of replacing /etc/passwd.</para></listitem>
+ </itemizedlist>
+
+ <para>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>NSS</primary></indexterm>
+<indexterm><primary>PAM</primary></indexterm>
+<indexterm><primary>LGPL</primary></indexterm>
+ The second item can be accomplished by using LDAP NSS and PAM modules. LGPL versions of these libraries can be
+ obtained from <ulink url="http://www.padl.com/">PADL Software</ulink>. More information about the
+ configuration of these packages may be found in <ulink url="http://safari.oreilly.com/?XmlId=1-56592-491-6">
+ <emphasis>LDAP, System Administration</emphasis> by Gerald Carter, Chapter 6, Replacing NIS"</ulink>.
+ </para>
+
+ <para>
+<indexterm><primary>LDAP directory</primary></indexterm>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>directory server</primary></indexterm>
+ This document describes how to use an LDAP directory for storing Samba user
+ account information traditionally stored in the smbpasswd(5) file. It is
+ assumed that the reader already has a basic understanding of LDAP concepts
+ and has a working directory server already installed. For more information
+ on LDAP architectures and directories, please refer to the following sites:
+ </para>
+
+ <itemizedlist>
+ <listitem><para><ulink url="http://www.openldap.org/">OpenLDAP</ulink></para></listitem>
+ <listitem><para><ulink url="http://www.sun.com/software/products/directory_srvr_ee/index.xml">
+ Sun One Directory Server</ulink></para></listitem>
+ <listitem><para><ulink url="http://www.novell.com/products/edirectory/">Novell eDirectory</ulink></para></listitem>
+ <listitem><para><ulink url="http://www-306.ibm.com/software/tivoli/products/directory-server/">IBM
+ Tivoli Directory Server</ulink></para></listitem>
+ <listitem><para><ulink url="http://www.redhat.com/software/rha/directory/">Red Hat Directory
+ Server</ulink></para></listitem>
+ <listitem><para><ulink url="http://www.linuxsecurity.com/content/view/119229">Fedora Directory
+ Server</ulink></para></listitem>
+ </itemizedlist>
+
+ <para>
+ Two additional Samba resources that may prove to be helpful are:
+ </para>
+
+ <itemizedlist>
+ <listitem><para>
+<indexterm><primary>Samba-PDC-LDAP-HOWTO</primary></indexterm>
+ The <ulink url="http://www.unav.es/cti/ldap-smb/ldap-smb-3-howto.html">Samba-PDC-LDAP-HOWTO</ulink>
+ maintained by Ignacio Coupeau.
+ </para></listitem>
+
+ <listitem><para>
+<indexterm><primary>IDEALX</primary></indexterm>
+<indexterm><primary>NT migration scripts</primary></indexterm>
+<indexterm><primary>smbldap-tools</primary></indexterm>
+ The NT migration scripts from <ulink url="http://samba.idealx.org/">IDEALX</ulink> that are
+ geared to manage users and groups in such a Samba-LDAP domain controller configuration.
+ Idealx also produced the smbldap-tools and the Interactive Console Management tool.
+ </para></listitem>
+ </itemizedlist>
+
+ <sect3>
+ <title>Supported LDAP Servers</title>
+
+ <para>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>ldapsam</primary></indexterm>
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>Netscape's Directory Server</primary></indexterm>
+ The LDAP ldapsam code was developed and tested using the OpenLDAP 2.x server and
+ client libraries. The same code should work with Netscape's Directory Server and client SDK.
+ However, there are bound to be compile errors and bugs. These should not be hard to fix.
+ Please submit fixes via the process outlined in <link linkend="bugreport">Reporting Bugs</link>.
+ </para>
+
+ <para>
+ Samba is capable of working with any standards-compliant LDAP server.
+ </para>
+
+ </sect3>
+
+ <sect3>
+ <title>Schema and Relationship to the RFC 2307 posixAccount</title>
+
+
+ <para>
+ Samba-3.0 includes the necessary schema file for OpenLDAP 2.x in the
+ <filename>examples/LDAP/samba.schema</filename> directory of the source code distribution
+ tarball. The schema entry for the sambaSamAccount ObjectClass is shown here:
+<programlisting>
+ObjectClass (1.3.6.1.4.1.7165.2.2.6 NAME 'sambaSamAccount' SUP top AUXILIARY
+ DESC 'Samba-3.0 Auxiliary SAM Account'
+ MUST ( uid $ sambaSID )
+ MAY ( cn $ sambaLMPassword $ sambaNTPassword $ sambaPwdLastSet $
+ sambaLogonTime $ sambaLogoffTime $ sambaKickoffTime $
+ sambaPwdCanChange $ sambaPwdMustChange $ sambaAcctFlags $
+ displayName $ sambaHomePath $ sambaHomeDrive $ sambaLogonScript $
+ sambaProfilePath $ description $ sambaUserWorkstations $
+ sambaPrimaryGroupSID $ sambaDomainName ))
+</programlisting>
+ </para>
+
+ <para>
+<indexterm><primary>samba.schema</primary></indexterm>
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>OID</primary></indexterm>
+ The <filename>samba.schema</filename> file has been formatted for OpenLDAP 2.0/2.1.
+ The Samba Team owns the OID space used by the above schema and recommends its use.
+ If you translate the schema to be used with Netscape DS, please submit the modified
+ schema file as a patch to <ulink url="mailto:jerry@samba.org">jerry@samba.org</ulink>.
+ </para>
+
+ <para>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>/etc/passwd</primary></indexterm>
+<indexterm><primary>sambaSamAccount</primary></indexterm>
+<indexterm><primary>AUXILIARY</primary></indexterm>
+<indexterm><primary>ObjectClass</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>RFC 2307.</primary></indexterm>
+ Just as the smbpasswd file is meant to store information that provides information
+ additional to a user's <filename>/etc/passwd</filename> entry, so is the sambaSamAccount
+ object meant to supplement the UNIX user account information. A sambaSamAccount is an
+ <constant>AUXILIARY</constant> ObjectClass, so it can be used to augment existing
+ user account information in the LDAP directory, thus providing information needed
+ for Samba account handling. However, there are several fields (e.g., uid) that overlap
+ with the posixAccount ObjectClass outlined in RFC 2307. This is by design.
+ </para>
+
+ <para>
+<indexterm><primary>account information</primary></indexterm>
+<indexterm><primary>sambaSamAccount</primary></indexterm>
+<indexterm><primary>posixAccount</primary></indexterm>
+<indexterm><primary>ObjectClasses</primary></indexterm>
+<indexterm><primary>smbd</primary></indexterm>
+<indexterm><primary>getpwnam</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>NIS</primary></indexterm>
+<indexterm><primary>NSS</primary></indexterm>
+ In order to store all user account information (UNIX and Samba) in the directory,
+ it is necessary to use the sambaSamAccount and posixAccount ObjectClasses in
+ combination. However, <command>smbd</command> will still obtain the user's UNIX account
+ information via the standard C library calls, such as getpwnam().
+ This means that the Samba server must also have the LDAP NSS library installed
+ and functioning correctly. This division of information makes it possible to
+ store all Samba account information in LDAP, but still maintain UNIX account
+ information in NIS while the network is transitioning to a full LDAP infrastructure.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>OpenLDAP Configuration</title>
+
+ <para>
+<indexterm><primary>sambaSamAccount</primary></indexterm>
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>slapd</primary></indexterm>
+<indexterm><primary>samba.schema</primary></indexterm>
+ To include support for the sambaSamAccount object in an OpenLDAP directory
+ server, first copy the samba.schema file to slapd's configuration directory.
+ The samba.schema file can be found in the directory <filename>examples/LDAP</filename>
+ in the Samba source distribution.
+<screen>
+&rootprompt;<userinput>cp samba.schema /etc/openldap/schema/</userinput>
+</screen>
+ </para>
+
+ <para>
+<indexterm><primary>samba.schema</primary></indexterm>
+<indexterm><primary>slapd.conf</primary></indexterm>
+<indexterm><primary>sambaSamAccount</primary></indexterm>
+<indexterm><primary>cosine.schema</primary></indexterm>
+<indexterm><primary>uid</primary></indexterm>
+<indexterm><primary>inetorgperson.schema</primary></indexterm>
+<indexterm><primary>displayName</primary></indexterm>
+<indexterm><primary>attribute</primary></indexterm>
+ Next, include the <filename>samba.schema</filename> file in <filename>slapd.conf</filename>.
+ The sambaSamAccount object contains two attributes that depend on other schema
+ files. The <parameter>uid</parameter> attribute is defined in <filename>cosine.schema</filename> and
+ the <parameter>displayName</parameter> attribute is defined in the <filename>inetorgperson.schema</filename>
+ file. Both of these must be included before the <filename>samba.schema</filename> file.
+<programlisting>
+## /etc/openldap/slapd.conf
+
+## schema files (core.schema is required by default)
+include /etc/openldap/schema/core.schema
+
+## needed for sambaSamAccount
+include /etc/openldap/schema/cosine.schema
+include /etc/openldap/schema/inetorgperson.schema
+include /etc/openldap/schema/nis.schema
+include /etc/openldap/schema/samba.schema
+....
+</programlisting>
+ </para>
+
+ <para>
+<indexterm><primary>sambaSamAccount</primary></indexterm>
+<indexterm><primary>posixAccount</primary></indexterm>
+<indexterm><primary>posixGroup</primary></indexterm>
+<indexterm><primary>ObjectClasses</primary></indexterm>
+ It is recommended that you maintain some indices on some of the most useful attributes,
+ as in the following example, to speed up searches made on sambaSamAccount ObjectClasses
+ (and possibly posixAccount and posixGroup as well):
+ </para>
+
+<para>
+<programlisting>
+# Indices to maintain
+## required by OpenLDAP
+index objectclass eq
+
+index cn pres,sub,eq
+index sn pres,sub,eq
+## required to support pdb_getsampwnam
+index uid pres,sub,eq
+## required to support pdb_getsambapwrid()
+index displayName pres,sub,eq
+
+## uncomment these if you are storing posixAccount and
+## posixGroup entries in the directory as well
+##index uidNumber eq
+##index gidNumber eq
+##index memberUid eq
+
+index sambaSID eq
+index sambaPrimaryGroupSID eq
+index sambaDomainName eq
+index default sub
+</programlisting>
+</para>
+
+ <para>
+ Create the new index by executing:
+<screen>
+&rootprompt;./sbin/slapindex -f slapd.conf
+</screen>
+ </para>
+
+ <para>
+ Remember to restart slapd after making these changes:
+<screen>
+&rootprompt;<userinput>/etc/init.d/slapd restart</userinput>
+</screen>
+ </para>
+
+ </sect3>
+
+ <sect3>
+ <title>Initialize the LDAP Database</title>
+
+ <para>
+<indexterm><primary>LDAP database</primary></indexterm>
+<indexterm><primary>account containers</primary></indexterm>
+<indexterm><primary>LDIF file</primary></indexterm>
+<indexterm><primary>DNS</primary></indexterm>
+ Before you can add accounts to the LDAP database, you must create the account containers
+ that they will be stored in. The following LDIF file should be modified to match your
+ needs (DNS entries, and so on):
+<programlisting>
+# Organization for Samba Base
+dn: dc=quenya,dc=org
+objectclass: dcObject
+objectclass: organization
+dc: quenya
+o: Quenya Org Network
+description: The Samba-3 Network LDAP Example
+
+# Organizational Role for Directory Management
+dn: cn=Manager,dc=quenya,dc=org
+objectclass: organizationalRole
+cn: Manager
+description: Directory Manager
+
+# Setting up container for Users OU
+dn: ou=People,dc=quenya,dc=org
+objectclass: top
+objectclass: organizationalUnit
+ou: People
+
+# Setting up admin handle for People OU
+dn: cn=admin,ou=People,dc=quenya,dc=org
+cn: admin
+objectclass: top
+objectclass: organizationalRole
+objectclass: simpleSecurityObject
+userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz
+
+# Setting up container for groups
+dn: ou=Groups,dc=quenya,dc=org
+objectclass: top
+objectclass: organizationalUnit
+ou: Groups
+
+# Setting up admin handle for Groups OU
+dn: cn=admin,ou=Groups,dc=quenya,dc=org
+cn: admin
+objectclass: top
+objectclass: organizationalRole
+objectclass: simpleSecurityObject
+userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz
+
+# Setting up container for computers
+dn: ou=Computers,dc=quenya,dc=org
+objectclass: top
+objectclass: organizationalUnit
+ou: Computers
+
+# Setting up admin handle for Computers OU
+dn: cn=admin,ou=Computers,dc=quenya,dc=org
+cn: admin
+objectclass: top
+objectclass: organizationalRole
+objectclass: simpleSecurityObject
+userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz
+</programlisting>
+ </para>
+
+ <para>
+<indexterm><primary>userPassword</primary></indexterm>
+<indexterm><primary>slappasswd</primary></indexterm>
+ The userPassword shown above should be generated using <command>slappasswd</command>.
+ </para>
+
+ <para>
+<indexterm><primary>LDIF</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+ The following command will then load the contents of the LDIF file into the LDAP
+ database.
+<indexterm><primary>slapadd</primary></indexterm>
+<screen>
+&prompt;<userinput>slapadd -v -l initldap.dif</userinput>
+</screen>
+ </para>
+
+ <para>
+ Do not forget to secure your LDAP server with an adequate access control list
+ as well as an admin password.
+ </para>
+
+ <note><para>
+<indexterm><primary>secrets.tdb</primary></indexterm>
+ Before Samba can access the LDAP server, you need to store the LDAP admin password
+ in the Samba-3 <filename>secrets.tdb</filename> database by:
+<indexterm><primary>smbpasswd</primary></indexterm>
+<screen>
+&rootprompt;<userinput>smbpasswd -w <replaceable>secret</replaceable></userinput>
+</screen>
+ </para></note>
+
+ </sect3>
+
+ <sect3>
+ <title>Configuring Samba</title>
+
+ <para>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>smbd</primary></indexterm>
+ The following parameters are available in &smb.conf; only if your version of Samba was built with
+ LDAP support. Samba automatically builds with LDAP support if the LDAP libraries are found. The
+ best method to verify that Samba was built with LDAP support is:
+<screen>
+&rootprompt; smbd -b | grep LDAP
+ HAVE_LDAP_H
+ HAVE_LDAP
+ HAVE_LDAP_DOMAIN2HOSTLIST
+ HAVE_LDAP_INIT
+ HAVE_LDAP_INITIALIZE
+ HAVE_LDAP_SET_REBIND_PROC
+ HAVE_LIBLDAP
+ LDAP_SET_REBIND_PROC_ARGS
+</screen>
+ If the build of the <command>smbd</command> command you are using does not produce output
+ that includes <literal>HAVE_LDAP_H</literal> it is necessary to discover why the LDAP headers
+ and libraries were not found during compilation.
+ </para>
+
+ <para>LDAP-related smb.conf options include these:
+ <smbconfblock>
+ <smbconfoption name="passdb backend">ldapsam:url</smbconfoption>
+ <smbconfoption name="ldap admin dn"/>
+ <smbconfoption name="ldap delete dn"/>
+ <smbconfoption name="ldap filter"/>
+ <smbconfoption name="ldap group suffix"/>
+ <smbconfoption name="ldap idmap suffix"/>
+ <smbconfoption name="ldap machine suffix"/>
+ <smbconfoption name="ldap passwd sync"/>
+ <smbconfoption name="ldap ssl"/>
+ <smbconfoption name="ldap suffix"/>
+ <smbconfoption name="ldap user suffix"/>
+ <smbconfoption name="ldap replication sleep"/>
+ <smbconfoption name="ldap timeout"/>
+ <smbconfoption name="ldap page size"/>
+ </smbconfblock>
+ </para>
+
+ <para>
+ These are described in the &smb.conf; man page and so are not repeated here. However, an example
+ for use with an LDAP directory is shown in <link linkend="confldapex">the Configuration with LDAP.</link>
+ </para>
+
+<example id="confldapex">
+<title>Configuration with LDAP</title>
+<smbconfblock>
+<smbconfsection name="[global]"/>
+<smbconfoption name="security">user</smbconfoption>
+<smbconfoption name="encrypt passwords">yes</smbconfoption>
+<smbconfoption name="netbios name">MORIA</smbconfoption>
+<smbconfoption name="workgroup">NOLDOR</smbconfoption>
+
+<smbconfcomment>LDAP related parameters:</smbconfcomment>
+
+<smbconfcomment>Define the DN used when binding to the LDAP servers.</smbconfcomment>
+<smbconfcomment>The password for this DN is not stored in smb.conf</smbconfcomment>
+<smbconfcomment>Set it using 'smbpasswd -w secret' to store the</smbconfcomment>
+<smbconfcomment>passphrase in the secrets.tdb file.</smbconfcomment>
+<smbconfcomment>If the "ldap admin dn" value changes, it must be reset.</smbconfcomment>
+<smbconfoption name="ldap admin dn">"cn=Manager,dc=quenya,dc=org"</smbconfoption>
+
+<smbconfcomment>SSL directory connections can be configured by:</smbconfcomment>
+<smbconfcomment>('off', 'start tls', or 'on' (default))</smbconfcomment>
+<smbconfoption name="ldap ssl">start tls</smbconfoption>
+
+<smbconfcomment>syntax: passdb backend = ldapsam:ldap://server-name[:port]</smbconfcomment>
+<smbconfoption name="passdb backend">ldapsam:ldap://frodo.quenya.org</smbconfoption>
+
+<smbconfcomment>smbpasswd -x delete the entire dn-entry</smbconfcomment>
+<smbconfoption name="ldap delete dn">no</smbconfoption>
+
+<smbconfcomment>The machine and user suffix are added to the base suffix</smbconfcomment>
+<smbconfcomment>wrote WITHOUT quotes. NULL suffixes by default</smbconfcomment>
+<smbconfoption name="ldap user suffix">ou=People</smbconfoption>
+<smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
+<smbconfoption name="ldap machine suffix">ou=Computers</smbconfoption>
+
+<smbconfcomment>Trust UNIX account information in LDAP</smbconfcomment>
+<smbconfcomment> (see the smb.conf man page for details)</smbconfcomment>
+
+<smbconfcomment>Specify the base DN to use when searching the directory</smbconfcomment>
+<smbconfoption name="ldap suffix">dc=quenya,dc=org</smbconfoption>
+</smbconfblock>
+</example>
+
+ </sect3>
+
+ <sect3>
+ <title>Accounts and Groups Management</title>
+
+ <para>
+ <indexterm><primary>User Management</primary></indexterm>
+ <indexterm><primary>User Accounts</primary><secondary>Adding/Deleting</secondary></indexterm>
+ Because user accounts are managed through the sambaSamAccount ObjectClass, you should
+ modify your existing administration tools to deal with sambaSamAccount attributes.
+ </para>
+
+ <para>
+<indexterm><primary>sambaSamAccount</primary></indexterm>
+<indexterm><primary>/etc/openldap/sldap.conf</primary></indexterm>
+<indexterm><primary>NSS</primary></indexterm>
+ Machine accounts are managed with the sambaSamAccount ObjectClass, just
+ like user accounts. However, it is up to you to store those accounts
+ in a different tree of your LDAP namespace. You should use
+ <quote>ou=Groups,dc=quenya,dc=org</quote> to store groups and
+ <quote>ou=People,dc=quenya,dc=org</quote> to store users. Just configure your
+ NSS and PAM accordingly (usually, in the <filename>/etc/openldap/sldap.conf</filename>
+ configuration file).
+ </para>
+
+ <para>
+<indexterm><primary>POSIX</primary></indexterm>
+<indexterm><primary>posixGroup</primary></indexterm>
+<indexterm><primary>Domain Groups</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+ In Samba-3, the group management system is based on POSIX
+ groups. This means that Samba makes use of the posixGroup ObjectClass.
+ For now, there is no NT-like group system management (global and local
+ groups). Samba-3 knows only about <constant>Domain Groups</constant>
+ and, unlike MS Windows 2000 and Active Directory, Samba-3 does not
+ support nested groups.
+ </para>
+
+ </sect3>
+
+ <sect3>
+ <title>Security and sambaSamAccount</title>
+
+
+ <para>
+<indexterm><primary>sambaSAMAccount</primary></indexterm>
+ There are two important points to remember when discussing the security
+ of sambaSAMAccount entries in the directory.
+ </para>
+
+ <itemizedlist>
+ <listitem><para><emphasis>Never</emphasis> retrieve the SambaLMPassword or
+<indexterm><primary>SambaNTPassword</primary></indexterm>
+ SambaNTPassword attribute values over an unencrypted LDAP session.</para></listitem>
+ <listitem><para><emphasis>Never</emphasis> allow non-admin users to
+ view the SambaLMPassword or SambaNTPassword attribute values.</para></listitem>
+ </itemizedlist>
+
+ <para>
+<indexterm><primary>clear-text</primary></indexterm>
+<indexterm><primary>impersonate</primary></indexterm>
+<indexterm><primary>LM/NT password hashes</primary></indexterm>
+ These password hashes are clear-text equivalents and can be used to impersonate
+ the user without deriving the original clear-text strings. For more information
+ on the details of LM/NT password hashes, refer to <link linkend="passdb">the
+ Account Information Database section</link>.
+ </para>
+
+ <para>
+<indexterm><primary>encrypted session</primary></indexterm>
+<indexterm><primary>StartTLS</primary></indexterm>
+<indexterm><primary>LDAPS</primary></indexterm>
+<indexterm><primary>secure communications</primary></indexterm>
+ To remedy the first security issue, the <smbconfoption name="ldap ssl"/> &smb.conf;
+ parameter defaults to require an encrypted session (<smbconfoption name="ldap
+ ssl">on</smbconfoption>) using the default port of <constant>636</constant> when
+ contacting the directory server. When using an OpenLDAP server, it
+ is possible to use the StartTLS LDAP extended operation in the place of LDAPS.
+ In either case, you are strongly encouraged to use secure communications protocols
+ (so do not set <smbconfoption name="ldap ssl">off</smbconfoption>).
+ </para>
+
+ <para>
+<indexterm><primary>LDAPS</primary></indexterm>
+<indexterm><primary>StartTLS</primary></indexterm>
+<indexterm><primary>LDAPv3</primary></indexterm>
+ Note that the LDAPS protocol is deprecated in favor of the LDAPv3 StartTLS
+ extended operation. However, the OpenLDAP library still provides support for
+ the older method of securing communication between clients and servers.
+ </para>
+
+ <para>
+<indexterm><primary>harvesting password hashes</primary></indexterm>
+<indexterm><primary>ACL</primary></indexterm>
+<indexterm><primary>slapd.conf</primary></indexterm>
+ The second security precaution is to prevent non-administrative users from
+ harvesting password hashes from the directory. This can be done using the
+ following ACL in <filename>slapd.conf</filename>:
+ </para>
+
+<para>
+<programlisting>
+## allow the "ldap admin dn" access, but deny everyone else
+access to attrs=SambaLMPassword,SambaNTPassword
+ by dn="cn=Samba Admin,ou=People,dc=quenya,dc=org" write
+ by * none
+</programlisting>
+</para>
+
+ </sect3>
+
+ <sect3>
+ <title>LDAP Special Attributes for sambaSamAccounts</title>
+
+ <para> The sambaSamAccount ObjectClass is composed of the attributes shown in next tables: <link
+ linkend="attribobjclPartA">Part A</link>, and <link linkend="attribobjclPartB">Part B</link>.
+ </para>
+
+ <table frame="all" id="attribobjclPartA">
+ <title>Attributes in the sambaSamAccount ObjectClass (LDAP), Part A</title>
+ <tgroup cols="2" align="justify">
+ <colspec align="left"/>
+ <colspec align="justify" colwidth="1*"/>
+ <tbody>
+ <row><entry><constant>sambaLMPassword</constant></entry><entry>The LanMan password 16-byte hash stored as a character
+ representation of a hexadecimal string.</entry></row>
+ <row><entry><constant>sambaNTPassword</constant></entry><entry>The NT password 16-byte hash stored as a character
+ representation of a hexadecimal string.</entry></row>
+ <row><entry><constant>sambaPwdLastSet</constant></entry><entry>The integer time in seconds since 1970 when the
+ <constant>sambaLMPassword</constant> and <constant>sambaNTPassword</constant> attributes were last set.
+ </entry></row>
+
+ <row><entry><constant>sambaAcctFlags</constant></entry><entry>String of 11 characters surrounded by square brackets [ ]
+ representing account flags such as U (user), W (workstation), X (no password expiration),
+ I (domain trust account), H (home dir required), S (server trust account),
+ and D (disabled).</entry></row>
+
+ <row><entry><constant>sambaLogonTime</constant></entry><entry>Integer value currently unused.</entry></row>
+
+ <row><entry><constant>sambaLogoffTime</constant></entry><entry>Integer value currently unused.</entry></row>
+
+ <row><entry><constant>sambaKickoffTime</constant></entry><entry>Specifies the time (UNIX time format) when the user
+ will be locked down and cannot login any longer. If this attribute is omitted, then the account will never expire.
+ Using this attribute together with shadowExpire of the shadowAccount ObjectClass will enable accounts to
+ expire completely on an exact date.</entry></row>
+
+ <row><entry><constant>sambaPwdCanChange</constant></entry><entry>Specifies the time (UNIX time format)
+ after which the user is allowed to change his password. If this attribute is not set, the user will be free
+ to change his password whenever he wants.</entry></row>
+
+ <row><entry><constant>sambaPwdMustChange</constant></entry><entry>Specifies the time (UNIX time format) when the user is
+ forced to change his password. If this value is set to 0, the user will have to change his password at first login.
+ If this attribute is not set, then the password will never expire.</entry></row>
+
+ <row><entry><constant>sambaHomeDrive</constant></entry><entry>Specifies the drive letter to which to map the
+ UNC path specified by sambaHomePath. The drive letter must be specified in the form <quote>X:</quote>
+ where X is the letter of the drive to map. Refer to the <quote>logon drive</quote> parameter in the
+ smb.conf(5) man page for more information.</entry></row>
+
+ <row><entry><constant>sambaLogonScript</constant></entry><entry>The sambaLogonScript property specifies the path of
+ the user's logon script, .CMD, .EXE, or .BAT file. The string can be null. The path
+ is relative to the netlogon share. Refer to the <smbconfoption name="logon script"/> parameter in the
+ &smb.conf; man page for more information.</entry></row>
+
+ <row><entry><constant>sambaProfilePath</constant></entry><entry>Specifies a path to the user's profile.
+ This value can be a null string, a local absolute path, or a UNC path. Refer to the
+ <smbconfoption name="logon path"/> parameter in the &smb.conf; man page for more information.</entry></row>
+
+ <row><entry><constant>sambaHomePath</constant></entry><entry>The sambaHomePath property specifies the path of
+ the home directory for the user. The string can be null. If sambaHomeDrive is set and specifies
+ a drive letter, sambaHomePath should be a UNC path. The path must be a network
+ UNC path of the form <filename>\\server\share\directory</filename>. This value can be a null string.
+ Refer to the <command>logon home</command> parameter in the &smb.conf; man page for more information.
+ </entry></row>
+ </tbody>
+ </tgroup></table>
+
+
+ <table frame="all" id="attribobjclPartB">
+ <title>Attributes in the sambaSamAccount ObjectClass (LDAP), Part B</title>
+ <tgroup cols="2" align="justify">
+ <colspec align="left"/>
+ <colspec align="justify" colwidth="1*"/>
+ <tbody>
+ <row><entry><constant>sambaUserWorkstations</constant></entry><entry>Here you can give a comma-separated list of machines
+ on which the user is allowed to login. You may observe problems when you try to connect to a Samba domain member.
+ Because domain members are not in this list, the domain controllers will reject them. Where this attribute is omitted,
+ the default implies no restrictions.
+ </entry></row>
+
+ <row><entry><constant>sambaSID</constant></entry><entry>The security identifier(SID) of the user.
+ The Windows equivalent of UNIX UIDs.</entry></row>
+
+ <row><entry><constant>sambaPrimaryGroupSID</constant></entry><entry>The security identifier (SID) of the primary group
+ of the user.</entry></row>
+
+ <row><entry><constant>sambaDomainName</constant></entry><entry>Domain the user is part of.</entry></row>
+ </tbody>
+ </tgroup></table>
+
+
+ <para>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>sambaSamAccount</primary></indexterm>
+ The majority of these parameters are only used when Samba is acting as a PDC of
+ a domain (refer to <link linkend="samba-pdc">Domain Control</link>, for details on
+ how to configure Samba as a PDC). The following four attributes
+ are only stored with the sambaSamAccount entry if the values are non-default values:
+ </para>
+
+ <itemizedlist>
+<indexterm><primary>sambaHomePath</primary></indexterm>
+<indexterm><primary>sambaLogonScript</primary></indexterm>
+<indexterm><primary>sambaProfilePath</primary></indexterm>
+<indexterm><primary>sambaHomeDrive</primary></indexterm>
+ <listitem><para>sambaHomePath</para></listitem>
+ <listitem><para>sambaLogonScript</para></listitem>
+ <listitem><para>sambaProfilePath</para></listitem>
+ <listitem><para>sambaHomeDrive</para></listitem>
+ </itemizedlist>
+
+ <para>
+<indexterm><primary>sambaSamAccount</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>smbHome</primary></indexterm>
+ These attributes are only stored with the sambaSamAccount entry if
+ the values are non-default values. For example, assume MORIA has now been
+ configured as a PDC and that <smbconfoption name="logon home">\\%L\%u</smbconfoption> was defined in
+ its &smb.conf; file. When a user named <quote>becky</quote> logs on to the domain,
+ the <smbconfoption name="logon home"/> string is expanded to \\MORIA\becky.
+ If the smbHome attribute exists in the entry <quote>uid=becky,ou=People,dc=samba,dc=org</quote>,
+ this value is used. However, if this attribute does not exist, then the value
+ of the <smbconfoption name="logon home"/> parameter is used in its place. Samba
+ will only write the attribute value to the directory entry if the value is
+ something other than the default (e.g., <filename>\\MOBY\becky</filename>).
+ </para>
+
+ </sect3>
+
+ <sect3>
+ <title>Example LDIF Entries for a sambaSamAccount</title>
+
+ <para>
+ The following is a working LDIF that demonstrates the use of the SambaSamAccount ObjectClass:
+<programlisting>
+dn: uid=guest2, ou=People,dc=quenya,dc=org
+sambaLMPassword: 878D8014606CDA29677A44EFA1353FC7
+sambaPwdMustChange: 2147483647
+sambaPrimaryGroupSID: S-1-5-21-2447931902-1787058256-3961074038-513
+sambaNTPassword: 552902031BEDE9EFAAD3B435B51404EE
+sambaPwdLastSet: 1010179124
+sambaLogonTime: 0
+objectClass: sambaSamAccount
+uid: guest2
+sambaKickoffTime: 2147483647
+sambaAcctFlags: [UX ]
+sambaLogoffTime: 2147483647
+sambaSID: S-1-5-21-2447931902-1787058256-3961074038-5006
+sambaPwdCanChange: 0
+</programlisting>
+ </para>
+
+ <para>
+ The following is an LDIF entry for using both the sambaSamAccount and
+ posixAccount ObjectClasses:
+<programlisting>
+dn: uid=gcarter, ou=People,dc=quenya,dc=org
+sambaLogonTime: 0
+displayName: Gerald Carter
+sambaLMPassword: 552902031BEDE9EFAAD3B435B51404EE
+sambaPrimaryGroupSID: S-1-5-21-2447931902-1787058256-3961074038-1201
+objectClass: posixAccount
+objectClass: sambaSamAccount
+sambaAcctFlags: [UX ]
+userPassword: {crypt}BpM2ej8Rkzogo
+uid: gcarter
+uidNumber: 9000
+cn: Gerald Carter
+loginShell: /bin/bash
+logoffTime: 2147483647
+gidNumber: 100
+sambaKickoffTime: 2147483647
+sambaPwdLastSet: 1010179230
+sambaSID: S-1-5-21-2447931902-1787058256-3961074038-5004
+homeDirectory: /home/moria/gcarter
+sambaPwdCanChange: 0
+sambaPwdMustChange: 2147483647
+sambaNTPassword: 878D8014606CDA29677A44EFA1353FC7
+</programlisting>
+ </para>
+
+ </sect3>
+
+ <sect3>
+ <title>Password Synchronization</title>
+
+ <para>
+ Samba-3 and later can update the non-Samba (LDAP) password stored with an account. When
+ using pam_ldap, this allows changing both UNIX and Windows passwords at once.
+ </para>
+
+ <para>The <smbconfoption name="ldap passwd sync"/> options can have the values shown in
+ <link linkend="ldappwsync">Possible <emphasis>ldap passwd sync</emphasis> Values</link>.</para>
+
+ <table frame="all" id="ldappwsync">
+ <title>Possible <parameter>ldap passwd sync</parameter> Values</title>
+ <tgroup cols="2">
+ <colspec align="left" colwidth="1*"/>
+ <colspec align="justify" colwidth="4*"/>
+ <thead>
+ <row><entry align="left">Value</entry><entry align="center">Description</entry></row>
+ </thead>
+ <tbody>
+ <row><entry>yes</entry><entry><para>When the user changes his password, update
+ <constant>SambaNTPassword</constant>, <constant>SambaLMPassword</constant>,
+ and the <constant>password</constant> fields.</para></entry></row>
+
+ <row><entry>no</entry><entry><para>Only update <constant>SambaNTPassword</constant> and
+ <constant>SambaLMPassword</constant>.</para></entry></row>
+
+ <row><entry>only</entry><entry><para>Only update the LDAP password and let the LDAP server
+ worry about the other fields. This option is only available on some LDAP servers and
+ only when the LDAP server supports LDAP_EXOP_X_MODIFY_PASSWD.</para></entry></row>
+ </tbody>
+ </tgroup>
+ </table>
+
+
+ <para>More information can be found in the &smb.conf; man page.</para>
+
+ </sect3>
+
+ <sect3>
+ <title>Using OpenLDAP Overlay for Password Syncronization</title>
+
+ <para>
+ Howard Chu has written a special overlay called <command>smbk5pwd</command>. This tool modifies the
+ <literal>SambaNTPassword</literal>, <literal>SambaLMPassword</literal> and <literal>Heimdal</literal>
+ hashes in an OpenLDAP entry when an LDAP_EXOP_X_MODIFY_PASSWD operation is performed.
+ </para>
+
+ <para>
+ The overlay is shipped with OpenLDAP-2.3 and can be found in the
+ <filename>contrib/slapd-modules/smbk5pwd</filename> subdirectory. This module can also be used with
+ OpenLDAP-2.2.
+ </para>
+
+ </sect3>
+
+ </sect2>
+
+</sect1>
+
+<sect1>
+<title>Common Errors</title>
+
+ <sect2>
+ <title>Users Cannot Logon</title>
+
+ <para><quote>I've installed Samba, but now I can't log on with my UNIX account! </quote></para>
+
+ <para>Make sure your user has been added to the current Samba <smbconfoption name="passdb backend"/>.
+ Read the <link linkend="acctmgmttools">Account Management Tools,</link> for details.</para>
+
+ </sect2>
+
+ <sect2>
+ <title>Configuration of <parameter>auth methods</parameter></title>
+
+ <para>
+ When explicitly setting an <smbconfoption name="auth methods"/> parameter,
+ <parameter>guest</parameter> must be specified as the first entry on the line &smbmdash;
+ for example, <smbconfoption name="auth methods">guest sam</smbconfoption>.
+ </para>
+
+ </sect2>
+
+</sect1>
+
+</chapter>