Progress update.

(This used to be commit 86f20eacb8f5e707b07e6d7aced55c3d2b2d9d6a)

2 files changed, 353 insertions, 82 deletions

diff --git a/docs/Samba3-HOWTO/TOSHARG-BDC.xml b/docs/Samba3-HOWTO/TOSHARG-BDC.xml
index 5a62de8e86..1bd6db9028 100644
--- a/docs/Samba3-HOWTO/TOSHARG-BDC.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-BDC.xml
@@ -46,9 +46,11 @@ you will have stability and operational problems.
 <indexterm><primary>two-way</primary><secondary>propagation</secondary></indexterm>
 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
 <indexterm><primary>non-LDAP</primary><secondary>backend</secondary></indexterm>
-While it is possible to run a Samba-3 BDC with a non-LDAP backend, that
-backend must allow some form of "two-way" propagation of changes
-from the BDC to the master.  Only LDAP has such capability at this stage.
+<indexterm><primary>propagate</primary></indexterm>
+While it is possible to run a Samba-3 BDC with a non-LDAP backend, that backend must allow some form of
+"two-way" propagation of changes from the BDC to the master.  At this time only LDAP delivers the capability
+to propagate identity database changes from the BDC to the PDC. The BDC can use a slave LDAP server, while it
+is preferable for the PDC to use as its primary an LDAP master server.
 </para>
 
 <para>
@@ -141,12 +143,18 @@ possible design configurations for a PDC/BDC infrastructure.
 <title>Essential Background Information</title>
 
 <para>
+<indexterm><primary>domain controller</primary></indexterm>
+<indexterm><primary>logon requests</primary></indexterm>
+<indexterm><primary>LanMan</primary></indexterm>
+<indexterm><primary>Netlogon</primary></indexterm>
 A domain controller is a machine that is able to answer logon requests from network
 workstations. Microsoft LanManager and IBM LanServer were two early products that
 provided this capability. The technology has become known as the LanMan Netlogon service.
 </para>
 
 <para>
+<indexterm>network<primary></primary><secondary>logon</secondary><tertiary>service</tertiary></indexterm>
+<indexterm><primary>Windows NT3.10</primary></indexterm>
 When MS Windows NT3.10 was first released, it supported a new style of Domain Control
 and with it a new form of the network logon service that has extended functionality.
 This service became known as the NT NetLogon Service. The nature of this service has
@@ -158,6 +166,13 @@ services that are implemented over an intricate spectrum of technologies.
 <title>MS Windows NT4-style Domain Control</title>
 
 <para>
+<indexterm><primary>domain controller</primary></indexterm>
+<indexterm><primary>authentication server</primary></indexterm>
+<indexterm><primary>username</primary></indexterm>
+<indexterm><primary>password</primary></indexterm>
+<indexterm><primary>SAM</primary></indexterm>
+<indexterm><primary>Security Account Manager</primary><see>SAM</see></indexterm>
+<indexterm><primary>domain control database</primary><see>SAM</see></indexterm>
 Whenever a user logs into a Windows NT4/200x/XP Professional workstation,
 the workstation connects to a domain controller (authentication server) to validate that
 the username and password the user entered are valid. If the information entered
@@ -167,6 +182,11 @@ codes is returned to the workstation that has made the authentication request.
 </para>
 
 <para>
+<indexterm><primary>account information</primary></indexterm>
+<indexterm><primary>machine accounts database</primary></indexterm>
+<indexterm><primary>profile</primary></indexterm>
+<indexterm><primary>network access profile</primary></indexterm>
+<indexterm><primary>desktop profile</primary></indexterm>
 When the username/password pair has been validated, the domain controller
 (authentication server) will respond with full enumeration of the account information
 that has been stored regarding that user in the user and machine accounts database
@@ -181,6 +201,10 @@ in all versions of MS Windows NT (3.10, 3.50, 3.51, 4.0).
 
 <para>
 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
+<indexterm><primary>%SystemRoot%\System32\config</primary></indexterm>
+<indexterm><primary>C:\WinNT\System32\config</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>SAM</primary></indexterm>
 The account information (user and machine) on domain controllers is stored in two files,
 one containing the security information and the other the SAM. These are stored in files
 by the same name in the <filename>%SystemRoot%\System32\config</filename> directory. 
@@ -195,21 +219,29 @@ There are two situations in which it is desirable to install BDCs:
 
 <itemizedlist>
 	<listitem><para>
+	<indexterm><primary>PDC</primary></indexterm>
+	<indexterm><primary>BDC</primary></indexterm>
 	On the local network that the PDC is on, if there are many
 	workstations and/or where the PDC is generally very busy. In this case the BDCs
 	will pick up network logon requests and help to add robustness to network services.
 	</para></listitem>
 
 	<listitem><para>
+	<indexterm><primary>network</primary><secondary>wide-area</secondary></indexterm>
 	At each remote site, to reduce wide-area network traffic and to add stability to
