Merge lp:~petermatulis/serverguide/serverguide-review-6.1 into lp:~ubuntu-core-doc/serverguide/oneiric

[Peter Matulis]

This subchapter was re-written using the Natty document as a skeleton. There were many mistakes in the old document and there was not enough explanation. I tried hard to be concise and referred to upstream documentation when possible. I added a new section call "Logging".

[Ahmed Kamal (kim0)]

An excellent review, thanks for greatly improving this chapter. I got a few little points to discuss:

- I notice a few shell scripts lost their execute permission. Can you please fix that
- On line 354 in this diff (/etc/ldap/slapd.d/ contents), I am not sure how this output was created. i.e. perhaps it's worth showing what command you used
- At the end of the chapter, you're including a list of man page links. Would it be a good idea to remove "oneiric" from the URL, example: http://manpages.ubuntu.com/manpages/en/man1/ldapadduser.1.html It seems the website does the right thing and always redirects you to the latest release

review: Needs Fixing

[lp:~petermatulis/serverguide/serverguide-review-6.1]

8. By Peter Matulis on 2011-10-04

Edits made based on merge proposal; subchapter 6.1

[Peter Matulis (petermatulis)]

Changes made. Including all man page links you did not mention.

Re missing command, I am providing the layout of the slapd-config database (/etc/ldap/slapd.d/). It's not meant for the reader to duplicate that. They should be able to browse the structure themselves using standard tools (i.e. 'ls').

[Ahmed Kamal (kim0)]

Thank you, this is a great contribution

review: Approve

[Connor Imes (ckimes)]

I've merged this one now as well, but had to resolve some conflicts with the section 6.1 review in merge request 75664 that was completed earlier.

=== modified file 'serverguide/C/network-auth.xml'
--- serverguide/C/network-auth.xml	2011-05-03 07:11:18 +0000
+++ serverguide/C/network-auth.xml	2011-10-04 12:44:23 +0000
@@ -9,194 +9,427 @@
 %xinclude;
 <!ENTITY language "&EnglishAmerican;">
 ]>
+
 <chapter id="network-authentication" status="review">
 	<title>Network Authentication</title>
 
-         <para>
-         This section explains various Network Authentication protocols.
-         </para>
+        <para>
+        This section applies LDAP to network authentication.
+        </para>
+
 	<sect1 id="openldap-server" status="review">
-		<title>OpenLDAP Server</title>
-         <para>
-	 LDAP is an acronym for Lightweight Directory Access Protocol, it is a simplified
-         version of the X.500 protocol. The directory setup in this section will 
-	 be used for authentication. Nevertheless, LDAP can be
-         used in numerous ways: authentication, shared directory (for mail
-         clients), address book, etc.
-         </para>
-
-         <para>
-         To describe LDAP quickly,  all information is stored in a tree structure. With 
-	 <application>OpenLDAP</application> you have freedom to determine 
-	 the directory arborescence (the Directory Information Tree: the DIT) yourself.
-	 We will begin with a basic tree containing two nodes below the root:
-         </para>
-
-	 <itemizedlist>
-           <listitem>
-               <para>"People" node where your users will be stored</para>
-           </listitem>
-           <listitem>
-               <para>"Groups" node where your groups will be stored</para>
-           </listitem>
-         </itemizedlist>
-
-	 <para>
-         Before beginning, you should determine what the root of your LDAP directory
-	 will be. By default, your tree will be determined by your Fully Qualified 
-	 Domain Name (FQDN). If your domain is example.com (which we will use in this 
-         example), your root node will be dc=example,dc=com. 
+	<title>OpenLDAP Server</title>
+
+	<para>
+	The Lightweight Directory Access Protocol, or LDAP, is a protocol for querying and modifying a X.500-based directory service running
+	over TCP/IP. The current LDAP version is LDAPv3, as defined in <ulink url="http://tools.ietf.org/html/rfc4510">RFC4510</ulink>, and
+	the LDAP implementation used in Ubuntu is OpenLDAP, currently at version 2.4.25 (Oneiric).
+	</para>
+
+	<para>
+	So this protocol accesses LDAP directories. Here are some key concepts and terms:
+	</para>
+
+	<itemizedlist>
+
+		<listitem>
+		<para>
+		A LDAP directory is a tree of data <emphasis>entries</emphasis> that is hierarchical in nature and is called
+		the Directory Information Tree (DIT).
+		</para>
+		</listitem>
+
+		<listitem>
+		<para>
+		An entry consists of a set of <emphasis>attributes</emphasis>.
+		</para>
+		</listitem>
+
+		<listitem>
+		<para>
+		An attribute has a <emphasis>type</emphasis> (a name/description) and one or more <emphasis>values</emphasis>.
+		</para>
+		</listitem>
+
+		<listitem>
+		<para>
+		Every attribute must be defined in at least one <emphasis>objectClass</emphasis>.
+		</para>
+		</listitem>
+
+		<listitem>
+		<para>
+		Attributes and objectclasses are defined in <emphasis>schemas</emphasis> (an objectclass is actually
+		considered as a special kind of attribute).
+		</para>
+		</listitem>
+
+		<listitem>
+		<para>
+		Each entry has a unique identifier: it's <emphasis>Distinguished Name</emphasis> (DN or dn). This consists
+		of it's <emphasis>Relative Distinguished Name</emphasis> (RDN) followed by the parent entry's DN.
+		</para>
+		</listitem>
+
+		<listitem>
+		<para>
+		The entry's DN is not an attribute. It is not considered part of the entry itself.
+		</para>
+		</listitem>
+
+	</itemizedlist>
+
+	<note>
+		<para>
+		The terms <emphasis>object</emphasis>, <emphasis>container</emphasis>, and <emphasis>node</emphasis> have certain
+		connotations but they all essentially mean the same thing as <emphasis>entry</emphasis>, the technically correct term.
+		</para>
+	</note>
+
+	<para>
+	For example, below we have a single entry consisting of 11 attributes. It's DN is "cn=John Doe,dc=example,dc=com"; it's RDN is "cn=John Doe";
+	and it's parent DN is "dc=example,dc=com".
+	</para>
+
+<programlisting>
+ dn: cn=John Doe,dc=example,dc=com
+ cn: John Doe
+ givenName: John
+ sn: Doe
+ telephoneNumber: [phone]
+ telephoneNumber: [phone]
+ mail: [e-mail]
+ manager: cn=Larry Smith,dc=example,dc=com
+ objectClass: inetOrgPerson
+ objectClass: organizationalPerson
+ objectClass: person
+ objectClass: top
+</programlisting>
+
+	<para>
+	The above entry is in <emphasis>LDIF</emphasis> format (LDAP Data Interchange Format). Any information that you feed
+	into your DIT must also be in such a format. It is defined in <ulink url="http://tools.ietf.org/html/rfc2849">RFC2849</ulink>.
+	</para>
+
+	<para>
+        Although this guide will describe how to use it for central authentication, LDAP is good for anything that involves a large number
+	of access requests to a mostly-read, attribute-based (name:value) backend. Examples include an address book, a list of email addresses,
+	and a mail server's configuration.
         </para>
 
-	<sect2 id="openldap-server-installation" status="review">
+		<sect2 id="openldap-server-installation" status="review">
 		<title>Installation</title>
 
    	<para>
-	First, install the <application>OpenLDAP</application> server daemon 
-	<application>slapd</application> and <application>ldap-utils</application>, 
-	a package containing LDAP management utilities:
-	</para>
+	Install the OpenLDAP server daemon and the traditional LDAP management utilities. These are found in packages <application>slapd</application>
+	and <application>ldap-utils</application> respectively. 
+	</para>
+
+	<para>
+        The installation of slapd will create a working configuration. In particular, it will create a database instance that you
+	can use to store your data.  However, the suffix (or base DN) of this instance will be determined from the domain name of the localhost.
+	If you want something different, edit <filename>/etc/hosts</filename> and replace the domain name with one that will give you the
+	suffix you desire.  For instance, if you want a suffix of <emphasis>dc=example,dc=com</emphasis> then your file would have a line
+	similar to this:
+	</para>
+
+<programlisting>
+127.0.1.1       hostname.example.com	hostname
+</programlisting>
+
+	<para>
+	You can revert the change after package installation.
+	</para>
+
+	<note>
+		<para>
+		This guide will use a database suffix of <emphasis>dc=example,dc=com</emphasis>.
+		</para>
+	</note>
+
+	<para>
+	Proceed with the install:
+	</para>
+
 <screen>
 <command>sudo apt-get install slapd ldap-utils</command>
 </screen>
