[deployment-guide/comm-rel: 213/727] BZ 606922, Trac#383: last minute edits to LDAP referral sub-section

[Jaromir Hradilek]

commit 784e8d9d6642cb1aa8f230d22288fd8e57b0124d
Author: David O'Brien <davido at redhat.com>
Date:   Mon Aug 2 15:45:09 2010 +1000

    BZ 606922, Trac#383: last minute edits to LDAP referral sub-section

 en-US/SSSD.xml |   27 +++++++++++++++++++++------
 1 files changed, 21 insertions(+), 6 deletions(-)
---
diff --git a/en-US/SSSD.xml b/en-US/SSSD.xml
index 680f6fb..9472026 100644
--- a/en-US/SSSD.xml
+++ b/en-US/SSSD.xml
@@ -81,20 +81,32 @@
     </section>
 
     <section><title>Support for LDAP Referrals</title>
-      <para>SSSD supports two types of LDAP referrals: object-level referrals and subtree referrals. These referral types and the extent of SSSD support is outlined below.</para>
+      <para>
+        SSSD supports two types of LDAP referrals: object-level referrals and subtree referrals. These referral types and the extent of SSSD support is outlined below.
+      </para>
       <section><title>Object-level Referrals</title>
         <para>
           SSSD provides full support for object-level referrals within the same LDAP server, correctly handling any differences in the distinguished name (DN) that might exist as part of the LDAP server referral configuration.
         </para>
         <para>
-          SSSD only provides partial support for object-level referrals between different LDAP servers, however. If the full DN of an LDAP request is identical on each server, then SSSD will correctly support such a request. SSSD does not support referrals to a different DN path on another server.
+          SSSD provides partial support for object-level referrals between different LDAP servers, and requires that the full DN of an LDAP request be identical on each server. SSSD does not support referrals to different DN paths on other servers.
         </para>
       </section>
       <section><title>Subtree Referrals</title>
         <para>
-          SSSD provides a similar level of support for subtree referrals as it does for object-level referrals. That is, it supports referrals to a changed DN on the local system or to an identical DN on a remote system. The difference with subtree referrals, however, is the ability to set up identical subtrees on each LDAP server and then configure referrals between these subtrees.
+          SSSD provides a similar level of support for subtree referrals as it does for object-level referrals. That is, it supports referrals to a changed DN on the local system or to an identical DN on a remote system. The difference with subtree referrals, however, is the ability to set up identical subtrees on each LDAP server and to then configure referrals between these subtrees.
         </para>
       </section>
+      <section><title>Enabling LDAP Referrals</title>
+        <para>
+          To take advantage of the SSSD LDAP referral functionality, you need to set the <option>ldap_referrals</option> option to <literal>TRUE</literal> in the LDAP domain configuration section of the <filename>/etc/sssd.conf</filename> file. This will enable anonymous access to the second LDAP server.
+        </para>
+        <note>
+          <para>
+            SSSD only supports LDAP referrals when it is compiled with OpenLDAP version 2.4.13 or later.
+          </para>
+        </note>
+      </section>
     </section>
 
     <section id="sect-SSSD_User_Guide-SSSD_Features-Differentiating_Like_named_Users">
@@ -1063,10 +1075,10 @@ ldap_group_object_class = group</screen>
 
 
   <section id="sect-SSSD_User_Guide-Configuring_Domains-Setting_up_Kerberos_Authentication">
-    <title>Setting up Kerberos Authentication</title>
+    <title>Setting Up Kerberos Authentication</title>
     <indexterm>
       <primary>SSSD</primary>
-      <secondary>Setting up Kerberos authentication for</secondary>
+      <secondary>Setting Up Kerberos authentication for</secondary>
     </indexterm>
 
     <para>
@@ -1079,10 +1091,13 @@ ldap_group_object_class = group</screen>
     <para>
       If the UPN is not available in the identity back end, SSSD will construct a UPN using the format <systemitem class="username">username at krb5_realm</systemitem>.
     </para>
+    <para>
+      SSSD assumes that the Kerberos KDC is also a Kerberos kadmin server. However, it is very common for production environments to have multiple, read-only replicas of the KDC, but only a single kadmin server (because password changes and similar procedures are comparitively rare). To manage this type of configuration, you can use the <option>krb5_kpasswd</option> option to specify where your password changing service is running, or if it is running on a non-default port. Refer to the <citetitle>sssd-krb5(5)</citetitle> manual page for more information about this and all Kerberos configuration options.
+    </para>
 
     <formalpara
                id="form-SSSD_User_Guide-Setting_Up_Kerberos_Authentication-How_to_Set_up_Kerberos_Authentication">
-      <title>How to Set up Kerberos Authentication</title>
+      <title>How to Set Up Kerberos Authentication</title>
       <para>Edit your <filename>/etc/sssd/sssd.conf</filename> file to reflect the following example:</para>
     </formalpara>