-	remote network operations. The design of the network, the strategic placement of
-	BDCs, together with an implementation that localizes as much
-	of network to client interchange as possible will help to minimize wide-area network
-	bandwidth needs (and thus costs).
+	remote network operations. The design of the network, and the strategic placement of
+	BDCs, together with an implementation that localizes as much of network to client
+	interchange as possible, will help to minimize wide-area network bandwidth needs
+	(and thus costs).
 	</para></listitem>
 </itemizedlist>
 
 <para>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>SAM</primary></indexterm>
+<indexterm><primary>user account database</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>trigger</primary></indexterm>
 The interoperation of a PDC and its BDCs in a true Windows NT4 environment is worth
 mentioning here. The PDC contains the master copy of the SAM. In the event that an
 administrator makes a change to the user account database while physically present
@@ -223,6 +255,10 @@ trigger them to obtain the update and then apply that to their own copy of the S
 </para>
 
 <para>
+<indexterm><primary>SAM</primary><secondary>replication</secondary></indexterm>
+<indexterm><primary>SAM</primary><secondary>delta file</secondary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
 Samba-3 cannot participate in true SAM replication and is therefore not able to
 employ precisely the same protocols used by MS Windows NT4. A Samba-3 BDC will
 not create SAM update delta files. It will not interoperate with a PDC (NT4 or Samba)
@@ -230,12 +266,17 @@ to synchronize the SAM from delta files that are held by BDCs.
 </para>
 
 <para>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
 Samba-3 cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 cannot
 function correctly as a PDC to an MS Windows NT4 BDC. Both Samba-3 and MS Windows
 NT4 can function as a BDC to its own type of PDC.
 </para>
 
 <para>
+<indexterm><primary>SAM</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>domain security</primary></indexterm>
 The BDC is said to hold a <emphasis>read-only</emphasis> of the SAM from which
 it is able to process network logon requests and authenticate users. The BDC can
 continue to provide this service, particularly while, for example, the wide-area
@@ -244,23 +285,29 @@ maintenance of domain security as well as in network integrity.
 </para>
 
 <para>
-In the event that the NT4 PDC should need to be taken out of service, or if it dies, 
-one of the NT4 BDCs can be promoted to a PDC. If this happens while the original NT4 PDC
-is online, it is automatically demoted to an NT4 BDC. This is an important aspect of domain
-controller management. The tool that is used to effect a promotion or a demotion is the
-Server Manager for Domains. It should be noted that Samba-3 BDCs cannot be promoted
-in this manner because reconfiguration of Samba requires changes to the &smb.conf; file.
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>promoted</primary></indexterm>
+<indexterm><primary>demoted</primary></indexterm>
+<indexterm><primary>reconfiguration</primary></indexterm>
+In the event that the NT4 PDC should need to be taken out of service, or if it dies, one of the NT4 BDCs can
+be promoted to a PDC. If this happens while the original NT4 PDC is online, it is automatically demoted to an
+NT4 BDC. This is an important aspect of domain controller management. The tool that is used to effect a
+promotion or a demotion is the Server Manager for Domains. It should be noted that Samba-3 BDCs cannot be
+promoted in this manner because reconfiguration of Samba requires changes to the &smb.conf; file. It is easy
+enough to manuall change the &smb.conf; file and then restart relevant Samba network services.
 </para>
 
 <sect3>
 <title>Example PDC Configuration</title>
 
 <para>
-Beginning with Version 2.2, Samba officially supports domain logons for all current Windows clients,
-including Windows NT4, 2003, and XP Professional. For Samba to be enabled as a PDC, some
-parameters in the <smbconfsection name="[global]"/> section of the &smb.conf; have to be set.
-Refer to <link linkend="minimalPDC">the Minimal smb.conf for a PDC in Use with a BDC &smbmdash; LDAP Server on
-PDC section</link> for an example of the minimum required settings.
+<indexterm><primary>domain logon</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+Beginning with Version 2.2, Samba officially supports domain logons for all current Windows clients, including
+Windows NT4, 2003, and XP Professional. For Samba to be enabled as a PDC, some parameters in the
+<smbconfsection name="[global]"/> section of the &smb.conf; have to be set.  Refer to <link
+linkend="minimalPDC">the Minimal smb.conf for a PDC in Use with a BDC &smbmdash; LDAP Server on PDC
+section</link> for an example of the minimum required settings.
 </para>
 
 <example id="minimalPDC">
@@ -274,6 +321,8 @@ PDC section</link> for an example of the minimum required settings.
 </example>
 
 <para>
+<indexterm><primary>profile path</primary></indexterm>
+<indexterm><primary>home drive</primary></indexterm>
 Several other things like a <smbconfsection name="[homes]"/> and a
 <smbconfsection name="[netlogon]"/> share also need to be set along with
 settings for the profile path, the user's home drive, and so on. This is not covered in this
@@ -287,6 +336,9 @@ chapter; for more information please refer to <link linkend="samba-pdc">Domain C
 <title>LDAP Configuration Notes</title>
 
 <para>
+<indexterm><primary>LDAP</primary><secondary>master</secondary></indexterm>
+<indexterm><primary>LDAP</primary><secondary>slave</secondary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
 When configuring a master and a slave LDAP server, it is advisable to use the master LDAP server
 for the PDC and slave LDAP servers for the BDCs. It is not essential to use slave LDAP servers; however,
 many administrators will want to do so in order to provide redundant services. Of course, one or more BDCs