-	
-	<para>
-        By default <application>slapd</application> is configured with minimal options needed 
-        to run the <application>slapd</application> daemon.
-	</para>
-
-	<para>
-        The configuration example in the following sections will match the domain name of the server.
-        For example, if the machine's Fully Qualified Domain Name (FQDN) is 
-        ldap.example.com, the default suffix will be <emphasis>dc=example,dc=com</emphasis>.
-	</para>
-
-        </sect2>
-        <sect2 id="openldap-server-populate" status="review">
-	<title>Populating LDAP</title>
-
-        <para>
-        <application>OpenLDAP</application> uses a separate directory which contains the 
-        <emphasis>cn=config</emphasis> Directory Information Tree (DIT).  The
-        <emphasis>cn=config</emphasis> DIT is used to dynamically configure the 
-        <application>slapd</application> daemon, allowing the modification of schema 
-        definitions, indexes, ACLs, etc without stopping the service.
-        </para>
-
-	<para>
-	The backend <emphasis>cn=config</emphasis> directory has only a minimal configuration and will 
-        need additional configuration options in order to populate the frontend directory.  The frontend will be populated
-        with a "classical" scheme that will be compatible with address book applications and with Unix Posix 
-        accounts.  Posix accounts will allow authentication to various applications, such as web 
-	applications, email Mail Transfer Agent (MTA) applications, etc.
-	</para>
-	
-	<note>
-	  <para>
-	  For external applications to authenticate using LDAP they will each need to be 
-	  specifically configured to do so.  Refer to the individual application 
-	  documentation for details.	 
-	  </para>
-	</note>
-
-	<note>
-	  <para>
-          Remember to change <emphasis>dc=example,dc=com</emphasis> in the following examples to match your LDAP configuration.
-	  </para>
-	</note>
-
-        <para>
-        First, some additional schema files need to be loaded.  In a terminal enter:
-        </para>
-
-<screen>
-<command>sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif</command>
-<command>sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif</command>
-<command>sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/inetorgperson.ldif</command>
-</screen>
-
-	<para>
-	Next, copy the following example LDIF file, naming it
-	<filename>backend.example.com.ldif</filename>, somewhere on your system:
-	</para>
-
-<programlisting>
-# Load dynamic backend modules
-dn: cn=module,cn=config
-objectClass: olcModuleList
-cn: module
-olcModulepath: /usr/lib/ldap
-olcModuleload: back_hdb.la
-
-# Database settings
-dn: olcDatabase=hdb,cn=config
-objectClass: olcDatabaseConfig
-objectClass: olcHdbConfig
-olcDatabase: {1}hdb
-olcSuffix: dc=example,dc=com
-olcDbDirectory: /var/lib/ldap
-olcRootDN: cn=admin,dc=example,dc=com
-olcRootPW: secret
-olcDbConfig: set_cachesize 0 2097152 0
-olcDbConfig: set_lk_max_objects 1500
-olcDbConfig: set_lk_max_locks 1500
-olcDbConfig: set_lk_max_lockers 1500
-olcDbIndex: objectClass eq
-olcLastMod: TRUE
-olcDbCheckpoint: 512 30
-olcAccess: to attrs=userPassword by dn="cn=admin,dc=example,dc=com" write by anonymous auth by self write by * none
-olcAccess: to attrs=shadowLastChange by self write by * read
-olcAccess: to dn.base="" by * read
-olcAccess: to * by dn="cn=admin,dc=example,dc=com" write by * read
-
-</programlisting>
-
-        <note>
-          <para>
-          Change <emphasis>olcRootPW: secret</emphasis> to a password of your choosing.
-          </para>
-        </note>
-
-	<para>
-	Now add the LDIF to the directory:
-	</para>
-
-<screen>
-<command>sudo ldapadd -Y EXTERNAL -H ldapi:/// -f backend.example.com.ldif</command>
-</screen>
-
-        <para>
-        The frontend directory is now ready to be populated.  Create a <filename>frontend.example.com.ldif</filename> 
-        with the following contents:
-        </para>
-
-<programlisting>
-# Create top-level object in domain
+
+        <para>
+        Since Ubuntu 8.10 slapd is designed to be configured within slapd itself by dedicating a separate DIT for that purpose. This allows one
+	to dynamically configure slapd without the need to restart the service. This configuration database consists of a collection of text-based
+	LDIF files located under <filename>/etc/ldap/slapd.d</filename>. This way of working is known by several names: the slapd-config method,
+	the RTC method (Real Time Configuration), or the cn=config method. You can still use the traditional flat-file method (slapd.conf) but it's
+	not recommended; the functionality will be eventually phased out.
+        </para>
+
+	<note>
+		<para>
+		Ubuntu now uses the <emphasis>slapd-config</emphasis> method for slapd configuration and this
+		guide reflects that.
+		</para>
+	</note>
+
+	<para>
+ 	During the install you were prompted to define administrative credentials. These are LDAP-based credentials for the <emphasis>rootDN</emphasis>
+	of your database instance. By default, this user's DN is <emphasis>cn=admin,dc=example,dc=com</emphasis>. Also by default, there is no
+	administrative account created for the slapd-config database and you will therefore need to authenticate externally to LDAP in order to access it.
+	We will see how to do this later on.
+	</para>
+
+	<para>
+	Some classical schemas (cosine, nis, inetorgperson) come built-in with slapd nowadays. There is also an included "core" schema, a pre-requisite
+	for any schema to work.
+	</para>
+
+		</sect2>
+
+		<sect2 id="openldap-server-postinstall" status="review">
+		<title>Post-install Inspection</title>
+
+	<para>
+	The installation process set up 2 DITs. One for slapd-config and one for your own data (dc=example,dc=com). Let's take a look.
+	</para>
+
+	<itemizedlist>
+
+		<listitem>
+		<para>
+		This is what the slapd-config database/DIT looks like.  Recall that this database is
+		LDIF-based and lives under <filename>/etc/ldap/slapd.d</filename>:
+		</para>
+
+<screen>
+<computeroutput>
+    /etc/ldap/slapd.d/
+
+	├── cn=config
+	│   ├── cn=module{0}.ldif
+	│   ├── cn=schema
+	│   │   ├── cn={0}core.ldif
+	│   │   ├── cn={1}cosine.ldif
+	│   │   ├── cn={2}nis.ldif
+	│   │   └── cn={3}inetorgperson.ldif
+	│   ├── cn=schema.ldif
+	│   ├── olcBackend={0}hdb.ldif
+	│   ├── olcDatabase={0}config.ldif
+	│   ├── olcDatabase={-1}frontend.ldif
+	│   └── olcDatabase={1}hdb.ldif
+	└── cn=config.ldif
+</computeroutput>
+</screen>
+
+	<note>
+		<para>
+		Do not edit the slapd-config database directly. Make changes via the LDAP protocol (utilities).
+		</para>
+	</note>
+
+		</listitem>
+
+		<listitem>
+		<para>
+		This is what the slapd-config DIT looks like via the LDAP protocol:
+		</para>
+
+<screen>
+<command>sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn</command>
+<computeroutput>
+dn: cn=config
+
+dn: cn=module{0},cn=config
+
+dn: cn=schema,cn=config
+
+dn: cn={0}core,cn=schema,cn=config
+
+dn: cn={1}cosine,cn=schema,cn=config
+
+dn: cn={2}nis,cn=schema,cn=config
+
+dn: cn={3}inetorgperson,cn=schema,cn=config
+
+dn: olcBackend={0}hdb,cn=config
+
+dn: olcDatabase={-1}frontend,cn=config
+
+dn: olcDatabase={0}config,cn=config
+
+dn: olcDatabase={1}hdb,cn=config
+</computeroutput>
+</screen>
+
+		<para>
+		Explanation of entries:
+		</para>
+
+		<itemizedlist>
+
+			<listitem>
+			<para>
+			<emphasis>cn=config</emphasis>: global settings
+			</para>
+			</listitem>
+
+			<listitem>
+			<para>
+			<emphasis>cn=module{0},cn=config</emphasis>: a dynamically loaded module
+			</para>
+			</listitem>
+
+			<listitem>
+			<para>
+			<emphasis>cn=schema,cn=config</emphasis>: contains hard-coded system-level schema
+			</para>
+			</listitem>
+
+			<listitem>
+			<para>
+			<emphasis>cn={0}core,cn=schema,cn=config</emphasis>: the hard-coded core schema
+			</para>
+			</listitem>
+
+			<listitem>
+			<para>
+			<emphasis>cn={1}cosine,cn=schema,cn=config</emphasis>: the cosine schema
+			</para>
+			</listitem>
+
+			<listitem>
+			<para>
+			<emphasis>cn={2}nis,cn=schema,cn=config</emphasis>: the nis schema
+			</para>
+			</listitem>
+
+			<listitem>
+			<para>
+			<emphasis>cn={3}inetorgperson,cn=schema,cn=config</emphasis>: the inetorgperson schema
+			</para>
+			</listitem>
+
+			<listitem>
+			<para>
+			<emphasis>olcBackend={0}hdb,cn=config</emphasis>: the 'hdb' backend storage type
+			</para>
+			</listitem>
+
+			<listitem>
+			<para>
+			<emphasis>olcDatabase={-1}frontend,cn=config</emphasis>: frontend database, default settings for other databases
+			</para>
+			</listitem>
+
+			<listitem>
+			<para>
+			<emphasis>olcDatabase={0}config,cn=config</emphasis>: slapd configuration database (cn=config)
+			</para>
+			</listitem>
+
+			<listitem>
+			<para>
+			<emphasis>olcDatabase={1}hdb,cn=config</emphasis>: your database instance (dc=examle,dc=com)
+			</para>
+			</listitem>
+		
+		</itemizedlist>
+
+		</listitem>
+
+		<listitem>
+
+		<para>
+		This is what the dc=example,dc=com DIT looks like:
+		</para>
+
+<screen>
+<command>ldapsearch -x -LLL -H ldap:/// -b dc=example,dc=com dn</command>
+<computeroutput>
 dn: dc=example,dc=com
-objectClass: top
-objectClass: dcObject
-objectclass: organization
-o: Example Organization
-dc: Example
-description: LDAP Example 
 
-# Admin user.
 dn: cn=admin,dc=example,dc=com
-objectClass: simpleSecurityObject
-objectClass: organizationalRole
-cn: admin
-description: LDAP administrator
-userPassword: secret
-
-dn: ou=people,dc=example,dc=com
-objectClass: organizationalUnit
-ou: people
-
-dn: ou=groups,dc=example,dc=com
-objectClass: organizationalUnit
-ou: groups
-
-dn: uid=john,ou=people,dc=example,dc=com
+</computeroutput>
+</screen>
+
+		<para>
+		Explanation of entries:
+		</para>
+
+		<itemizedlist>
+
+			<listitem>
+			<para>
+			<emphasis>dc=example,dc=com</emphasis>: base of the DIT
+			</para>
+			</listitem>
+
+			<listitem>
+			<para>
+			<emphasis>cn=admin,dc=example,dc=com</emphasis>: administrator (rootDN) for this DIT (set up during package install)
+			</para>
+			</listitem>
+
+		</itemizedlist>
+
+		</listitem>
+
+	</itemizedlist>
+
+		</sect2>
+
+		<sect2 id="openldap-server-populate" status="review">
+		<title>Modifying/Populating your Database</title>
+
+        <para>
+	Let's introduce some content to our database.  We will add the following:
+	</para>
+
+	<itemizedlist>
+
+	<listitem>
+	<para>
+	a node called <emphasis>People</emphasis> (to store users)
+	</para>
+        </listitem>
+
+	<listitem>
+	<para>
+	a node called <emphasis>Groups</emphasis> (to store groups)
+	</para>
+        </listitem>
+
+	<listitem>
+	<para>
+	a group called <emphasis>miners</emphasis>
+	</para>
+        </listitem>
+
+	<listitem>
+	<para>
+	a user called <emphasis>john</emphasis>
+	</para>
+        </listitem>
+
+	</itemizedlist>
+
+	<para>
+	Create the following LDIF file and call it <filename>add_content.ldif</filename>:
+	</para>
+
+<programlisting>
+dn: ou=People,dc=example,dc=com
+objectClass: organizationalUnit
+ou: People
+
+dn: ou=Groups,dc=example,dc=com
+objectClass: organizationalUnit
+ou: Groups
+
+dn: cn=miners,ou=Groups,dc=example,dc=com
+objectClass: posixGroup
+cn: miners
+gidNumber: 5000
+
+dn: uid=john,ou=People,dc=example,dc=com
 objectClass: inetOrgPerson
 objectClass: posixAccount
 objectClass: shadowAccount
@@ -205,173 +438,99 @@
 givenName: John
 cn: John Doe
 displayName: John Doe
-uidNumber: 1000
-gidNumber: 10000
-userPassword: password
+uidNumber: 10000
+gidNumber: 5000
+userPassword: johnldap
 gecos: John Doe
 loginShell: /bin/bash
 homeDirectory: /home/john
-shadowExpire: -1
-shadowFlag: 0
-shadowWarning: 7
-shadowMin: 8
-shadowMax: 999999
-shadowLastChange: 10877
-mail: [e-mail]
-postalCode: 31000
-l: Toulouse
-o: Example
-mobile: +33 (0)6 xx xx xx xx
-homePhone: +33 (0)5 xx xx xx xx
-title: System Administrator
-postalAddress: 
-initials: JD
-
-dn: cn=example,ou=groups,dc=example,dc=com
-objectClass: posixGroup
-cn: example
-gidNumber: 10000
 </programlisting>
 
-	<para>
-	In this example the directory structure, a user, and a 
-	group have been setup. In other examples you might see the 
-	<emphasis>objectClass: top</emphasis> added in every entry, but that is the 
-	default behaviour so you do not have to add it explicitly.
-	</para>
-
-	<para>
-	Add the entries to the LDAP directory:
-	</para>
-
-
+	<note>
+		<para>
+		It's important that uid and gid values in your directory do not collide with local values.  Use high number ranges.
+		</para>
+	</note>
+
+	<para>
+	Add the content:
+	</para>
+	
 <screen>
-<command>sudo ldapadd -x -D cn=admin,dc=example,dc=com -W -f frontend.example.com.ldif</command>
+<command>ldapadd -x -D cn=admin,dc=example,dc=com -W -f add_content.ldif</command>
+<computeroutput>
+Enter LDAP Password: <application>********</application>
+adding new entry "ou=People,dc=example,dc=com"
+
+adding new entry "ou=Groups,dc=example,dc=com"
+
+adding new entry "cn=miners,ou=Groups,dc=example,dc=com"
+
+adding new entry "uid=john,ou=People,dc=example,dc=com"
+</computeroutput>
 </screen>
 
 	<para>
-	We can check that the content has been correctly added with the
-	<application>ldapsearch</application> utility. Execute a search of the LDAP directory:
+	We can check that the information has been correctly added with the <application>ldapsearch</application> utility:
 	</para>
 
 <screen>
-<command>ldapsearch -xLLL -b "dc=example,dc=com" uid=john sn givenName cn</command>
+<command>ldapsearch -x -LLL -b dc=example,dc=com 'uid=john' cn gidNumber</command>
 <computeroutput>
-dn: uid=john,ou=people,dc=example,dc=com
+dn: uid=john,ou=People,dc=example,dc=com
 cn: John Doe
-sn: Doe
-givenName: John
+gidNumber: 5000
 </computeroutput>
 </screen>
 
 	<para>
-	Just a quick explanation:
+	Explanation of switches:
 	</para>
 
 	<itemizedlist>
-	    <listitem>
-                <para>
-		<emphasis>-x:</emphasis> will not use SASL authentication 
-		method, which is the default.
-		</para>
-            </listitem>
-            <listitem>
-                <para>
-		<emphasis>-LLL:</emphasis> disable printing LDIF schema information.
-		</para>
-            </listitem>
+
+	<listitem>
+	<para>
+	<emphasis>-x:</emphasis> "simple" binding; will not use the default SASL method
+	</para>
+        </listitem>
+
+        <listitem>
+	<para>
+	<emphasis>-LLL:</emphasis> disable printing extraneous information
+	</para>
+        </listitem>
+
+	<listitem>
+	<para>
+	<emphasis>uid=john:</emphasis> a "filter" to find the john user
+	</para>
+        </listitem>
+
+	<listitem>
+	<para>
+	<emphasis>cn gidNumber:</emphasis> requests certain attributes to be displayed (the default is to show all attributes)
+	</para>
+        </listitem>
+	
         </itemizedlist>
 	
