Fixing index problems.

(This used to be commit 2e192190776e41ed96ccb77af945e8ab815be526)

4 files changed, 233 insertions, 57 deletions

diff --git a/docs/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml b/docs/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml
index 042f1c156f..c5a5d7633a 100644
--- a/docs/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml
@@ -249,7 +249,7 @@ configuration parameter called the NetBIOS node-type. There are four basic NetBI
 </itemizedlist>
 
 <para>
-<indexterm><primary>Hybrid</primary></indexterm>
+<indexterm><primary>h-node</primary></indexterm>
 <indexterm><primary>hybrid</primary></indexterm>
 <indexterm><primary>enables NetBIOS over TCP/IP</primary></indexterm>
 <indexterm><primary>WINS</primary></indexterm>
diff --git a/docs/Samba3-HOWTO/TOSHARG-Passdb.xml b/docs/Samba3-HOWTO/TOSHARG-Passdb.xml
index 200861919e..34bf2604de 100644
--- a/docs/Samba3-HOWTO/TOSHARG-Passdb.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-Passdb.xml
@@ -20,12 +20,51 @@
 <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>
 Samba-3 implements a new capability to work concurrently with multiple account backends.
 The possible new combinations of password backends allows Samba-3 a degree of flexibility
-and scalability that previously could be achieved only with MS Windows Active Directory.
+and scalability that previously could be achieved only with MS Windows Active Directory (ADS).
 This chapter describes the new functionality and how to get the most out of it.
 </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 <literal>tdbsam</literal> method for all simple systems. Use
+the <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>
 
@@ -38,12 +77,17 @@ as follows:
 </para>
 
 <sect2>
-	<title>Backward Compatibility Backends</title>
+	<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
@@ -58,6 +102,10 @@ as follows:
 	<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
@@ -77,6 +125,9 @@ as follows:
 	<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
@@ -90,7 +141,7 @@ as follows:
 </sect2>
 
 <sect2>
-<title>New Backends</title>
+<title>New Account Storage Systems</title>
 
 <para>
 Samba-3 introduces a number of new password backend capabilities.
@@ -104,12 +155,21 @@ Samba-3 introduces a number of new password backend capabilities.
 	<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.
@@ -119,6 +179,9 @@ Samba-3 introduces a number of new password backend capabilities.
 			</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
@@ -131,16 +194,28 @@ Samba-3 introduces a number of new password backend capabilities.
 	<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
@@ -153,6 +228,8 @@ Samba-3 introduces a number of new password backend capabilities.
 	<varlistentry><term>mysqlsam (MySQL-based backend)</term>
 		<listitem>
 			<para>
+<indexterm><primary>MySQL-based SAM</primary></indexterm>
+<indexterm><primary>database backend</primary></indexterm>
 			It is expected that the MySQL-based SAM will be very popular in some corners.
 			This database backend will be of considerable interest to sites that want to
 			leverage existing MySQL technology.
@@ -163,10 +240,10 @@ Samba-3 introduces a number of new password backend capabilities.
 	<varlistentry><term>pgsqlsam (PostGreSQL-based backend)</term>
 		<listitem>
 			<para>
-				Stores user information in a PostgreSQL database.
-				This backend is largely undocumented at 
-				the moment, though its configuration is very similar to 
-				that of the mysqlsam backend.
+<indexterm><primary>PostgreSQL database</primary></indexterm>
+<indexterm><primary>mysqlsam</primary></indexterm>
+				Stores user information in a PostgreSQL database.  This backend is largely undocumented at 
+				the moment, though its configuration is very similar to that of the mysqlsam backend.
 			</para>
 		</listitem>
 	</varlistentry>
@@ -175,13 +252,21 @@ Samba-3 introduces a number of new password backend capabilities.
 		<listitem>
 			<para>
 <indexterm><primary>pdbedit</primary></indexterm>
+<indexterm><primary>XML format</primary></indexterm>
+<indexterm><primary>pdb2pdb</primary></indexterm>
 			Allows the account and password data to be stored in an XML format
 			data file. This backend cannot be used for normal operation, it can only 
 			be used in conjunction with <command>pdbedit</command>'s pdb2pdb 
-			functionality. The DTD that is used might be subject to changes in the future.
+			functionality. The Document Type Definition (DTD) file that is used 
+			might be subject to changes in the future. (See the XML <ulink
+			url="http://www.brics.dk/~amoeller/XML/schemas/">reference</ulink> for a definition
+			of XML terms.)
 			</para>
 
 			<para>
+<indexterm><primary>account migration</primary></indexterm>
+<indexterm><primary>database backends</primary></indexterm>
+<indexterm><primary>backend format</primary></indexterm>
 			The <parameter>xmlsam</parameter> option can be useful for account migration between database
 			backends or backups. Use of this tool allows the data to be edited before migration
 			into another backend format.
@@ -199,39 +284,54 @@ Samba-3 introduces a number of new password backend capabilities.
 	<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>	
