diff options
| author | Gerald W. Carter <jerry@samba.org> | 2008-04-22 10:09:40 -0500 |
|---|---|---|
| committer | Gerald W. Carter <jerry@samba.org> | 2008-04-23 08:47:48 -0500 |
| commit | 8f8a9f01909ba29e2b781310baeeaaddc3f15f0d (patch) | |
| tree | 90c6b720ad3a7bc815245c0ef28820424f89d658 /docs-xml/Samba3-HOWTO/TOSHARG-Passdb.xml | |
| parent | 197238246389c40edc60c6630d18d6913086e630 (diff) | |
| download | samba-8f8a9f01909ba29e2b781310baeeaaddc3f15f0d.tar.gz samba-8f8a9f01909ba29e2b781310baeeaaddc3f15f0d.tar.bz2 samba-8f8a9f01909ba29e2b781310baeeaaddc3f15f0d.zip | |
Moving docs tree to docs-xml to make room for generated docs in the release tarball.
(This used to be commit 9f672c26d63955f613088489c6efbdc08b5b2d14)
Diffstat (limited to 'docs-xml/Samba3-HOWTO/TOSHARG-Passdb.xml')
| -rw-r--r-- | docs-xml/Samba3-HOWTO/TOSHARG-Passdb.xml | 2675 |
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> |