-	</sect2>
-        <sect2 id="openldap-configuration" status="review">
-          <title>Further Configuration</title>
-
-
-          <para>
-          The <emphasis>cn=config</emphasis> tree can be manipulated using the utilities in the 
-          <application>ldap-utils</application> package.  For example:
-          </para>
-
-          <itemizedlist>
-            <listitem>
-
-              <para>
-              Use <application>ldapsearch</application> to view the tree, entering the admin 
-              password set during installation or reconfiguration:
-              </para>
-
-<screen>
-<command>sudo ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn</command>
-</screen>
-
-<screen>
-<computeroutput>
-SASL/EXTERNAL authentication started
-SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
-SASL SSF: 0
-dn: cn=config
-
-dn: cn=module{0},cn=config
-
-dn: cn=schema,cn=config
-
-dn: cn={0}core,cn=schema,cn=config
-
-dn: cn={1}cosine,cn=schema,cn=config
-
-dn: cn={2}nis,cn=schema,cn=config
-
-dn: cn={3}inetorgperson,cn=schema,cn=config
-
-dn: olcDatabase={-1}frontend,cn=config
-
-dn: olcDatabase={0}config,cn=config
-
-dn: olcDatabase={1}hdb,cn=config
-</computeroutput>
-</screen>
-
-              <para>
-              The output above is the current configuration options for the <emphasis>cn=config</emphasis>
-              backend database.  Your output may be vary.  
-              </para>
-
-            </listitem>
-            <listitem>
-
-              <para>
-              As an example of modifying the <emphasis>cn=config</emphasis> tree, add another attribute 
-              to the index list using <application>ldapmodify</application>:
-              </para>
-
-<screen>
-<command>sudo ldapmodify -Y EXTERNAL -H ldapi:///</command>
-</screen>
-
-<screen>
-<computeroutput>
-SASL/EXTERNAL authentication started
-SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
-SASL SSF: 0
-<userinput>dn: olcDatabase={1}hdb,cn=config
-add: olcDbIndex
-olcDbIndex: uidNumber eq</userinput>
-
-modifying entry "olcDatabase={1}hdb,cn=config"
-</computeroutput>
-</screen>
-
-              <para>
-              Once the modification has completed, press <emphasis>Ctrl+D</emphasis> to exit the utility.
-              </para>
-
-            </listitem>
-            <listitem>
-
-              <para>
-              <application>ldapmodify</application> can also read the changes from a file.  Copy and paste
-              the following into a file named <filename>uid_index.ldif</filename>:              
-              </para>
+		</sect2>
+
+		<sect2 id="openldap-configuration" status="review">
+		<title>Modifying the slapd Configuration Database</title>
+
+	<para>
+       	The slapd-config DIT can also be queried and modified. Here are a few examples.
+	</para>
+
+       	<itemizedlist>
+
+	<listitem>
+	<para>
+	Use <application>ldapmodify</application> to add an "Index" (DbIndex attribute) to your <application>{1}hdb,cn=config</application>
+	database (dc=example,dc=com). Create a file, call it <filename>uid_index.ldif</filename>, with the following contents:              
+	</para>
 
 <programlisting>
 dn: olcDatabase={1}hdb,cn=config
@@ -379,44 +538,55 @@
 olcDbIndex: uid eq,pres,sub
 </programlisting>
 
-              <para>
-              Then execute <application>ldapmodify</application>:
-              </para> 
-
-<screen>
-<command>sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f uid_index.ldif</command>
-</screen>
-
-<screen>
+	<para>
+	Then issue the command:
+	</para>
+
+<screen>
+<command>sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f uid_index.ldif</command>
 <computeroutput>
-SASL/EXTERNAL authentication started
-SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
-SASL SSF: 0
 modifying entry "olcDatabase={1}hdb,cn=config"
 </computeroutput>
 </screen>
 
-              <para>
-              The file method is very useful for large changes.
-              </para>
-
-            </listitem>
-            <listitem>
-
-              <para>
-              Adding additional <emphasis>schemas</emphasis> to <application>slapd</application> requires the
-              schema to be converted to LDIF format.  The <filename role="directory">/etc/ldap/schema</filename>
-              directory contains some schema files already converted to LDIF format as demonstrated in the previous section.
-              Fortunately, the <application>slapd</application> program can be used to automate the conversion.  
-              The following example will add the <emphasis>dyngroup.schema</emphasis>:
-              </para>
-
-              <procedure>
-                <step>
-                  <para>                  
-                  First, create a conversion <filename>schema_convert.conf</filename> file containing the 
-                  following lines:
-                  </para>
+	<para>
+	You can confirm the change in this way:
+	</para>
+
+<screen>
+<command>sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcDatabase={1}hdb)' olcDbIndex</command>
+<computeroutput>
+dn: olcDatabase={1}hdb,cn=config
+olcDbIndex: objectClass eq
+olcDbIndex: uid eq,pres,sub
+</computeroutput>
+</screen>
+
+	</listitem>
+
+       	<listitem>
+	<para>
+	Let's add a schema. It will first need to be converted to LDIF format. You can find unconverted
+	schemas in addition to converted ones in the <filename role="directory">/etc/ldap/schema</filename> directory.
+	</para>
+
+	<note>
+	  	<para>
+		It is not trivial to remove a schema from the slapd-config database. Practice adding schemas on a test system.
+	  	</para>
+	</note>
+
+	<para>
+	In the following example we'll add the CORBA schema.
+	</para>
+
+	<procedure>
+
+	<step>
+		<para>                  
+		Create the conversion configuration file <filename>schema_convert.conf</filename> containing the 
+		following lines:
+		</para>
 
 <programlisting>
 include /etc/ldap/schema/core.schema
@@ -431,136 +601,229 @@
 include /etc/ldap/schema/nis.schema
 include /etc/ldap/schema/openldap.schema
 include /etc/ldap/schema/ppolicy.schema
+include /etc/ldap/schema/ldapns.schema
+include /etc/ldap/schema/pmi.schema
 </programlisting>
 
-                </step>
-                <step>
-
-                  <para>
-                  Next, create a temporary directory to hold the output:
-                  </para> 
-
-<screen>
-<command>mkdir /tmp/ldif_output</command>
-</screen>
-
-                </step>
-                <step>
-
-                  <para>
-                  Now using <application>slapcat</application> convert the schema files to LDIF:
-                  </para>
-
-<screen>
-<command>slapcat -f schema_convert.conf -F /tmp/ldif_output -n0 -s "cn={5}dyngroup,cn=schema,cn=config" > /tmp/cn=dyngroup.ldif</command>
-</screen>
-
-                  <para>
-                  Adjust the configuration file name and temporary directory names if yours are different.
-                  It may be worthwhile to keep the <filename>ldif_output</filename> directory around
-                  in case you want to add additional schemas in the future.
-                  </para>
-
-                  <note>
-                    <para>
-                    The <emphasis>"cn={5}"</emphasis> index number may change according to the configuration
-                    ordering.  To find out the correct number execute the following:
-                    </para>
-<screen>
-<command>slapcat -f schema_convert.conf -F /tmp/ldif_output -n 0 | grep dyngroup</command>
-</screen>
-                    <para>
-                    Replace <emphasis>dyngroup</emphasis> with the appropriate schema name.
-                    </para>
-                  </note>
-
-                </step>
-                <step>
-
-                  <para>
-                  Edit the <filename>/tmp/cn\=dyngroup.ldif</filename> file, changing the following attributes:
-                  </para> 
+	</step>
+
+	<step>
+		<para>
+		Create the output directory <filename>ldif_output</filename>.
+		</para> 
+	</step>
+
+	<step>
+		<para>
+		Determine the index of the schema:
+		</para> 
+
+<screen>
+<command>slapcat -f schema_convert.conf -F ldif_output -n 0 | grep corba,cn=schema</command>
+<computeroutput>
+cn={1}corba,cn=schema,cn=config
+</computeroutput>
+</screen>
+
+		<note>
+			<para>
+			When slapd injests objects with the same parent DN it will create an <emphasis>index</emphasis> for that object.
+			An index is contained within braces: <application>{X}</application>.
+			</para>
+		</note>
+
+	</step>
+
+	<step>
+		<para>
+		Use <application>slapcat</application> to perform the conversion:
+		</para>
+
+<screen>
+<command>slapcat -f schema_convert.conf -F ldif_output -n0 -H ldap:///cn={1}corba,cn=schema,cn=config -l cn=corba.ldif</command>
+</screen>
+
+		<para>
+		The converted schema is now in <filename>cn=corba.ldif</filename>
+		</para>
+	</step>
+
+	<step>
+		<para>
+		Edit <filename>cn=corba.ldif</filename> to arrive at the following attributes:
+		</para> 
 
 <programlisting>
-dn: cn=dyngroup,cn=schema,cn=config
+dn: cn=corba,cn=schema,cn=config
 ...
-cn: dyngroup
+cn: corba
 </programlisting>
 
-                  <para>
-                  And remove the following lines from the bottom of the file:
-                  </para> 
+		<para>
+		Also remove the following lines from the bottom:
+		</para> 
 
 <programlisting>
 structuralObjectClass: olcSchemaConfig
-entryUUID: 10dae0ea-0760-102d-80d3-f9366b7f7757
+entryUUID: 52109a02-66ab-1030-8be2-bbf166230478
 creatorsName: cn=config
-createTimestamp: 20080826021140Z
-entryCSN: 20080826021140.791425Z#000000#000#000000
+createTimestamp: 20110829165435Z
+entryCSN: 20110829165435.935248Z#000000#000#000000
 modifiersName: cn=config
-modifyTimestamp: 20080826021140Z
-</programlisting>
-
-                  <note>
-                    <para>
-                    The attribute values will vary, just be sure the attributes are removed.
-                    </para>
-                  </note>
-
-                </step>
-                <step>
-
-                  <para>
-                  Finally, using the <application>ldapadd</application> utility, add the new schema to the 
-                  directory:
-                  </para>
-
-<screen>
-<command>sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/cn\=dyngroup.ldif</command>
-</screen>
-
-                </step>
-              </procedure>
-
-              <para>
-              There should now be a <emphasis>dn: cn={4}dyngroup,cn=schema,cn=config</emphasis> entry in the cn=config tree.
-              </para> 
-
-            </listitem>
-          </itemizedlist>
-
-        </sect2>
-
-	<sect2 id="openldap-server-replication" status="review">
-		<title>LDAP Replication</title>
-
-	<para>
-	LDAP often quickly becomes a highly critical service to the network.  Multiple systems 
-        will come to depend on LDAP for authentication, authorization, configuration, etc. It is a good idea to 
-        setup a redundant system through replication. 
+modifyTimestamp: 20110829165435Z
+</programlisting>
+
+		<para>
+		Your attribute values will vary.
+		</para>
+	</step>
+
+	<step>
+		<para>
+		Finally, use <application>ldapadd</application> to add the new schema to the slapd-config DIT:
+		</para>
+
+<screen>
+<command>sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f cn\=corba.ldif</command>
+<computeroutput>
+adding new entry "cn=corba,cn=schema,cn=config"
+</computeroutput>
+</screen>
+
+	</step>
+
+	<step>
+		<para>
+		Confirm currently loaded schemas:
+		</para> 
+
+<screen>
+<command>sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn</command>
+<computeroutput>
+dn: cn=schema,cn=config
+
+dn: cn={0}core,cn=schema,cn=config
+
+dn: cn={1}cosine,cn=schema,cn=config
+
+dn: cn={2}nis,cn=schema,cn=config
+
+dn: cn={3}inetorgperson,cn=schema,cn=config
+
+dn: cn={4}corba,cn=schema,cn=config
+</computeroutput>
+</screen>
+
+	</step>
+
+	</procedure>
+
+	</listitem>
+
+       	</itemizedlist>
+
+	<note>
+	  	<para>
+	  	For external applications and clients to authenticate using LDAP they will each need to be specifically
+		configured to do so.  Refer to the appropriate client-side documentation for details.	 
+	  	</para>
+	</note>
+
+		</sect2>
+
+		<sect2 id="openldap-server-logging" status="review">
+		<title>Logging</title>
+
+	<para>
+	Activity logging for slapd is indispensible when implementing an OpenLDAP-based solution yet it must be manually enabled after
+	software installation. Otherwise, only rudimentary messages will appear in the logs. Logging, like any other slapd configuration,
+	is enabled via the slapd-config database.
+	</para>
+
+	<para>
+	OpenLDAP comes with multiple logging subsystems (levels) with each one containing the lower one (additive). A good level to
+	try is <emphasis>stats</emphasis>. The <ulink url="http://manpages.ubuntu.com/manpages/en/man5/slapd-config.5.html">slapd-config</ulink>
+	man page has more to say on the different subsystems.
+	</para>
+
+	<para>
+	Create the file <filename>logging.ldif</filename> with the following contents:
+	</para>
+
+<programlisting>
+dn: cn=config
+changetype: modify
+add: olcLogLevel
+olcLogLevel: stats
+</programlisting>
+
+	<para>
+	Implement the change:
+	</para>
+
+<screen>
+<command>sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f logging.ldif</command>
+</screen>
+
+	<para>
+	This will produce a significant amount of logging and you will want to throttle back to a less verbose level once your system
+	is in production. While in this verbose mode your host's syslog engine (rsyslog) may have a hard time keeping up and may drop
+	messages:
+	</para>
+
+<programlisting>
+rsyslogd-2177: imuxsock lost 228 messages from pid 2547 due to rate-limiting
+</programlisting>
+
+	<para>
+	You may consider a change to rsyslog's configuration. In <filename>/etc/rsyslog.conf</filename>, put:
+	</para>
+
+<programlisting>
+# Disable rate limiting (default is 200 messages in 5 seconds; below we make the 5 become 0)
+$SystemLogRateLimitInterval 0
+</programlisting>
+
+	<para>
+	And then restart the rsyslog daemon:
+	</para>
+
+<screen>
+<command>sudo service rsyslog restart</command>
+</screen>
+
+		</sect2>
+
+		<sect2 id="openldap-server-replication" status="review">
+		<title>Replication</title>
+
+	<para>
+	The LDAP service becomes increasingly important as more networked systems begin to depend on it. In such an environment,
+	it is standard practice to build redundancy (high availability) into LDAP to prevent havoc should the LDAP server become
+	unresponsive. This is done through <emphasis>LDAP replication</emphasis>. 
 	</para>
 	
 	<para>