-	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.
+<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>
-	These 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.
+<indexterm><primary>UNIX-style encrypted passwords</primary></indexterm>
+<indexterm><primary>converted</primary></indexterm>
+	Many people ask why Samba can not 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, plain text
-	file, and MySQL. For more information, see the man page for &smb.conf; regarding the 
+	information using a <smbconfoption name="passdb backend"/>. Commonly available backends are LDAP,
+	tdbsam, plain text file, and MySQL. 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="50">idmap-sid2uid</imagefile>
+		<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
@@ -247,6 +347,12 @@ Samba-3 introduces a number of new password backend capabilities.
 	<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>MYSQL</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
@@ -262,18 +368,25 @@ Samba-3 introduces a number of new password backend capabilities.
 		</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>
@@ -287,6 +400,9 @@ Samba-3 introduces a number of new password backend capabilities.
 
 		<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>
@@ -304,6 +420,12 @@ Samba-3 introduces a number of new password backend capabilities.
 		</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.
@@ -312,6 +434,11 @@ Samba-3 introduces a number of new password backend capabilities.
 		</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
@@ -324,26 +451,43 @@ Samba-3 introduces a number of new password backend capabilities.
 		<title>Advantages of Encrypted Passwords</title>
 
 			<itemizedlist>
-				<listitem><para>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>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>Plaintext passwords are not stored anywhere in
-				memory or on disk.</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>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.
+				<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>Encrypted password support allows automatic share
-				(resource) reconnects.</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>Encrypted passwords are essential for PDC/BDC
-				operation.</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>
 
@@ -352,15 +496,23 @@ Samba-3 introduces a number of new password backend capabilities.
 		<title>Advantages of Non-Encrypted Passwords</title>
 
 			<itemizedlist>
-				<listitem><para>Plaintext passwords are not kept 
-				on disk and are not cached in memory. </para></listitem>
+				<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>Plaintext passwords use the same password file as other UNIX 
-				services, such as Login and FTP.</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>Use of other services (such as Telnet and FTP) that
-				send plaintext passwords over the network makes sending them for SMB
-				is not such a big deal.</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 is not such a big deal.
+				</para></listitem>
 			</itemizedlist>
 		</sect3>
 	</sect2>
@@ -369,26 +521,38 @@ Samba-3 introduces a number of new password backend capabilities.
 	<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>
-	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.
+<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>
-	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 SAM server.
+	<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>
@@ -397,6 +561,12 @@ Samba-3 introduces a number of new password backend capabilities.
 	<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?
@@ -405,6 +575,13 @@ Samba-3 introduces a number of new password backend capabilities.
 	</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
diff --git a/docs/Samba3-HOWTO/TOSHARG-StandAloneServer.xml b/docs/Samba3-HOWTO/TOSHARG-StandAloneServer.xml
index ae658e28ea..fa7fdf72b9 100644
--- a/docs/Samba3-HOWTO/TOSHARG-StandAloneServer.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-StandAloneServer.xml
@@ -97,13 +97,12 @@ the Samba server is not a member of a domain security context.
 <indexterm><primary>local smbpasswd file</primary></indexterm>
 <indexterm><primary>LDAP backend</primary></indexterm>
 <indexterm><primary>Winbind</primary></indexterm>
-Through the use of Pluggable Authentication Modules (PAM) and the name service switcher (NSS),
-which maintains the UNIX-user database, the source of authentication may reside on 
-another server. We would be inclined to call this the authentication server.
-This means that the Samba server may use the local UNIX/Linux system password database
-(<filename>/etc/passwd</filename> or <filename>/etc/shadow</filename>), may use a
-local smbpasswd file, or may use an LDAP backend, or even via PAM and Winbind another CIFS/SMB server
-for authentication.
+Through the use of Pluggable Authentication Modules (PAM) (see <link linkend="pam">the chapter on PAM</link>)
+and the name service switcher (NSS), which maintains the UNIX-user database, the source of authentication may
+reside on another server. We would be inclined to call this the authentication server.  This means that the
+Samba server may use the local UNIX/Linux system password database (<filename>/etc/passwd</filename> or
+<filename>/etc/shadow</filename>), may use a local smbpasswd file, or may use an LDAP backend, or even via PAM
+and Winbind another CIFS/SMB server for authentication.
 </para>
 
 </sect1>
diff --git a/docs/Samba3-HOWTO/index.xml b/docs/Samba3-HOWTO/index.xml
index b4d17d4176..05792762cf 100644
--- a/docs/Samba3-HOWTO/index.xml
+++ b/docs/Samba3-HOWTO/index.xml
@@ -16,7 +16,7 @@
 
 	<?latex \setcounter{page}{5} ?>
 
-	<xi:include href="../Samba-HOWTO-attributions.xml">
+	<xi:include href="../Samba3-HOWTO-attributions.xml">
 		<xi:fallback/>
 	</xi:include>
 
@@ -152,7 +152,7 @@ The chapters in this part each cover specific Samba features.
 <!-- Comment out the following line to include the manpages.
 	 *Please* do not commit with the line below enabled! -->
 	<!--	 <xi:include href="manpages.xml"/> -->
-	<xi:include href="manpages.xml"/>
+	<!-- <xi:include href="manpages.xml"/> -->
 	<xi:include href="http://www.gnu.org/licenses/gpl.xml"/>
 
 	<xi:include href="TOSHARG-glossary.xml"/>