@@ -295,36 +347,51 @@ entire network.
 </para>
 
 <para>
-When configuring a master LDAP server that will have slave LDAP servers, do not forget to configure
-this in the <filename>/etc/openldap/slapd.conf</filename> file. It must be noted that the DN of a
-server certificate must use the CN attribute to name the server, and the CN must carry the servers'
-fully qualified domain name. Additional alias names and wildcards may be present in the
-subjectAltName certificate extension. More details on server certificate names are in RFC2830.
+<indexterm><primary>LDAP</primary><secondary>master</secondary></indexterm>
+<indexterm><primary>LDAP</primary><secondary>server</secondary></indexterm>
+<indexterm><primary>CN</primary></indexterm>
+<indexterm><primary>DN</primary></indexterm>
+<indexterm><primary>RFC2830</primary></indexterm>
+When configuring a master LDAP server that will have slave LDAP servers, do not forget to configure this in
+the <filename>/etc/openldap/slapd.conf</filename> file. It must be noted that the DN of a server certificate
+must use the CN attribute to name the server, and the CN must carry the servers' fully qualified domain name.
+Additional alias names and wildcards may be present in the subjectAltName certificate extension. More details
+on server certificate names are in RFC2830.
 </para>
 
 <para>
-It does not really fit within the scope of this document, but a working LDAP installation is
-basic to LDAP-enabled Samba operation. When using an OpenLDAP server with Transport Layer Security
-(TLS), the machine name in <filename>/etc/ssl/certs/slapd.pem</filename> must be the
-same as in <filename>/etc/openldap/sldap.conf</filename>. The Red Hat Linux startup script
-creates the <filename>slapd.pem</filename> file with hostname <quote>localhost.localdomain.</quote>
-It is impossible to access this LDAP server from a slave LDAP server (i.e., a Samba BDC) unless the
-certificate is re-created with a correct hostname.
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>transport layer security</primary><see>TLS</see></indexterm>
+<indexterm><primary>/etc/ssl/certs/slapd.pem</primary></indexterm>
+<indexterm><primary>slapd.pem</primary></indexterm>
+<indexterm><primary>Red Hat Linux</primary></indexterm>
+It does not really fit within the scope of this document, but a working LDAP installation is basic to
+LDAP-enabled Samba operation. When using an OpenLDAP server with Transport Layer Security (TLS), the machine
+name in <filename>/etc/ssl/certs/slapd.pem</filename> must be the same as in
+<filename>/etc/openldap/sldap.conf</filename>. The Red Hat Linux startup script creates the
+<filename>slapd.pem</filename> file with hostname <quote>localhost.localdomain.</quote> It is impossible to
+access this LDAP server from a slave LDAP server (i.e., a Samba BDC) unless the certificate is re-created with
+a correct hostname.
 </para>
 
 <para>
-For preference, do not install a Samba PDC on a OpenLDAP slave server. Joining client machines to the domain
-will fail in this configuration because the change to the machine account in the LDAP tree
-must take place on the master LDAP server. This is not replicated rapidly enough to the slave
-server that the PDC queries. It therefore gives an error message on the client machine about
-not being able to set up account credentials. The machine account is created on the LDAP server,
-but the password fields will be empty.  Unfortunately, some sites are
-unable to avoid such configurations, and these sites should review the
-<smbconfoption name="ldap replication sleep"/> parameter, intended to slow down Samba sufficiently
-for the replication to catch up.  This is a kludge, and one that the
-administrator must manually duplicate in any scripts (such as the
-<smbconfoption name="add machine script"/>) that
-they use.
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>machine account</primary></indexterm>
+<indexterm><primary>credentials</primary></indexterm>
+<indexterm><primary>replication</primary></indexterm>
+<indexterm><primary>duplicate</primary></indexterm>
+Do not install a Samba PDC so that is uses an LDAP slave server. Joining client machines to the domain
+will fail in this configuration because the change to the machine account in the LDAP tree must take place on
+the master LDAP server. This is not replicated rapidly enough to the slave server that the PDC queries. It
+therefore gives an error message on the client machine about not being able to set up account credentials. The
+machine account is created on the LDAP server, but the password fields will be empty.  Unfortunately, some
+sites are unable to avoid such configurations, and these sites should review the <smbconfoption name="ldap
+replication sleep"/> parameter, intended to slow down Samba sufficiently for the replication to catch up.
+This is a kludge, and one that the administrator must manually duplicate in any scripts (such as the
+<smbconfoption name="add machine script"/>) that they use.
 </para>
 
 <para>
@@ -369,6 +436,12 @@ Servers in &smb.conf; example</link>.
 <title>Active Directory Domain Control</title>
 
 <para>
+<indexterm><primary>MS Windows 2000</primary></indexterm>
+<indexterm><primary>Active Directory</primary></indexterm>
+<indexterm><primary>directory</primary></indexterm>
+<indexterm><primary>replicated</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>domain controller</primary></indexterm>
 As of the release of MS Windows 2000 and Active Directory, this information is now stored
 in a directory that can be replicated and for which partial or full administrative control
 can be delegated. Samba-3 is not able to be a domain controller within an Active Directory