-	Replication is achieved using the <emphasis>Syncrepl</emphasis> engine. Syncrepl allows the
-	changes to be synced using a <emphasis>consumer</emphasis>, <emphasis>provider</emphasis> model.
-        A provider sends directory changes to consumers.
-	</para>
-
-    <sect3 id="openldap-provider-configuration" status="review">
-      <title>Provider Configuration</title>
-
-  	  <para>
-	  The following is an example of a <emphasis>Single-Master</emphasis> configuration.  In this configuration one
-      OpenLDAP server is configured as a <emphasis>provider</emphasis> and another as a <emphasis>consumer</emphasis>. 
-	  </para>
+	Replication is achieved via the <emphasis>Syncrepl</emphasis> engine. This allows changes to be synchronized using a
+	<emphasis>Consumer</emphasis> - <emphasis>Provider</emphasis> model. The specific kind of replication we will implement
+	in this guide is a combination of the following modes: <emphasis>refreshAndPersist</emphasis> and <emphasis>delta-syncrepl</emphasis>.
+	This has the Provider push changed entries to the Consumer as soon as they're made but, in addition, only actual changes will
+	be sent, not entire entries.
+	</para>
+
+			<sect3 id="openldap-provider-configuration" status="review">
+			<title>Provider Configuration</title>
+
+	<para>
+	Begin by configuring the <emphasis>Provider</emphasis>.
+	</para>
 
         <procedure>
-          <step>
-  
-            <para>
-            First, configure the provider server.  Copy the following to a 
-            file named <filename>provider_sync.ldif</filename>:
-            </para>
+
+	<step>
+		<para>
+		Create an LDIF file with the following contents and name it <filename>provider_sync.ldif</filename>:
+		</para>
 
 <programlisting>
 # Add indexes to the frontend db.
@@ -621,175 +884,83 @@
 olcAccessLogPurge: 07+00:00 01+00:00
 </programlisting>
           
-          </step>
-          <step>
-
-            <para>
-            The <application>AppArmor</application> profile for <application>slapd</application> will need to be adjusted for the 
-            accesslog database location.  Edit <filename>/etc/apparmor.d/usr.sbin.slapd</filename> adding:
-            </para>
+	<para>
+	Change the rootDN in the LDIF file to match the one you have for your directory.
+	</para>
+
+        </step>
+
+        <step>
+		<para>
+		The <application>apparmor</application> profile for slapd will need to be adjusted for the 
+		accesslog database location. Edit <filename>/etc/apparmor.d/local/usr.sbin.slapd</filename> by
+		adding the following:
+		</para>
 
 <programlisting>
-  /var/lib/ldap/accesslog/ r,
-  /var/lib/ldap/accesslog/** rwk,
+/var/lib/ldap/accesslog/ r,
+/var/lib/ldap/accesslog/** rwk,
 </programlisting>
 
-            <para>
-            Then create the directory, reload the <application>apparmor</application> profile, and copy 
-            the <filename>DB_CONFIG</filename> file:
-            </para>
+		<para>
+		Create a directory, set up a databse config file, and reload the apparmor profile:
+		</para>
 
 <screen>
 <command>sudo -u openldap mkdir /var/lib/ldap/accesslog</command>
-<command>sudo -u openldap cp /var/lib/ldap/DB_CONFIG /var/lib/ldap/accesslog/</command>
-<command>sudo /etc/init.d/apparmor reload</command>
-</screen>
-
-            <note>
-              <para>
-              Using the <emphasis>-u openldap</emphasis> option with the <application>sudo</application> commands above
-              removes the need to adjust permissions for the new directory later.
-              </para>
-            </note>
-
-          </step>
-          <step>
-
-            <para>
-            Edit the file and change the <emphasis>olcRootDN</emphasis> to match your directory:
-            </para>
-
-<programlisting>
-olcRootDN: cn=admin,dc=example,dc=com
-</programlisting>
-
-          </step>
-          <step>
-
-
-            <para>
-            Next, add the LDIF file using the <application>ldapadd</application> utility:
-            </para>
-
-<screen>
-<command>sudo ldapadd -Y EXTERNAL -H ldapi:/// -f provider_sync.ldif</command>
-</screen>
-
-          </step>
-          <step>
-
-
-            <para>
-            Restart <application>slapd</application>:
-            </para>
-
-<screen>
-<command>sudo /etc/init.d/slapd restart</command>
-</screen>
-
-          </step>
+<command>sudo -u openldap cp /var/lib/ldap/DB_CONFIG /var/lib/ldap/accesslog</command>
+<command>sudo service apparmor reload</command>
+</screen>
+
+	</step>
+
+	<step>
+		<para>
+		Add the new content and, due to the apparmor change, restart the daemon:
+		</para>
+
+<screen>
+<command>sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f provider_sync.ldif</command>
+<command>sudo service slapd restart</command>
+</screen>
+
+	</step>
+
         </procedure>
 
         <para>
-        The <emphasis>Provider</emphasis> server is now configured, and it is time to configure a <emphasis>Consumer</emphasis>
-        server. 
+        The Provider is now configured.
         </para>
 
-      </sect3>
-      <sect3 id="openldap-consumer-configuration" status="review">
-        <title>Consumer Configuration</title>
+			</sect3>
+
+			<sect3 id="openldap-consumer-configuration" status="review">
+			<title>Consumer Configuration</title>
+
+	<para>
+	And now configure the <emphasis>Consumer</emphasis>.
+	</para>
 
         <procedure>
-          <step>
-
-            <para>
-            On the <emphasis>Consumer</emphasis> server configure it the same as the <emphasis>Provider</emphasis> except for the 
-            <emphasis>Syncrepl</emphasis> configuration steps.
-            </para>
-
-            <para>
-            Add the additional schema files:
-            </para>
-
-<screen>
-<command>sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif</command>
-<command>sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif</command>
-<command>sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/inetorgperson.ldif</command>
-</screen>
-
-            <para>
-            Also, create, or copy from the provider server, the <filename>backend.example.com.ldif</filename>
-            </para>
-
-<programlisting>
-# Load dynamic backend modules
-dn: cn=module,cn=config
-objectClass: olcModuleList
-cn: module
-olcModulepath: /usr/lib/ldap
-olcModuleload: back_hdb.la
-
-# Database settings
-dn: olcDatabase=hdb,cn=config
-objectClass: olcDatabaseConfig
-objectClass: olcHdbConfig
-olcDatabase: {1}hdb
-olcSuffix: dc=example,dc=com
-olcDbDirectory: /var/lib/ldap
-olcRootDN: cn=admin,dc=example,dc=com
-olcRootPW: secret
-olcDbConfig: set_cachesize 0 2097152 0
-olcDbConfig: set_lk_max_objects 1500
-olcDbConfig: set_lk_max_locks 1500
-olcDbConfig: set_lk_max_lockers 1500
-olcDbIndex: objectClass eq
-olcLastMod: TRUE
-olcDbCheckpoint: 512 30
-olcAccess: to attrs=userPassword by dn="cn=admin,dc=example,dc=com" write by anonymous auth by self write by * none
-olcAccess: to attrs=shadowLastChange by self write by * read
-olcAccess: to dn.base="" by * read
-olcAccess: to * by dn="cn=admin,dc=example,dc=com" write by * read
-</programlisting>
-
-            <para>
-            And add the LDIF by entering:
-            </para>
-
-<screen>
-<command>sudo ldapadd -Y EXTERNAL -H ldapi:/// -f backend.example.com.ldif</command>
-</screen>
-
-          </step>
-          <step>
-
-            <para>
-            Do the same with the <filename>frontend.example.com.ldif</filename> file listed above, and add it:
-            </para>
-
-<screen>
-<command>sudo ldapadd -x -D cn=admin,dc=example,dc=com -W -f frontend.example.com.ldif</command>
-</screen>
-
-            <para>
-            The two severs should now have the same configuration except for the <emphasis>Syncrepl</emphasis>
-            options.
-            </para>
-
-          </step>
-          <step>
-
-            <para>
-            Now create a file named <filename>consumer_sync.ldif</filename> containing:
-            </para>
-
-<programlisting>
-#Load the syncprov module.
+
+	<step>
+		<para>
+		Install the software by going through <xref linkend="openldap-server-installation"/>. Make sure the slapd-config
+		databse is identical to the Provider's. In particular, make sure schemas and the databse suffix are the same.
+		</para>
+	</step>
+
+	<step>
+		<para>
+		Create an LDIF file with the following contents and name it <filename>consumer_sync.ldif</filename>:
+		</para>
+
+<programlisting>
 dn: cn=module{0},cn=config
 changetype: modify
 add: olcModuleLoad
 olcModuleLoad: syncprov
 
-# syncrepl specific indices
 dn: olcDatabase={1}hdb,cn=config
 changetype: modify
 add: olcDbIndex
@@ -805,130 +976,281 @@
 olcUpdateRef: ldap://ldap01.example.com
 </programlisting>
 
-            <para>
-            You will probably want to change the following attributes:
-            </para>
-
-            <itemizedlist>
-              <listitem><para><emphasis>ldap01.example.com</emphasis> to your server's hostname.</para></listitem>
-              <listitem><para><emphasis>binddn</emphasis></para></listitem>
-              <listitem><para><emphasis>credentials</emphasis></para></listitem>
-              <listitem><para><emphasis>searchbase</emphasis></para></listitem>
-              <listitem><para><emphasis>olcUpdateRef:</emphasis></para></listitem>
-            </itemizedlist>
-
-          </step>
-          <step>
-
-            <para>
-            Add the LDIF file to the configuration tree:
-            </para>
+	<para>
+	Ensure the following attributes have the correct values:
+	</para>
+
+	<itemizedlist>
+	<listitem><para><emphasis>ldap01.example.com</emphasis> (Provider server's hostname or IP address)</para></listitem>
+	<listitem><para><emphasis>binddn</emphasis> (the admin DN you're using)</para></listitem>
+	<listitem><para><emphasis>credentials</emphasis> (the admin DN password you're using)</para></listitem>
+	<listitem><para><emphasis>searchbase</emphasis> (the database suffix you're using)</para></listitem>
+	<listitem><para><emphasis>olcUpdateRef:</emphasis> (Provider server's hostname or IP address)</para></listitem>
+	</itemizedlist>
+
+        </step>
+
+	<step>
+
+	<para>
+	Add the new content:
+	</para>
 
 <screen>
-<command>sudo ldapadd -c -Y EXTERNAL -H ldapi:/// -f consumer_sync.ldif</command>
+<command>sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f consumer_sync.ldif</command>
 </screen>
 
-          </step>
+	</step>
+
         </procedure>
 
         <para>
-        The frontend database should now sync between servers.  You can add additional servers using the 
-        steps above as the need arises. 
+        You're done. The two databases (suffix: dc=example,dc=com) should now be synchronizing.
         </para>
 
-        <note>
-  	  <para>
-          The <application>slapd</application> daemon will send log information to <filename>/var/log/syslog</filename>
-          by default.  So if all does <emphasis>not</emphasis> go well check there for errors and other troubleshooting information.
-          Also, be sure that each server knows it's Fully Qualified Domain Name (FQDN).  This is configured in <filename>/etc/hosts</filename>
-          with a line similar to: <programlisting>127.0.0.1	ldap01.example.com ldap01</programlisting>.
-          </para>
-        </note>
-
-      </sect3>
-	</sect2>
-
-	<sect2 id="openldap-server-acl" status="review">
-              <title>Setting up ACL</title>
-
-	<para>
-	Authentication requires access to the password field, that should be not
-	accessible by default. Also, in order for users to change their own password,
-	using <command>passwd</command> or other utilities, <emphasis>shadowLastChange</emphasis> 
-        needs to be accessible once a user has authenticated.  
-	</para>
+	<para>
+	To test if it worked simply query, on the Consumer, the DNs in the database:
+	</para>
+
+<screen>
+<command>sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com dn</command>
+</screen>
+
+	<para>
+	You should see the user 'john' and the group 'miners' as well as the nodes 'People' and 'Groups'.
+	</para>
+
+			</sect3>
+
+		</sect2>
+
+		<sect2 id="openldap-server-acl" status="review">
+		<title>Access Control</title>
+
+	<para>
+	The management of what type of access (read, write, etc) users should be granted to resources is known as
+	<emphasis>access control</emphasis>. The configuration directives involved are called <emphasis>access control lists</emphasis> or ACL.
+	</para>
+
+	<para>
+	When we installed the slapd package various ACL were set up automatically. We will look at a few important consequences of those
+	defaults and, in so doing, we'll get an idea of how ACLs work and how they're configured.
+	</para>
+
+	<para>
+	To get the effective ACL for an LDAP query we need to look at the ACL entries of the database being queried as well as those of the
+	special frontend database instance. The ACLs belonging to the latter act as defaults in case those of the former do not match. The
+	frontend database is the second to be consulted and the ACL to be applied is the first to match ("first match wins") among these 2
+	ACL sources. The following commands will give, respectively, the ACLs of the hdb database ("dc=example,dc=com") and those of the
+	frontend database:
+	</para>
+
+<screen>
+<command>sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcDatabase={1}hdb)' olcAccess</command>
+<computeroutput>
+dn: olcDatabase={1}hdb,cn=config
+olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * none
+olcAccess: {1}to dn.base="" by * read
+olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=com" write by *
+  read
+</computeroutput>
+</screen>
+
+	<note>
+	  	<para>
+		The rootDN always has full rights to it's database. Including it in an ACL does provide an explicit configuration but it also causes
+		slapd to incure a performance penalty.
+	  	</para>
+	</note>
+
+<screen>
+<command>sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcDatabase={-1}frontend)' olcAccess</command>
+<computeroutput>
+dn: olcDatabase={-1}frontend,cn=config
+olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
+olcAccess: {1}to dn.exact="" by * read
+olcAccess: {2}to dn.base="cn=Subschema" by * read
+</computeroutput>
+</screen>
+
+	<para>
+	The very first ACL is crucial:
+	</para>
+
+<programlisting>
+olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * none
+</programlisting>
+
+	<para>
+	This can be represented differently for easier digestion:
+	</para>
+
+<programlisting>
+to attrs=userPassword
+	by self write
+	by anonymous auth
+	by dn="cn=admin,dc=example,dc=com" write
+	by * none
+
+to attrs=shadowLastChange
+	by self write
+	by anonymous auth
+	by dn="cn=admin,dc=example,dc=com" write
+	by * none
+</programlisting>
+
+	<para>
+	This compound ACL (there are 2) enforces the following:
+	</para>
+
+	<itemizedlist>
+
+	<listitem>
+	<para>
+	Anonymous 'auth' access is provided to the <emphasis>userPassword</emphasis> attribute for the initial connection to
+	occur. Perhaps counter-intuitively, 'by anonymous auth' is needed even when anonymous access to the DIT is
+	unwanted. Once the remote end is connected, howerver, authentication can occur (see next point).
+	</para>
+	</listitem>
+
+	<listitem>
+	<para>
+	Authentication can happen because all users have 'read' (due to 'by self write') access to the <emphasis>userPassword</emphasis> attribute.
+	</para>
+	</listitem>
+
+	<listitem>
+	<para>
+	The <emphasis>userPassword</emphasis> attribute is otherwise unaccessible by all other users, with the exception of the rootDN, who
+	has complete access to it.
+	</para>
+	</listitem>
+
+	<listitem>
+	<para>
+	In order for users to change their own password, using <command>passwd</command> or other utilities, the
+	<emphasis>shadowLastChange</emphasis> attribute needs to be accessible once a user has authenticated. 
+	</para>
+	</listitem>
+
+	</itemizedlist>
+
+	<para>
+	This DIT can be searched anonymously because of 'by * read' in this ACL:
+	</para>
+
+<programlisting>
+to *
+	by self write
+	by dn="cn=admin,dc=example,dc=com" write
+	by * read
+</programlisting>
+
+	<para>
+	If this is unwanted then you need to change the ACLs. To force authentication during a bind request you can alternatively (or
+	in combination with the modified ACL) use the 'olcRequire: authc' directive.
+	</para>
+
+	<para>
+	As previously mentioned, there is no administrative account created for the slapd-config database. There is, however, a SASL
+	identity that is granted full access to it. It represents the localhost's superuser (root/sudo). Here it is:
+	</para>
+
+<programlisting>
+dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth 
+</programlisting>
 
         <para>
-        To view the Access Control List (ACL) for the <emphasis>cn=config</emphasis> tree, use the 
-        <application>ldapsearch</application> utility:
+        The following command will display the ACLs of the slapd-config database:
         </para>
 
 <screen>
-<command>sudo ldapsearch -c -Y EXTERNAL -H ldapi:///  -LLL -b cn=config olcDatabase=config olcAccess</command>
-</screen>
-
-<screen>
-<computeroutput>SASL/EXTERNAL authentication started
-SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
-SASL SSF: 0
+<command>sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcDatabase={0}config)' olcAccess</command>
+<computeroutput>
 dn: olcDatabase={0}config,cn=config
-olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
- ,cn=auth manage by * break
+olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
 </computeroutput>
 </screen>
 
-      <para>
-      To see the ACL for the frontend tree enter:
-      </para>
-
-<screen>
-<command>sudo ldapsearch -c -Y EXTERNAL -H ldapi:///  -LLL -b cn=config olcDatabase={1}hdb olcAccess</command>
-</screen>
-
-	</sect2>
-
-        <sect2 id="openldap-tls" status="review">
-          <title>TLS and SSL</title>
-
-          <para>
-          When authenticating to an OpenLDAP server it is best to do so using an encrypted session.  This can be accomplished using Transport
-          Layer Security (TLS) and/or Secure Sockets Layer (SSL).
-          </para>
-
-          <para>
-          The first step in the process is to obtain or create a <emphasis>certificate</emphasis>.  Because <application>slapd</application> 
-          is compiled using the <application>gnutls</application> library, the <application>certtool</application> utility will be 
-          used to create certificates.
-          </para>
+        <para>
+	Since this is a SASL identity we need to use a SASL <emphasis>mechanism</emphasis> when invoking the LDAP utility in question and
+	and we have seen it plenty of times in this guide. It is the EXTERNAL mechanism. See the previous command for an example. Note that:
+	</para>
         
-          <procedure>
-            <step>
-
-              <para>
-              First, install <application>gnutls-bin</application> by entering the following in a terminal:
-              </para>
-
-<screen>
-<command>sudo apt-get install gnutls-bin</command>
-</screen>
-
-            </step>
-            <step>
-
-              <para>
-              Next, create a private key for the <emphasis>Certificate Authority</emphasis> (CA):
-              </para>
+	<procedure>
+
+	<step>
+		<para>
+		You must use <emphasis>sudo</emphasis> to become the root identity in order for the ACL to match.
+		</para>
+	</step>
+
+	<step>
+		<para>
+		The EXTERNAL mechanism works via <emphasis>IPC</emphasis> (UNIX domain sockets). This means you must use the <emphasis>ldapi</emphasis>
+		URI format.
+		</para>
+	</step>
+
+	</procedure>
+
+        <para>
+	A succinct way to get all the ACLs is like this:
+        </para>
+
+<screen>
+<command>sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcAccess=*)' olcAccess olcSuffix</command>
+</screen>
+
+        <para>
+        There is much to say on the topic of access control. See the man page for
+	<ulink url="http://manpages.ubuntu.com/manpages/en/man5/slapd.access.5.html">slapd.access</ulink>.
+        </para>
+
+		</sect2>
+
+		<sect2 id="openldap-tls" status="review">
+		<title>TLS</title>
+
+	<para>
+	When authenticating to an OpenLDAP server it is best to do so using an encrypted session. This can be accomplished using Transport
+	Layer Security (TLS).
+	</para>
+
+	<para>
+	Here, we will be our own <emphasis>Certificate Authority</emphasis> and then create and sign our LDAP server certificate as that CA.
+	Since <application>slapd</application> is compiled using the <application>gnutls</application> library, we will use the
+	<application>certtool</application> utility to complete these tasks.
+	</para>
+
+	<procedure>
+
+	<step>
+		<para>
+		Install the <application>gnutls-bin</application> and <application>gnutls-bin</application> packages:
+		</para>
+
+<screen>
+<command>sudo apt-get install gnutls-bin ssl-cert</command>
+</screen>
+
+	</step>
+
+	<step>
+		<para>
+		Create a private key for the Certificate Authority:
+		</para>
 
 <screen>
 <command>sudo sh -c "certtool --generate-privkey > /etc/ssl/private/cakey.pem"</command>
 </screen>
 
-            </step>
-            <step>
+	</step>
 
-              <para>
-              Create a <filename>/etc/ssl/ca.info</filename> details file to self-sign the CA certificate containing:
-              </para>
+       	<step>
+		<para>
+		Create the template/file <filename>/etc/ssl/ca.info</filename> to define the CA:
+		</para>
 
 <programlisting>
 cn = Example Company
@@ -936,42 +1258,46 @@
 cert_signing_key
 </programlisting>
 
-            </step>
-            <step>
-
-              <para>
-              Now create the self-signed CA certificate:
-              </para>
-
-<screen>
-<command>sudo certtool --generate-self-signed --load-privkey /etc/ssl/private/cakey.pem \ 
- --template  /etc/ssl/ca.info --outfile /etc/ssl/certs/cacert.pem</command>
-</screen>
-
-            </step>
-            <step>
-
-              <para>
-              Make a private key for the server:
-              </para>
-
-<screen>
-<command>sudo sh -c "certtool --generate-privkey > /etc/ssl/private/ldap01_slapd_key.pem"</command>
-</screen>
-
-              <note>
-                <para>
-                Replace <emphasis>ldap01</emphasis> in the filename with your server's hostname.  Naming the certificate and key for the host
-                and service that will be using them will help keep filenames and paths straight.
-                </para>
-              </note>
-
-            </step>
-            <step>
-
-              <para>
-              To sign the server's certificate with the CA, create the <filename>/etc/ssl/ldap01.info</filename> info file containing:
-              </para>
+	</step>
+
+       	<step>
+		<para>
+		Create the self-signed CA certificate:
+		</para>
+
+<screen>
+<command>sudo certtool --generate-self-signed \
+--load-privkey /etc/ssl/private/cakey.pem \ 
+--template /etc/ssl/ca.info \
+--outfile /etc/ssl/certs/cacert.pem</command>
+</screen>
+
+	</step>
+
+       	<step>
+		<para>
+		Make a private key for the server:
+		</para>
+
+<screen>
+<command>sudo certtool --generate-privkey \
+--bits 1024 \
+--outfile /etc/ssl/private/ldap01_slapd_key.pem</command>
+</screen>
+
+		<note>
+			<para>
+			Replace <emphasis>ldap01</emphasis> in the filename with your server's hostname. Naming the certificate and
+			key for the host and service that will be using them will help keep things clear.
+			</para>
+		</note>
+
+	</step>
+
+	<step>
+		<para>
+		Create the <filename>/etc/ssl/ldap01.info</filename> info file containing:
+		</para>
 
 <programlisting>
 organization = Example Company
@@ -979,36 +1305,38 @@
 tls_www_server
 encryption_key
 signing_key
+expiration_days = 3650
 </programlisting>
 
-            </step>
-            <step>
-
-              <para>
-              Create the server's certificate:
-              </para>
-
-<screen>
-<command>sudo certtool --generate-certificate --load-privkey /etc/ssl/private/ldap01_slapd_key.pem \
- --load-ca-certificate /etc/ssl/certs/cacert.pem --load-ca-privkey /etc/ssl/private/cakey.pem \
- --template /etc/ssl/ldap01.info --outfile /etc/ssl/certs/ldap01_slapd_cert.pem</command>
-</screen>
-
-            </step>
-          </procedure>
-
-          <para>
-          Once you have a certificate, key, and CA cert installed, use <application>ldapmodify</application> to add the new 
-          configuration options:
-          </para>
-
-<screen>
-<command>sudo ldapmodify -Y EXTERNAL -H ldapi:///</command>
-</screen>
-
-<screen>
-<computeroutput>Enter LDAP Password:
-<userinput>dn: cn=config
+		<para>
+		The above certificate is good for 10 years. Adjust accordingly.
+		</para>
+	</step>
+
+	<step>
+		<para>
+		Create the server's certificate:
+		</para>
+
+<screen>
+<command>sudo certtool --generate-certificate \
+--load-privkey /etc/ssl/private/ldap01_slapd_key.pem \
+--load-ca-certificate /etc/ssl/certs/cacert.pem \
+--load-ca-privkey /etc/ssl/private/cakey.pem \
+--template /etc/ssl/ldap01.info \
+--outfile /etc/ssl/certs/ldap01_slapd_cert.pem</command>
+</screen>
+
+	</step>
+
+	</procedure>
+
+	<para>
+	Create the file <filename>certinfo.ldif</filename> with the following contents (adjust accordingly):
+	</para>
+
+<programlisting>
+dn: cn=config
 add: olcTLSCACertificateFile
 olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
 -
@@ -1016,170 +1344,171 @@
 olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem
 -
 add: olcTLSCertificateKeyFile
-olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem</userinput>
-
-modifying entry "cn=config"
-</computeroutput>
+olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem
+</programlisting>
+
+        <para>
+	Use the <application>ldapmodify</application> command to tell slapd about our TLS work via the slapd-config database:
+        </para>
+
+<screen>
+<command>sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ssl/certinfo.ldif</command>
 </screen>
-
-          <note>
-            <para>
-            Adjust the <filename>ldap01_slapd_cert.pem</filename>, <filename>ldap01_slapd_key.pem</filename>, and 
-            <filename>cacert.pem</filename> names if yours are different. 
-            </para>
-          </note>
-
-          <para>
-          Next, edit <filename>/etc/default/slapd</filename> uncomment the <emphasis>SLAPD_SERVICES</emphasis> option:
-          </para>
+	
+        <para>
+        Contratry to popular belief, you do not need <emphasis>ldaps://</emphasis> in <filename>/etc/default/slapd</filename>
+	in order to use encryption. You should have just:
+        </para>
 
 <programlisting>
-SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"
+SLAPD_SERVICES="ldap:/// ldapi:///"
 </programlisting>
 
-          <para>
-          Now the <emphasis>openldap</emphasis> user needs access to the certificate:
-          </para>
+	<note>
+		<para>
+		LDAP over TLS/SSL (ldaps://) is deprecated in favour of <emphasis>StartTLS</emphasis>. The latter refers to an
+		existing LDAP session (listening on TCP port 389) becoming protected by TLS/SSL whereas LDAPS, like HTTPS, is a
+		distinct encrypted-from-the-start protocol that operates over TCP port 636.
+		</para>
+	</note>
+
+
+	<para>
+	Tighten up ownership and permissions:
+	</para>
 
 <screen>
 <command>sudo adduser openldap ssl-cert</command>
 <command>sudo chgrp ssl-cert /etc/ssl/private/ldap01_slapd_key.pem</command>
 <command>sudo chmod g+r /etc/ssl/private/ldap01_slapd_key.pem</command>
+<command>sudo chmod o-r /etc/ssl/private/ldap01_slapd_key.pem</command>
 </screen>
 
-          <note>
-            <para>
-            If the <filename role="directory">/etc/ssl/private</filename> and <filename>/etc/ssl/private/server.key</filename> have
-            different permissions, adjust the commands appropriately.
-            </para>
-          </note>
-
-          <para>
-          Finally, restart <application>slapd</application>:
-          </para>
+	<para>
+	Restart OpenLDAP:
+	</para>
 
 <screen>
-<command>sudo /etc/init.d/slapd restart</command>
+<command>sudo service slapd restart</command>
 </screen>
 
-          <para>
-          The <application>slapd</application> daemon should now be listening for LDAPS connections and be able to use STARTTLS during
-          authentication.
-          </para>
-
-	  <note>
-	    <para>If you run into troubles with the server not starting,
-	      check the /var/log/syslog. If you see errors like 
-	      main: TLS init def ctx failed: -1,
-	      it is likely there is a configuration problem.
-	      Check that the certificate is signed by the authority from 
-	      in the files configured, and that the ssl-cert group
-	      has read permissions on the private key.
-	    </para>
-	  </note>
-
-
-          <sect3 id="openldap-tls-replication" status="review">
-            <title>TLS Replication</title>
-
-            <para>
-            If you have setup <application>Syncrepl</application> between servers, it is prudent to encrypt the replication traffic 
-            using <emphasis>Transport Layer Security (TLS)</emphasis>.  For details on setting up replication see 
-            <xref linkend="openldap-server-replication"/>.
-            </para>
-
-            <para>
-            Assuming you have followed the above instructions and created a CA certificate and server certificate on the 
-            <emphasis>Provider</emphasis> server.  Follow the following instructions to create a certificate and key for the 
-            <emphasis>Consumer</emphasis> server.
-            </para>
-
-            <procedure>
-              <step>
-
-                <para>
-                Create a new key for the Consumer server:
+	<para>
+	Check your host's logs (/var/log/syslog) to see if the server has started properly.
+	</para>
+
+		</sect2>
+
+		<sect2 id="openldap-tls-replication" status="review">
+		<title>Replication and TLS</title>
+
+	<para>
+	If you have set up replication between servers, it is common practice to encrypt (StartTLS) the replication traffic to prevent
+	evesdropping. This is distinct from using encryption with authentication as we did above. In this section we will build on that
+	TLS-authentication work.
+	</para>
+
+	<para>
+	The assumption here is that you have set up replication between Provider and Consumer according to <xref linkend="openldap-server-replication"/>
+	and have configured TLS for authentication on the Provider by following <xref linkend="openldap-tls"/>.
+	</para>
+
+	<para>
+	As previously stated, the objective (for us) with replication is high availablity for the LDAP service. Since we have TLS for
+	authentication on the Provider we will require the same on the Consumer. In addition to this, however, we want to encrypt
+	replication traffic. What remains to be done is to create a key and certificate for the Consumer and then configure accordingly.
+	We will generate the key/certificate on the Provider, to avoid having to create another CA certificate, and then transfer the
+	necessary material over to the Consumer.
+	</para>
+
+	<procedure>
+
+	<step>
+                <para>
+                On the Provider,
+                </para>
+
+                <para>
+		Create a holding directory (which will be used for the eventual transfer) and then the Consumer's private key:
                 </para>
 
 <screen>
 <command>mkdir ldap02-ssl</command>
 <command>cd ldap02-ssl</command>
-<command>certtool --generate-privkey > ldap02_slapd_key.pem</command>
+<command>sudo certtool --generate-privkey \
+--bits 1024 \
+--outfile ldap02_slapd_key.pem</command>
 </screen>
 
-                <note>
-                  <para>
-                  Creating a new directory is not strictly necessary, but it will help keep things organized and make it easier to copy the 
-                  files to the Consumer server.
-                  </para>
-                </note>
-            
-              </step>
-              <step>       
-
                 <para>
-                Next, create an info file, <filename>ldap02.info</filename> for the Consumer server, changing the attributes to match your 
-                locality and server:
+                Create an info file, <filename>ldap02.info</filename>, for the Consumer server, adjusting it's values accordingly:
                 </para>  
 
 <programlisting>
-country = US
-state = North Carolina
-locality = Winston-Salem
 organization = Example Company
-cn = ldap02.salem.edu
-tls_www_client
+cn = ldap02.example.com
+tls_www_server
 encryption_key
 signing_key
+expiration_days = 3650
 </programlisting>
 
-              </step>
-              <step>  
-
                 <para>
-                Create the certificate:
+                Create the Consumer's certificate:
                 </para>
 
 <screen>
-<command>sudo certtool --generate-certificate --load-privkey ldap02_slapd_key.pem \
- --load-ca-certificate /etc/ssl/certs/cacert.pem --load-ca-privkey /etc/ssl/private/cakey.pem \
- --template ldap02.info --outfile ldap02_slapd_cert.pem</command>
+<command>sudo certtool --generate-certificate \
+--load-privkey ldap02_slapd_key.pem \
+--load-ca-certificate /etc/ssl/certs/cacert.pem \
+--load-ca-privkey /etc/ssl/private/cakey.pem \
+--template ldap02.info \
+--outfile ldap02_slapd_cert.pem</command>
 </screen>
 
-              </step>
-              <step>
-
                 <para>
-                Copy the <filename>cacert.pem</filename> to the directory:
+                Get a copy of the CA certificate:
                 </para>
 
 <screen>
 <command>cp /etc/ssl/certs/cacert.pem .</command>
 </screen>
 
-              </step>
-              <step>  
-
-                <para>
-                The only thing left is to copy the <filename>ldap02-ssl</filename> directory to the Consumer server, then copy 
-                <filename>ldap02_slapd_cert.pem</filename> and <filename>cacert.pem</filename> to <filename>/etc/ssl/certs</filename>,
-                and copy <filename>ldap02_slapd_key.pem</filename> to <filename>/etc/ssl/private</filename>.
-                </para>
-
-              </step>
-              <step>  
-
-                <para>
-                Once the files are in place adjust the <emphasis>cn=config</emphasis> tree by entering:
-                </para>
-
-<screen>
-<command>sudo ldapmodify -Y EXTERNAL -H ldapi:///</command>
-</screen>
-
-<screen>
-<computeroutput>Enter LDAP Password:
-<userinput>dn: cn=config
+		<para>
+		We're done. Now transfer the <filename>ldap02-ssl</filename> directory to the Consumer.  Here we use scp (adjust accordingly):
+		</para>
+
+<screen>
+<command>cd ..</command>
+<command>scp -r ldap02-ssl user@consumer:</command>
+</screen>
+
+	</step>
+
+	<step>  
+		<para>
+		On the Consumer,
+		</para>
+
+		<para>
+		Configure TLS authentication:
+		</para>
+
+<screen>
+<command>sudo apt-get install ssl-cert</command>
+<command>sudo adduser openldap ssl-cert</command>
+<command>sudo cp ldap02_slapd_cert.pem cacert.pem /etc/ssl/certs</command>
+<command>sudo cp ldap02_slapd_key.pem /etc/ssl/private</command>
+<command>sudo chgrp ssl-cert /etc/ssl/private/ldap02_slapd_key.pem</command>
+<command>sudo chmod g+r /etc/ssl/private/ldap02_slapd_key.pem</command>
+<command>sudo chmod o-r /etc/ssl/private/ldap02_slapd_key.pem</command>
+</screen>
+
+		<para>
+		Create the file <filename>/etc/ssl/certinfo.ldif</filename> with the following contents (adjust accordingly):
+		</para>
+
+<programlisting>
+dn: cn=config
 add: olcTLSCACertificateFile
 olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
 -
@@ -1187,175 +1516,194 @@
 olcTLSCertificateFile: /etc/ssl/certs/ldap02_slapd_cert.pem
 -
 add: olcTLSCertificateKeyFile
-olcTLSCertificateKeyFile: /etc/ssl/private/ldap02_slapd_key.pem</userinput>
-
-modifying entry "cn=config"
-</computeroutput>
-</screen>
-
-              </step>
-              <step>  
-
-                <para>
-                As with the Provider you can now edit <filename>/etc/default/slapd</filename> and add the <emphasis>ldaps:///</emphasis>
-                parameter to the <emphasis>SLAPD_SERVICES</emphasis> option.
-                </para>
-              
-              </step>
-            </procedure>
-  
-            <para>
-            Now that <emphasis>TLS</emphasis> has been setup on each server, once again modify the <emphasis>Consumer</emphasis> server's
-            <emphasis>cn=config</emphasis> tree by entering the following in a terminal:
-            </para>
-
-<screen>
-<command>sudo ldapmodify -Y EXTERNAL -H ldapi:///</command>
-</screen>
-
-<screen>
-<computeroutput>SASL/EXTERNAL authentication started
-SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
-SASL SSF: 0
-<userinput>
+olcTLSCertificateKeyFile: /etc/ssl/private/ldap02_slapd_key.pem
+</programlisting>
+
+		<para>
+		Configure the slapd-config database:
+		</para>
+
+<screen>
+<command>sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.ldif</command>
+</screen>
+	
+		<para>
+		Configure <filename>/etc/default/slapd</filename> as on the Provider (SLAPD_SERVICES).
+		</para>
+	</step>
+
+	<step>
+		<para>
+		On the Consumer,
+		</para>
+
+		<para>
+		Configure TLS for Consumer-side replication. Modify the existing <emphasis>olcSyncrepl</emphasis> attribute by tacking
+		on some TLS options. In so doing, we will see, for the first time, how to change an attribute's value(s).
+		</para>
+
+		<para>
+		Create the file <filename>consumer_sync_tls.ldif</filename> with the following contents:
+		</para>
+
+<programlisting>
 dn: olcDatabase={1}hdb,cn=config
-replace: olcSyncrepl
-olcSyncrepl: {0}rid=0 provider=ldap://ldap01.example.com bindmethod=simple binddn="cn=ad
- min,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" logbas
- e="cn=accesslog" logfilter="(&amp;(objectClass=auditWriteObject)(reqResult=0))" s
- chemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog starttls=yes</userinput>
-
-modifying entry "olcDatabase={1}hdb,cn=config"
-</computeroutput>
-</screen>
-
-            <para>
-            If the LDAP server hostname does not match the Fully Qualified Domain Name (FQDN) in the certificate, you may have to edit 
-            <filename>/etc/ldap/ldap.conf</filename> and add the following TLS options:
-            </para>
+replace: olcSyncRepl
+olcSyncRepl: rid=0 provider=ldap://ldap01.example.com bindmethod=simple
+ binddn="cn=admin,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com"
+ logbase="cn=accesslog" logfilter="(&amp;(objectClass=auditWriteObject)(reqResult=0))"
+ schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog
+ <application>starttls=critical tls_reqcert=demand</application>
+</programlisting>
+
+		<para>
+		The extra options specify, respectively, that the consumer must use StartTLS and that the CA certificate is required to verify the
+		Provider's identity. Also note the LDIF syntax for changing the values of an attribute ('replace').
+		</para>
+
+		<para>
+		Implement these changes:
+		</para>
+
+<screen>
+<command>sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_sync_tls.ldif</command>
+</screen>
+
+		<para>
+		And restart slapd:
+		</para>
+
+<screen>
+<command>sudo service slapd restart</command>
+</screen>
+
+	</step>
+
+	<step>
+		<para>
+		On the Provider,
+		</para>
+
+		<para>
+		Check to see that a TLS session has been established. In <filename>/var/log/syslog</filename>, providing you have
+		'conns'-level logging set up, you should see messages similar to:		      
+		</para>
 
 <programlisting>
-TLS_CERT /etc/ssl/certs/ldap02_slapd_cert.pem
-TLS_KEY /etc/ssl/private/ldap02_slapd_key.pem
-TLS_CACERT /etc/ssl/certs/cacert.pem
+slapd[3620]: conn=1047 fd=20 ACCEPT from IP=10.153.107.229:57922 (IP=0.0.0.0:389)
+slapd[3620]: conn=1047 op=0 EXT oid=1.3.6.1.4.1.1466.20037
+slapd[3620]: conn=1047 op=0 STARTTLS
+slapd[3620]: conn=1047 op=0 RESULT oid= err=0 text=
+slapd[3620]: conn=1047 fd=20 TLS established tls_ssf=128 ssf=128
+slapd[3620]: conn=1047 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128
+slapd[3620]: conn=1047 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0
+slapd[3620]: conn=1047 op=1 RESULT tag=97 err=0 text
 </programlisting>
 
-
-              <para>
-              Finally, restart <application>slapd</application> on each of the servers:
-              </para>
-
-<screen>
-<command>sudo /etc/init.d/slapd restart</command>
-</screen>
-
-          </sect3>
-
-        </sect2>
-
-        <sect2 id="openldap-auth-config" status="review">
-          <title>LDAP Authentication</title>
-
-          <para>
-          Once you have a working LDAP server, the <application>auth-client-config</application> and <application>libnss-ldap</application> 
-          packages take the pain out of configuring an Ubuntu client to authenticate using LDAP.  To install the packages from, a terminal 
-          prompt enter:
-          </para> 
+	</step>
+
+	</procedure>
+
+		</sect2>
+
+		<sect2 id="openldap-auth-config" status="review">
+		<title>LDAP Authentication</title>
+
+	<para>
+	Once you have a working LDAP server, you will need to install libraries on the client that will know how and when to contact it.
+	On Ubuntu, this has been traditionally accomplishd by installing the <application>libnss-ldap</application> package. This package
+	will bring in other tools that will assist you in the configuration step. Install this package now:
+	</para> 
 
 <screen>
 <command>sudo apt-get install libnss-ldap</command>
 </screen>
 
-         <para>
-         During the install a menu dialog will ask you connection details about your LDAP server.
-         </para>
-       
-         <para>
-         If you make a mistake when entering your information you can execute the dialog again using:
-         </para>
-
+        <para>
+        You will be prompted for details of your LDAP server. If you make a mistake you can try again using:
+        </para>
+	
 <screen>
 <command>sudo dpkg-reconfigure ldap-auth-config</command>
 </screen>
 
-         <para>
-         The results of the dialog can be seen in <filename>/etc/ldap.conf</filename>.  If your server requires options not covered in the menu 
-         edit this file accordingly.
-         </para>
+	<para>
+	The results of the dialog can be seen in <filename>/etc/ldap.conf</filename>. If your server requires options not covered in the menu 
+	edit this file accordingly.
+	</para>
 
-         <para>
-         Now that <application>libnss-ldap</application> is configured enable the <application>auth-client-config</application> LDAP profile by 
-         entering:
-         </para>
+	<para>
+	Now configure the LDAP profile for NSS:
+	</para>
 
 <screen>
 <command>sudo auth-client-config -t nss -p lac_ldap</command>
 </screen>
          
-          <itemizedlist>
-	    <listitem>
-              <para>
-	      <emphasis>-t:</emphasis> only modifies <filename>/etc/nsswitch.conf</filename>.
-	      </para>
-            </listitem>
-	    <listitem>
-              <para>
-	      <emphasis>-p:</emphasis> name of the profile to enable, disable, etc.
-	      </para>
-	    </listitem>
-	    <listitem>
-              <para>
-	      <emphasis>lac_ldap:</emphasis> the <application>auth-client-config</application> profile that is part of the 
-              <application>ldap-auth-config</application> package.
-	      </para>
-	    </listitem>
-          </itemizedlist>
-
-          <para>
-          Using the <application>pam-auth-update</application> utility, configure the system to use LDAP for authentication:
-          </para>
+	<para>
+	Configure the system to use LDAP for authentication:
+	</para>
 
 <screen>
 <command>sudo pam-auth-update</command>
 </screen>
 
-          <para>
-          From the <application>pam-auth-update</application> menu, choose LDAP and any other authentication mechanisms you need.
-          </para>
-
-          <para>
-          You should now be able to login using user credentials stored in the LDAP directory.
-          </para> 
-
-          <note>
-            <para>
-            If you are going to use LDAP to store Samba users you will need to configure the server to authenticate using LDAP.
-            See <xref linkend="samba-ldap"/> for details.
-            </para>
-          </note>
-
-        </sect2>
-        <sect2 id="ldap-usergroup-management" status="review">
-          <title>User and Group Management</title>
-
-          <para>
-          The <application>ldap-utils</application> package comes with multiple utilities to manage the directory, but the long 
-          string of options needed, can make them a burden to use. The <application>ldapscripts</application> package contains 
-          configurable scripts to easily manage LDAP users and groups.
-          </para>
-
-          <para>
-          To install the package, from a terminal enter:
-          </para>
+	<para>
+	From the menu, choose LDAP and any other authentication mechanisms you need.
+	</para>
+
+	<para>
+	You should now be able to log in using LDAP-based credentials.
+	</para> 
+
+	<para>
+	LDAP clients will need to refer to multiple servers if replication is in use. In <filename>/etc/ldap.conf</filename> you would
+	have something like:
+	</para>
+
+<programlisting>
+uri ldap://ldap01.example.com ldap://ldap02.example.com
+</programlisting>
+
+	<para>
+	The request will time out and the Consumer (ldap02) will attempt to be reached if the Provider (ldap01) becomes unresponsive.
+	</para>
+
+	<para>
+	If you are going to use LDAP to store Samba users you will need to configure the Samba server to authenticate using LDAP. See
+	<xref linkend="samba-ldap"/> for details.
+	</para>
+
+	<note>
+		<para>
+		An alternative to the <application>libnss-ldap</application> package is the <application>libnss-ldapd</application>
+		package. This, however, will bring in the <application>nscd</application> package which is problably not wanted. Simply
+		remove it afterwards.
+		</para>
+	</note>
+		
+		</sect2>
+
+		<sect2 id="ldap-usergroup-management" status="review">
+		<title>User and Group Management</title>
+
+	<para>
+	The <application>ldap-utils</application> package comes with enough utilities to manage the directory but the long string of
+	options needed can make them a burden to use. The <application>ldapscripts</application> package contains wrapper scripts to these
+	utilities that some people find easier to use.
+	</para>
+
+	<para>
+	Install the package:
+	</para>
 
 <screen>
 <command>sudo apt-get install ldapscripts</command>
 </screen>
 
-          <para> 
-          Next, edit the config file <filename>/etc/ldapscripts/ldapscripts.conf</filename> uncommenting and changing the following to 
-          match your environment:
-          </para>       
+	<para> 
+	Then edit the file <filename>/etc/ldapscripts/ldapscripts.conf</filename> to arrive at something similar to the following:
+	</para>       
 
 <programlisting>
 SERVER=localhost
@@ -1370,104 +1718,125 @@
 MIDSTART=10000
 </programlisting>
 
-          <para>
-          Now, create the <filename>ldapscripts.passwd</filename> file to allow authenticated access to the directory:
-          </para>
+	<para>
+	Now, create the <filename>ldapscripts.passwd</filename> file to allow rootDN access to the directory:
+	</para>
 
 <screen>
 <command>sudo sh -c "echo -n 'secret' > /etc/ldapscripts/ldapscripts.passwd"</command>
 <command>sudo chmod 400 /etc/ldapscripts/ldapscripts.passwd</command>
 </screen>
 
-          <note>
-            <para>
-            Replace <quote>secret</quote> with the actual password for your LDAP admin user.
-            </para>
-          </note>
-
-          <para>
-          The <application>ldapscripts</application> are now ready to help manage your directory.  The following are some examples
-          of how to use the scripts:
-          </para>
-
-          <itemizedlist>
-	    <listitem>
-              <para>
-	      Create a new user:
-	      </para>
+	<note>
+		<para>
+		Replace <quote>secret</quote> with the actual password for your database's rootDN user.
+		</para>
+	</note>
+
+	<para>
+	The scripts are now ready to help manage your directory. Here are some examples of how to use them:
+	</para>
+
+	<itemizedlist>
+
+	<listitem>
+		<para>
+		Create a new user:
+		</para>
+
 <screen>
 <command>sudo ldapadduser george example</command>
 </screen>
-              <para>
-              This will create a user with uid <emphasis role="italic">george</emphasis> and set the user's primary group (gid) to
-              <emphasis role="italic">example</emphasis>
-              </para>
-	    </listitem>
-	    <listitem>
-              <para>
-	      Change a user's password:
-	      </para>
+
+		<para>
+		This will create a user with uid <emphasis role="italic">george</emphasis> and set the user's primary group (gid) to
+		<emphasis role="italic">example</emphasis>
+		</para>
+	</listitem>
+
+	<listitem>
+		<para>
+		Change a user's password:
+		</para>
+
 <screen>
 <command>sudo ldapsetpasswd george</command>
 <computeroutput>Changing password for user uid=george,ou=People,dc=example,dc=com</computeroutput>
 <userinput>New Password: </userinput>
 <userinput>New Password (verify): </userinput>
 </screen>
-	    </listitem>
-	    <listitem>
-              <para>
-	      Delete a user:
-	      </para>
+
+	</listitem>
+
+	<listitem>
+		<para>
+		Delete a user:
+		</para>
+
 <screen>
 <command>sudo ldapdeleteuser george</command>
 </screen>
 
-	    </listitem>
-	    <listitem>
-              <para>
-	      Add a group:
-	      </para>
+	</listitem>
+
+	<listitem>
+		<para>
+		Add a group:
+		</para>
+
 <screen>
 <command>sudo ldapaddgroup qa</command>
 </screen>
-	    </listitem>
-	    <listitem>
-              <para>
-	      Delete a group:
-	      </para>
+
+	</listitem>
+
+	<listitem>
+		<para>
+		Delete a group:
+		</para>
+
 <screen>
 <command>sudo ldapdeletegroup qa</command>
 </screen>
-	    </listitem>
-	    <listitem>
-              <para>
-	      Add a user to a group:
-	      </para>
+
+	</listitem>
+
+	<listitem>
+		<para>
+		Add a user to a group:
+		</para>
+
 <screen>
 <command>sudo ldapaddusertogroup george qa</command>
 </screen>
-              <para>
-              You should now see a <emphasis>memberUid</emphasis> attribute for the <emphasis role="italic">qa</emphasis> group with 
-              a value of <emphasis role="italic">george</emphasis>.
-              </para>
-	    </listitem>
-            <listitem>
-              <para>
-	      Remove a user from a group:
-	      </para>
+
+		<para>
+		You should now see a <emphasis>memberUid</emphasis> attribute for the <emphasis role="italic">qa</emphasis> group with 
+		a value of <emphasis role="italic">george</emphasis>.
+		</para>
+	</listitem>
+
+	<listitem>
+		<para>
+		Remove a user from a group:
+		</para>
+
 <screen>
 <command>sudo ldapdeleteuserfromgroup george qa</command>
 </screen>
-              <para>
-              The <emphasis>memberUid</emphasis> attribute should now be removed from the <emphasis role="italic">qa</emphasis>
-              group.
-              </para>
-	    </listitem>
-            <listitem>
-              <para>
-	      The <application>ldapmodifyuser</application> script allows you to add, remove, or replace a user's attributes.  
-              The script uses the same syntax as the <application>ldapmodify</application> utility.  For example:
-	      </para>
+
+		<para>
+		The <emphasis>memberUid</emphasis> attribute should now be removed from the <emphasis role="italic">qa</emphasis>
+		group.
+		</para>
+	</listitem>
+
+	<listitem>
+		<para>
+		The <application>ldapmodifyuser</application> script allows you to add, remove, or replace a user's attributes.  
+		The script uses the same syntax as the <application>ldapmodify</application> utility.  For example:
+		</para>
+
 <screen>
 <command>sudo ldapmodifyuser george</command>
 <computeroutput># About to modify the following entry :
@@ -1489,36 +1858,38 @@
 <userinput>replace: gecos
 gecos: George Carlin</userinput>
 </screen>
-              <para>
-              The user's <emphasis>gecos</emphasis> should now be <quote>George Carlin</quote>.
-              </para>
-	    </listitem>
-            <listitem>
-              <para>
-	      Another great feature of <application>ldapscripts</application>, is the template system.  Templates
-              allow you to customize the attributes of user, group, and machine objectes.  For example, to enable
-              the <emphasis>user</emphasis> template edit <filename>/etc/ldapscripts/ldapscripts.conf</filename> 
-              changing:
-	      </para>
+
+		<para>
+		The user's <emphasis>gecos</emphasis> should now be <quote>George Carlin</quote>.
+		</para>
+	</listitem>
+
+	<listitem>
+		<para>
+		A nice feature of <application>ldapscripts</application> is the template system. Templates allow you to customize the
+		attributes of user, group, and machine objectes. For example, to enable the <emphasis>user</emphasis> template edit
+		<filename>/etc/ldapscripts/ldapscripts.conf</filename> changing:
+		</para>
 
 <programlisting>
 UTEMPLATE="/etc/ldapscripts/ldapadduser.template"
 </programlisting>
 
-              <para>
-              There are <emphasis role="italic">sample</emphasis> templates in the <filename>/etc/ldapscripts</filename> directory.
-              Copy or rename the <filename>ldapadduser.template.sample</filename> file to 
-              <filename>/etc/ldapscripts/ldapadduser.template</filename>:
-              </para>
+		<para>
+		There are <emphasis role="italic">sample</emphasis> templates in the <filename>/etc/ldapscripts</filename> directory.
+		Copy or rename the <filename>ldapadduser.template.sample</filename> file to
+		<filename>/etc/ldapscripts/ldapadduser.template</filename>:
+		</para>
 
 <screen>
-<command>sudo cp /usr/share/doc/ldapscripts/examples/ldapadduser.template.sample /etc/ldapscripts/ldapadduser.template</command>
+<command>sudo cp /usr/share/doc/ldapscripts/examples/ldapadduser.template.sample \
+/etc/ldapscripts/ldapadduser.template</command>
 </screen>
 
-              <para>
-              Edit the new template to add the desired attributes.  The following will create new user's as with an 
-              <emphasis>objectClass</emphasis> of <emphasis>inetOrgPerson</emphasis>:
-              </para>
+		<para>
+		Edit the new template to add the desired attributes. The following will create new users with an objectClass of
+		inetOrgPerson:
+		</para>
 
 <programlisting>
 dn: uid=&lt;user&gt;,&lt;usuffix&gt;,&lt;suffix&gt;
@@ -1536,59 +1907,112 @@
 title: Employee
 </programlisting>
 
-              <para>
-              Notice the <emphasis>&lt;ask&gt;</emphasis> option used for the <emphasis>ssn</emphasis> value.  Using &lt;ask&gt; 
-              will configure <application>ldapadduser</application> to prompt you for the attribute value during user creation.
-              </para>
-
-	    </listitem>
-          </itemizedlist>
-
-          <para>
-          There are more useful scripts in the package, to see a full list enter: <command>dpkg -L ldapscripts | grep bin</command>
-          </para>
-
-        </sect2>
-	<sect2 id="openldap-server-resources" status="review">
-	  <title>Resources</title>
-	  <itemizedlist>
-	    <listitem>
-          <para>
-	      The <ulink url="https://help.ubuntu.com/community/OpenLDAPServer">OpenLDAP Ubuntu Wiki</ulink> page has more details.
-	      </para>
-	    </listitem>
-	    <listitem>
-          <para>
-	      For more information see <ulink url="http://www.openldap.org/">OpenLDAP Home Page</ulink>
-	      </para>
-	    </listitem>
-	    <listitem>
-              <para>
-	      Though starting to show it's age, a great source for in depth LDAP information is 
-	      O'Reilly's <ulink url="http://www.oreilly.com/catalog/ldapsa/">LDAP System Administration</ulink>
-	      </para>
-	    </listitem>
-	    <listitem>
-              <para>
-              Packt's <ulink url="http://www.packtpub.com/OpenLDAP-Developers-Server-Open-Source-Linux/book">Mastering OpenLDAP</ulink>
-              is a great reference covering newer versions of OpenLDAP.
-	      </para>
-	    </listitem>
-	    <listitem>
-              <para>
-              For more information on <application>auth-client-config</application> see the man page: <command>man auth-client-config</command>.
-	      </para>
-	    </listitem>
-	    <listitem>
-              <para>
-              For more details regarding the <application>ldapscripts</application> package see the man pages: <command>man ldapscripts</command>,
-              <command>man ldapadduser</command>, <command>man ldapaddgroup</command>, etc.
-	      </para>
-	    </listitem>
-	  </itemizedlist>
+		<para>
+		Notice the <emphasis>&lt;ask&gt;</emphasis> option used for the <emphasis>sn</emphasis> attribute. This 
+		will make <application>ldapadduser</application> prompt you for it's value.
+		</para>
+	</listitem>
+
+	</itemizedlist>
+
+        <para>
+        There are utilities in the package that were not covered here. Here is a complete list:
+        </para>
+
+<programlisting>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldaprenamemachine.1.html">ldaprenamemachine</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapadduser.1.html">ldapadduser</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapdeleteuserfromgroup.1.html">ldapdeleteuserfromgroup</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapfinger.1.html">ldapfinger</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapid.1.html">ldapid</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapgid.1.html">ldapgid</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapmodifyuser.1.html">ldapmodifyuser</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldaprenameuser.1.html">ldaprenameuser</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/lsldap.1.html">lsldap</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapaddusertogroup.1.html">ldapaddusertogroup</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapsetpasswd.1.html">ldapsetpasswd</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapinit.1.html">ldapinit</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapaddgroup.1.html">ldapaddgroup</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapdeletegroup.1.html">ldapdeletegroup</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapmodifygroup.1.html">ldapmodifygroup</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapdeletemachine.1.html">ldapdeletemachine</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldaprenamegroup.1.html">ldaprenamegroup</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapaddmachine.1.html">ldapaddmachine</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapmodifymachine.1.html">ldapmodifymachine</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapsetprimarygroup.1.html">ldapsetprimarygroup</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man1/ldapdeleteuser.1.html">ldapdeleteuser</ulink>
+</programlisting>
+
+		</sect2>
+
+		<sect2 id="openldap-server-resources" status="review">
+		<title>Resources</title>
+
+	<itemizedlist>
+
+	<listitem>
+	<para>
+	The primary resource is the upstream documentation: <ulink url="http://www.openldap.org/">www.openldap.org</ulink>
+	</para>
+	</listitem>
+
+	<listitem>
+	<para>
+	There are many man pages that come with the slapd package. Here are some important ones, especially considering the material
+	presented in this guide:
+	</para>
+
+<programlisting>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man8/slapd.8.html">slapd</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man5/slapd-config.5.html">slapd-config</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man5/slapd.access.5.html">slapd.access</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man5/slapo-syncprov.5.html">slapo-syncprov</ulink>
+</programlisting>
+
+	</listitem>
+
+	<listitem>
+	<para>
+	Other man pages:
+	</para>
+
+<programlisting>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man8/auth-client-config.8.html">auth-client-config</ulink>
+<ulink url="http://manpages.ubuntu.com/manpages/en/man8/pam-auth-update.8.html">pam-auth-update</ulink>
+</programlisting>
+
+	</listitem>
+
+	<listitem>
+	<para>
+	Zytrax's <ulink url="http://www.zytrax.com/books/ldap/">LDAP for Rocket Scientists</ulink>; a less pedantic but comprehensive treatment of LDAP
+	</para>
+	</listitem>
+
+	<listitem>
+	<para>
+	A Ubuntu community <ulink url="https://help.ubuntu.com/community/OpenLDAPServer">OpenLDAP wiki</ulink> page has a collection of notes
+	</para>
+	</listitem>
+
+	<listitem>
+	<para>
+	O'Reilly's <ulink url="http://www.oreilly.com/catalog/ldapsa/">LDAP System Administration</ulink> (textbook; 2003)
+	</para>
+	</listitem>
+
+	<listitem>
+	<para>
+	Packt's <ulink url="http://www.packtpub.com/OpenLDAP-Developers-Server-Open-Source-Linux/book">Mastering OpenLDAP</ulink> (textbook; 2007)
+	</para>
+	</listitem>
+
+	</itemizedlist>
 	 
-	</sect2>
-  </sect1>
+		</sect2>
+
+	</sect1>
+
   <sect1 id="samba-ldap" status="review">
     <title>Samba and LDAP</title>
 
@@ -1725,11 +2149,9 @@
 modifyTimestamp: 20080827045234Z
 </programlisting>
 
-                <note>
                   <para>
                   The attribute values will vary, just be sure the attributes are removed.
                   </para>
-                </note>
 
               </step>
               <step>
@@ -1845,7 +2267,7 @@
 
           <note>
             <para>
-            You can create an LDIF file containing the new Samba objects by executing <command>sudo smbldap-populate -e samba.ldif</command>.
+            You can create a LDIF file containing the new Samba objects by executing <command>sudo smbldap-populate -e samba.ldif</command>.
             This allows you to look over the changes making sure everything is correct.
             </para>
           </note>
@@ -2769,11 +3191,9 @@
 modifyTimestamp: 20090111203515Z
 </programlisting>
 
-                  <note>
                     <para>
                     The attribute values will vary, just be sure the attributes are removed. 
                     </para>
-                  </note>
 
                 </step>
                 <step>