@@ -382,15 +455,22 @@ act as a BDC to an Active Directory domain controller.
 <title>What Qualifies a Domain Controller on the Network?</title>
 
 <para>
+<indexterm><primary>DMB</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>WINS</primary></indexterm>
+<indexterm><primary>NetBIOS</primary></indexterm>
 Every machine that is a domain controller for the domain MIDEARTH has to register the NetBIOS
-group name MIDEARTH&lt;#1c&gt; with the WINS server and/or by broadcast on the local network.
-The PDC also registers the unique NetBIOS name MIDEARTH&lt;#1b&gt; with the WINS server.
-The name type &lt;#1b&gt; name is normally reserved for the Domain Master Browser (DMB), a role
+group name MIDEARTH&lt;#1C&gt; with the WINS server and/or by broadcast on the local network.
+The PDC also registers the unique NetBIOS name MIDEARTH&lt;#1B&gt; with the WINS server.
+The name type &lt;#1B&gt; name is normally reserved for the Domain Master Browser (DMB), a role
 that has nothing to do with anything related to authentication, but the Microsoft domain
 implementation requires the DMB to be on the same machine as the PDC.
 </para>
 
 <para>
+<indexterm><primary>broadcast</primary></indexterm>
+<indexterm><primary>name registration</primary></indexterm>
+<indexterm><primary>SMB/CIFS</primary></indexterm>
 Where a WINS server is not used, broadcast name registrations alone must suffice. Refer to
 <link linkend="NetworkBrowsing">Network Browsing</link>,<link linkend="netdiscuss">Discussion</link>
 for more information regarding TCP/IP network protocols and how SMB/CIFS names are handled.
@@ -402,12 +482,16 @@ for more information regarding TCP/IP network protocols and how SMB/CIFS names a
 <title>How Does a Workstation find its Domain Controller?</title>
 
 <para>
+<indexterm><primary>locate domain controller</primary></indexterm>
+<indexterm><primary>NetBIOS</primary></indexterm>
 There are two different mechanisms to locate a domain controller: one method is used when
 NetBIOS over TCP/IP is enabled and the other when it has been disabled in the TCP/IP
 network configuration.
 </para>
 
 <para>
+<indexterm><primary>DNS</primary></indexterm>
+<indexterm><primary>broadcast messaging</primary></indexterm>
 Where NetBIOS over TCP/IP is disabled, all name resolution involves the use of DNS, broadcast
 messaging over UDP, as well as Active Directory communication technologies. In this type of
 environment all machines require appropriate DNS entries. More information may be found in
@@ -417,6 +501,10 @@ environment all machines require appropriate DNS entries. More information may b
 <sect3>
 <title>NetBIOS Over TCP/IP Enabled</title>
 <para>
+<indexterm><primary>Windows NT4/200x/XP</primary></indexterm>
+<indexterm><primary>domain controller</primary></indexterm>
+<indexterm><primary>logon requests</primary></indexterm>
+<indexterm><primary>credentials validation</primary></indexterm>
 An MS Windows NT4/200x/XP Professional workstation in the domain MIDEARTH that wants a
 local user to be authenticated has to find the domain controller for MIDEARTH. It does this
 by doing a NetBIOS name query for the group name MIDEARTH&lt;#1c&gt;. It assumes that each
@@ -432,6 +520,10 @@ password) to the local domain controller for validation.
 <title>NetBIOS Over TCP/IP Disabled</title>
 
 <para>
+<indexterm><primary>realm</primary></indexterm>
+<indexterm><primary>logon authentication</primary></indexterm>
+<indexterm><primary>DNS</primary></indexterm>
+<indexterm><primary>_ldap._tcp.pdc._msdcs.quenya.org</primary></indexterm>
 An MS Windows NT4/200x/XP Professional workstation in the realm <constant>quenya.org</constant>
 that has a need to affect user logon authentication will locate the domain controller by 
 re-querying DNS servers for the <constant>_ldap._tcp.pdc._msdcs.quenya.org</constant> record.
@@ -446,13 +538,19 @@ More information regarding this subject may be found in <link linkend="adsdnstec
 <title>Backup Domain Controller Configuration</title>
 
 <para>
+<indexterm><primary>BDC</primary></indexterm>
 The creation of a BDC requires some steps to prepare the Samba server before
 &smbd; is executed for the first time. These steps are as follows:
-<indexterm><primary>SID</primary></indexterm>
 </para>
 
 <itemizedlist>
-<listitem><para>
+	<listitem><para>
+	<indexterm><primary>SID</primary></indexterm>
+	<indexterm><primary>PDC</primary></indexterm>
+	<indexterm><primary>BDC</primary></indexterm>
+	<indexterm><primary>private/secrets.tdb</primary></indexterm>
+	<indexterm><primary>private/MACHINE.SID</primary></indexterm>
+	<indexterm><primary>domain SID</primary></indexterm>
 	The domain SID has to be the same on the PDC and the BDC. In Samba versions
 	pre-2.2.5, the domain SID was stored in the file <filename>private/MACHINE.SID</filename>.
 	The domain SID is now stored in the file <filename>private/secrets.tdb</filename>. This file
@@ -462,6 +560,11 @@ The creation of a BDC requires some steps to prepare the Samba server before
 	</para>
 
 	<para>
+	<indexterm><primary>domain SID</primary></indexterm>
+	<indexterm><primary>PDC</primary></indexterm>
+	<indexterm><primary>BDC</primary></indexterm>
+	<indexterm><primary>secrets.tdb</primary></indexterm>
+	<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>getsid</tertiary></indexterm>
 	To retrieve the domain SID from the PDC or an existing BDC and store it in the
 	<filename>secrets.tdb</filename>, execute:
 	</para>
@@ -471,6 +574,9 @@ The creation of a BDC requires some steps to prepare the Samba server before
 	</listitem>
 
 	<listitem><para>
+	<indexterm><primary>secrets.tdb</primary></indexterm>
+	<indexterm><primary>smbpasswd</primary></indexterm>
+	<indexterm><primary>LDAP administration password</primary></indexterm>
 	Specification of the <smbconfoption name="ldap admin dn"/> is obligatory.
 	This also requires the LDAP administration password to be set in the <filename>secrets.tdb</filename>
 	using the <command>smbpasswd -w <replaceable>mysecret</replaceable></command>.
@@ -483,7 +589,10 @@ The creation of a BDC requires some steps to prepare the Samba server before
 	</para></listitem>
 
 	<listitem><para>
-<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
+	<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
+	<indexterm><primary>user database</primary></indexterm>
+	<indexterm><primary>synchronized</primary></indexterm>
+	<indexterm><primary>NIS</primary></indexterm>
 	The UNIX user database has to be synchronized from the PDC to the
 	BDC. This means that both the <filename>/etc/passwd</filename> and
 	<filename>/etc/group</filename> have to be replicated from the PDC
@@ -497,6 +606,14 @@ The creation of a BDC requires some steps to prepare the Samba server before
 	</listitem>
 
 	<listitem><para>
+	<indexterm><primary>password database</primary></indexterm>
+	<indexterm><primary>replicated</primary></indexterm>
+	<indexterm><primary>PDC</primary></indexterm>
+	<indexterm><primary>BDC</primary></indexterm>
+	<indexterm><primary>smbpasswd</primary></indexterm>
+	<indexterm><primary>rsync</primary></indexterm>
+	<indexterm><primary>ssh</primary></indexterm>
+	<indexterm><primary>LDAP</primary></indexterm>
 	The Samba password database must be replicated from the PDC to the BDC.
 	Although it is possible to synchronize the <filename>smbpasswd</filename>
 	file with <command>rsync</command> and <command>ssh</command>, this method
@@ -505,6 +622,12 @@ The creation of a BDC requires some steps to prepare the Samba server before
 	</para></listitem>
 
 	<listitem><para>
+	<indexterm><primary>netlogon share</primary></indexterm>
+	<indexterm><primary>replicate</primary></indexterm>
+	<indexterm><primary>PDC</primary></indexterm>
+	<indexterm><primary>BDC</primary></indexterm>
+	<indexterm><primary>cron</primary></indexterm>
+	<indexterm><primary>rsync</primary></indexterm>
 	The netlogon share has to be replicated from the PDC to the
 	BDC. This can be done manually whenever login scripts are changed,
 	or it can be done automatically using a <command>cron</command> job
@@ -534,23 +657,35 @@ as shown in <link linkend="minim-bdc">Minimal Setup for Being a BDC</link>.
 </example>
 
 <para>
-This configuration causes the BDC to register only the name MIDEARTH&lt;#1c&gt; with the
-WINS server. This is not a problem, as the name MIDEARTH&lt;#1c&gt; is a NetBIOS group name
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>NetBIOS</primary></indexterm>
+<indexterm><primary>group</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+This configuration causes the BDC to register only the name MIDEARTH&lt;#1C&gt; with the
+WINS server. This is not a problem, as the name MIDEARTH&lt;#1C&gt; is a NetBIOS group name
 that is meant to be registered by more than one machine. The parameter
 <smbconfoption name="domain master">no</smbconfoption>
-forces the BDC not to register MIDEARTH&lt;#1b&gt;, which is a unique NetBIOS name that 
+forces the BDC not to register MIDEARTH&lt;#1B&gt;, which is a unique NetBIOS name that 
 is reserved for the PDC.
 </para>
 
 <para>
 <indexterm><primary>idmap backend</primary></indexterm>
 <indexterm><primary>winbindd</primary></indexterm>
+<indexterm><primary>redirect</primary></indexterm>
+<indexterm><primary>winbindd</primary></indexterm>
+<indexterm><primary>LDAP database</primary></indexterm>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>GID</primary></indexterm>
 The <parameter>idmap backend</parameter> will redirect the <command>winbindd</command> utility to
 use the LDAP database to resolve all UIDs and GIDs for UNIX accounts.
 </para>
 
 <note><para>
 <indexterm><primary>Server Type</primary><secondary>Domain Member</secondary></indexterm>
+<indexterm><primary>ID mapping</primary></indexterm>
+<indexterm><primary>domain member server</primary></indexterm>
+<indexterm><primary>idmap backend</primary></indexterm>
 Samba-3 has introduced a new ID mapping facility. One of the features of this facility is that it
 allows greater flexibility in how user and group IDs are handled in respect to NT domain user and group
 SIDs. One of the new facilities provides for explicitly ensuring that UNIX/Linux UID and GID values
@@ -560,6 +695,9 @@ regarding its behavior.
 </para></note>
 
 <para>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>winbindd</primary></indexterm>
+<indexterm><primary>domain member servers</primary></indexterm>
 The use of the <smbconfoption name="idmap backend">ldap:ldap://master.quenya.org</smbconfoption>
 option on a BDC only makes sense where ldapsam is used on a PDC. The purpose of an LDAP-based idmap backend is
 also to allow a domain member (without its own passdb backend) to use winbindd to resolve Windows network users
@@ -574,6 +712,7 @@ member servers.
 <title>Common Errors</title>
 
 <para>
+<indexterm><primary>domain control</primary></indexterm>
 As domain control is a rather new area for Samba, there are not many examples that we may refer to.
 Updates will be published as they become available and may be found in later Samba releases or
 from the Samba Web <ulink url="http://samba.org">site</ulink>.
@@ -584,6 +723,9 @@ from the Samba Web <ulink url="http://samba.org">site</ulink>.
 
 <para>
 <indexterm><primary>Machine Trust Accounts</primary></indexterm>
+<indexterm><primary>passdb</primary></indexterm>
+<indexterm><primary>SAM</primary></indexterm>
+<indexterm><primary>Local Machine Trust Account</primary></indexterm>
 This problem will occur when the passdb (SAM) files are copied  from a central
 server but the local BDC is acting as a PDC. This results in the application of
 Local Machine Trust Account password updates to the local SAM. Such updates 
@@ -606,10 +748,14 @@ a slave LDAP server for each BDC and a master LDAP server for the PDC.
 
 <para>
 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
+<indexterm><primary>SAM</primary></indexterm>
 No. The native NT4 SAM replication protocols have not yet been fully implemented.
 </para>
 
 <para>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>logon requests</primary></indexterm>
 Can I get the benefits of a BDC with Samba?  Yes, but only to a Samba PDC.The
 main reason for implementing a BDC is availability. If the PDC is a Samba
 machine, a second Samba machine can be set up to service logon requests whenever
@@ -623,12 +769,17 @@ the PDC is down.
 
 <para>
 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
+<indexterm><primary>smbpasswd</primary></indexterm>
+<indexterm><primary>SAM</primary></indexterm>
 Replication of the smbpasswd file is sensitive. It has to be done whenever changes
 to the SAM are made. Every user's password change is done in the smbpasswd file and
 has to be replicated to the BDC. So replicating the smbpasswd file very often is necessary.
 </para>
 
 <para>
+<indexterm><primary>plaintext password</primary></indexterm>
+<indexterm><primary>ssh</primary></indexterm>
+<indexterm><primary>rsync</primary></indexterm>
 As the smbpasswd file contains plaintext password equivalents, it must not be
 sent unencrypted over the wire. The best way to set up smbpasswd replication from
 the PDC to the BDC is to use the utility rsync. rsync can use ssh as a transport.
@@ -637,6 +788,8 @@ the PDC to the BDC is to use the utility rsync. rsync can use ssh as a transport
 </para>
 
 <para>
+<indexterm><primary>machine trust accounts</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
 As said a few times before, use of this method is broken and flawed. Machine trust 
 accounts will go out of sync, resulting in a broken domain. This method is
 <emphasis>not</emphasis> recommended. Try using LDAP instead.
@@ -648,6 +801,8 @@ accounts will go out of sync, resulting in a broken domain. This method is
 <title>Can I Do This All with LDAP?</title>
 
 <para>
+<indexterm><primary>pdb_ldap</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
 The simple answer is yes. Samba's pdb_ldap code supports binding to a replica
 LDAP server and will also follow referrals and rebind to the master if it ever
 needs to make a modification to the database. (Normally BDCs are read-only, so
diff --git a/docs/Samba3-HOWTO/TOSHARG-PDC.xml b/docs/Samba3-HOWTO/TOSHARG-PDC.xml
index a82d36e9dd..99014eba01 100644
--- a/docs/Samba3-HOWTO/TOSHARG-PDC.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-PDC.xml
@@ -243,55 +243,171 @@ Information Databases</link>.
 </sect1>
 
 <sect1>
-<title>Comparison of Single Sign-on and Domain Security</title>
+<title>Single Sign-On and Domain Security</title>
 
 <para>
+<indexterm><primary>single sign-on</primary><see>SSO</see></indexterm>
+<indexterm><primary>SSO</primary></indexterm>
+<indexterm><primary>active directory</primary></indexterm>
+<indexterm><primary>authentication</primary></indexterm>
+<indexterm><primary>validation</primary></indexterm>
+<indexterm><primary>password uniqueness</primary></indexterm>
+<indexterm><primary>password history</primary></indexterm>
 When network administrators  are asked to describe the benefits of Windows NT4 and active directory networking
-the most often mentioned feature is that of SSO. Many companies have implemented SSO solutions. The mode of
-implementation of a single sign-on solution is an important factor in the practice of networking in general,
-and is critical in respect of Windows networking. Where a company may have a wide variety of information
-systems, each of which require some form of user authentication and validation it is not uncommon that users
-may need to remember more than a dozen login IDs and passwords. The problem will be compounded when the
-password for each system must be changed at regular intervals, and particularly so where password uniqueness
-and history limits are applied.
+the most often mentioned feature is that of single sign-on (SSO). Many companies have implemented SSO
+solutions. The mode of implementation of a single sign-on solution is an important factor in the practice of
+networking in general, and is critical in respect of Windows networking. A company may have a wide variety of
+information systems, each of which requires a form of user authentication and validation, thus it is not
+uncommon that users may need to remember more than ten login IDs and passwords. This problem is compounded
+when the password for each system must be changed at regular intervals, and particularly so where password
+uniqueness and history limits are applied.
+</para>
+
+<para>
+<indexterm><primary>management overheads</primary></indexterm>
+There is a broadly held perception that SSO is the answer to the problem of users having to deal with too many
+information system access credentials (username/password pairs). Many elaborate schemes have been devised to
+make it possible to deliver a user-friendly SSO solution. The trouble is that if this implementation is not
+done correctly, the site may end up paying dearly by way of complexity and management overheads. Simply put,
+many SSO solutions are an administrative nightmare.
 </para>
 
 <para>
-There is a wide perception that SSO is the answer to the problem of users having to deal with too many
-information system access credentials. Many elaborate schemes have been devised to make it possible to deliver
-a user-friendly SSO solution. The trouble is that if this implementation is not done correctly, the site may
-end up paying dearly by way of complexity and management overheads. Simply put, many SSO solutions are an
-administrative nightmare.
+<indexterm><primary>identity management</primary></indexterm>
+<indexterm><primary>authentication system</primary></indexterm>
+<indexterm><primary>SSO</primary></indexterm>
+SSO implementations utilize centralization of all user account information. Depending on environmental
+complexity and the age of the systems over which a SSO solution is implemented, it may not be possible to
+change the solution architecture so as to accomodate a new identity management and user authentication system.
+Many SSO solutions involving legacy systems consist of a new super-structure that handles authentication on
+behalf of the user. The software that gets layered over the old system may simply implement a proxy
+authentication system. This means that the addition of SSO increases over-all information systems complexity.
+Ideally, the implementation of SSO should reduce complexity and reduce administative overheads.
+</para>
+
+<para>
+<indexterm><primary>centralized identity management</primary></indexterm>
+<indexterm><primary>identity management</primary><secondary>centralized</secondary></indexterm>
+<indexterm><primary>centralized</primary><secondary>authentication</secondary></indexterm>
+<indexterm><primary>legacy systems</primary></indexterm>
+<indexterm><primary>access control</primary></indexterm>
+The initial goal of many network administrators is often to create and use a centralized identity management
+system. It is often assumed that such a centralized system will use a single authentication infrastructure
+that can be used by all information systems. The Microsoft Windows NT4 security domain architecture and the
+Micrsoft active directory service are often put forward as the ideal foundation for such a system. It is
+conceptually simple to install an external authentication agent on each of the disparate infromation systems
+that can then use the Microsoft (NT4 domain or ads service) for user authentication and access control. The
+wonderful dream of a single centralized authentication service is commonly broken when realities are realized.
+The problem with legacy systems is often the inability to externalize the authentication and access control
+system it uses because its implementation will be excessively invasive from a re-engineering perspective, or
+because application software has built-in dependencies on particular elements of the way user authentication
+and access control were designed and built.
+</para>
+
+<para>
+<indexterm><primary>meta-directory</primary></indexterm>
+<indexterm><primary>credentials</primary></indexterm>
+<indexterm><primary>disparate information systems</primary></indexterm>
+<indexterm><primary>management procedures</primary></indexterm>
+<indexterm><primary>work-flow protocol</primary></indexterm>
+<indexterm><primary>rights</primary></indexterm>
+<indexterm><primary>privileges</primary></indexterm>
+<indexterm><primary>provisioned</primary></indexterm>
+Over the past decade an industry has been developed around the various methods that have been built to get
+around the key limitations of legacy information technology systems. One approach that is often used involves
+the use of a meta-directory. The meta-directory stores user credentials for all disparate information systems
+in the format that is particular to each system. An elaborate set of management procedures is coupled with a
+rigidly enforced work-flow protocol for managing user rights and privileges within the maze of systems that
+are provisioned by the new infrastructure makes possible user access to all systems using a single set of user
+credentials.
+</para>
+
+<para>
+<indexterm><primary>Organization for the Advancement of Structured Information Standards</primary><see>OASIS</see></indexterm>
+<indexterm><primary>Security Assertion Markup Language</primary><see>SAML</see></indexterm>
+<indexterm><primary>Federated Identity Management</primary><see>FIM</see></indexterm>
+<indexterm><primary>secure access</primary></indexterm>
+The Organization for the Advancement of Structured Information Standards (OASIS) has developed the Security
+Assertion Markup Language (SAML), a structured method for communication of authentication information. The
+over-all umbrella name for the technologies and methods that deploy SAML is called Federated Identity
+Management (FIM). FIM depends on each system in the complex maze of disparate information systems to
+authenticate their respective users and vouch for secure access to the services each provides.
+</para>
+
+<para>
+<indexterm><primary>Simple Object Access Protocol</primary><see>SOAP</see></indexterm>
+<indexterm><primary>federated organizations</primary></indexterm>
+<indexterm><primary>Liberty Alliance</primary></indexterm>
+<indexterm><primary>federated-identity</primary></indexterm>
+<indexterm><primary></primary></indexterm>
+<indexterm><primary></primary></indexterm>
+SAML documents can be wrapped in a Simple Object Access Protocol (SOAP) message for the computer-to-computer
+communications needed for Web services. Or they may be passed between Web servers of federated organizations
+that share live services. The Liberty Alliance, an industry group formed to promote federated-identity
+standards, has adopted SAML 1.1 as part of its application framework. Microsoft and IBM have proposed an
+alternative specification called WS-Security. Some believe that the competing technologies and methods may
+converge when the SAML 2.0 standard is introduced. A few Web access-management products support SAML today,
+but implemention of the technology mostly requires customization to integrate applications and develop user
+interfaces. In a nust-shell, that is why FIM is a big and growing industry.
+</para>
+
+<para>
+<indexterm><primary>interoperability</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>GSSAPI</primary></indexterm>
+<indexterm><primary>general security service application programming interface</primary><see>GSSAPI</see></indexterm>
+Ignoring the bigger picture, which is beyond the scope of this book, the migration of all user and group
+management to a centralized system is a step in the right direction. It is essential for interoperability
+reasons to locate the identity management system data in a directory such as Microsoft Active Directory
+Service (ADS), or any proprietary or open source system that provides a standard protocol for information
+access (such as LDAP) and that can be coupled with a flexible array of authentication mechanisms (such as
+kerberos) that use the protocols that are defined by the various general security service application
+programming interface (GSSAPI) services.
 </para>
 
 <para>
-SSO implementations may involve centralization of all user account information in one repository. Depending on
-environmental complexity and the age of the systems over which a SSO solution is implemented, it may not be
-possible to change the solution architecture so as to accomodate a new identity management and user
-authentication system. Many SSO solutions involving legacy systems consist of a new super-structure that
-handles authentication on behalf of the user. The software that gets layered over the old system may simply
-implement a proxy authentication system. This means that the addition of SSO increases over-all information
-systems complexity. Ideally, the implementation of SSO should reduce complexity and reduce administative
-overheads.
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>authentication agents</primary></indexterm>
+A growing number of companies provide authentication agents for disparate legacy platforms to permit the use
+of LDAP systems. Thus the use of OpenLDAP, the dominant open source software implementation of the light
+weight directory access protocol standard. This fact, means that by providing support in Samba for the use of
+LDAP and Microsoft ADS make Samba a highly scalable and forward reaching organizational networking technology.
 </para>
 
 <para>
-JJJ More Info HERE!
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>authentication architecture</primary></indexterm>
+<indexterm><primary>ntlm_auth</primary></indexterm>
+<indexterm><primary>SQUID</primary></indexterm>
+<indexterm><primary>FIM</primary></indexterm>
+Microsoft ADS provides purely proprietary services that, with limitation, can be extended to provide a
+centralized authentication infrastructure. Samba plus LDAP provides a similar opportunity for extension of a
+centralized authentication architecture, but it is the fact that the Samba Team are pro-active in introducing
+the extension of authentication services, using LDAP or otherwise, to applications such as SQUID (the open
+source proxy server) through tools such as the <command>ntlm_auth</command> utility, that does much to create
+sustainable choice and competition in the FIM market place.
 </para>
 
 <para>
-Briefly describe:	1. New auth system that uses external auth.
-					2. SSO system that stores info about all IT systems, and provides front-end
-						app. that hides the IT systems beneath a veneer of its own.
-					3. Meta-directories and distribution if ID info.
-					4. The significance of Samba in the context of SSO
-					5. Implications of domain security
-						a) with NT4 domain
-						b) with ADS
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>identity information</primary></indexterm>
+Primary domain control, if it is to be scalable to meet the needs of large sites, must therefore be capable of
+using LDAP. The rapid adoption of OpenLDAP, and Samba configurations that use it, is ample proof that the era
+of the directoy has started. Samba-3 does not demand the use of LDAP, but the demand for a mechanism by which
+user and group identity information can be distributed makes it an an unavoidable option.
 </para>
 
 <para>
-Other considerations: Should this stuff go elsewhere? Should it be dropped? Should this chapter be revamped?
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>e-Directory</primary></indexterm>
+At this time, the use of Samba based BDCs, necessitates the use of LDAP. The most commonly used LDAP
+implementation used by Samba sites is OpenLDAP. It is possible to use any standards compliant LDAP server.
+Those known to work includes those manufactured by: IBM, CA, Novell (e-Directory), and others.
 </para>
 
 </sect1>