[deployment-guide/comm-rel: 212/727] BZ 606922; add sub-section on referral support in SSSD
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Oct 19 12:42:11 UTC 2010
commit ba46d42901b0676f0d305674db114ce319452bd6
Author: David O'Brien <davido at redhat.com>
Date: Mon Aug 2 11:53:18 2010 +1000
BZ 606922; add sub-section on referral support in SSSD
en-US/SSSD.xml | 73 +++++++++++++++++++++++++++++++------------------------
1 files changed, 41 insertions(+), 32 deletions(-)
---
diff --git a/en-US/SSSD.xml b/en-US/SSSD.xml
index 3974499..680f6fb 100644
--- a/en-US/SSSD.xml
+++ b/en-US/SSSD.xml
@@ -39,53 +39,62 @@
</section>
<section id="sect-SSSD_User_Guide-SSSD_Features-Specifying_Multiple_Domains">
-
<title>Specifying Multiple Domains</title>
- <indexterm>
+ <indexterm>
<primary>multiple domains</primary>
<secondary>specifying in SSSD</secondary>
</indexterm>
-
<para>
You can use SSSD to specify multiple domains of the same type. Compare this to an <filename>nsswitch.conf</filename> file configuration, with which you can only request user information from a single server of any particular type (LDAP, NIS, etc.). With SSSD, you can create multiple domains of the same, or of different types of identity provider.
</para>
<para>
Beginning with version 0.6.0, SSSD maintains a separate database file for each domain. This means that each domain has its own cache, and in the event that problems occur and maintenance is necessary, it is very easy to purge the cache for a single domain, by stopping <systemitem class="daemon">sssd</systemitem> and deleting the corresponding cache file. These cache files are stored in the <filename>/var/lib/sss/db/</filename> directory.
</para>
-
-
<para>
All cache files are named according to the domain that they represent, for example <filename>cache_<replaceable>DOMAINNAME</replaceable>.ldb</filename>.
</para>
-
<formalpara>
- <title>Considerations Associated with Deleting Cache Files</title>
- <indexterm>
- <primary>deleting cache files</primary>
- <secondary>in SSSD</secondary>
- </indexterm>
-
- <para>
- Deleting a domain's cache file can have some unexpected side effects. You should be aware of the following before you proceed:
- <itemizedlist>
- <listitem>
- <para>
- Deleting the cache file also deletes all user data (both identification and cached credentials). Consequently, you should not proceed unless you are online and can authenticate with your username against the domain's servers, because offline authentication will fail.
- </para>
- </listitem>
- <listitem>
- <para>
- If you are online and change your configuration to reference a different identity provider, SSSD will recognize users from both providers until the cached entries from the original provider time out.
- </para>
- <para>
- To avoid this situation, you can either purge the cache or use a different domain name for the new provider (this is the recommended practice). Changing the domain name means that when you restart SSSD it will create a new cache file (with the new name) and the old file will be ignored.
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </formalpara>
-<!-- <para>The local user cache (that is, for a domain where <parameter>id_provider=local</parameter>), is stored in the <filename>sssd.ldb</filename> file.</para> -->
+ <title>Considerations Associated with Deleting Cache Files</title>
+ <indexterm>
+ <primary>deleting cache files</primary>
+ <secondary>in SSSD</secondary>
+ </indexterm>
+ <para>
+ Deleting a domain's cache file can have some unexpected side effects. You should be aware of the following before you proceed:
+ </para>
+ </formalpara>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Deleting the cache file also deletes all user data (both identification and cached credentials). Consequently, you should not proceed unless you are online and can authenticate with your username against the domain's servers, because offline authentication will fail.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If you are online and change your configuration to reference a different identity provider, SSSD will recognize users from both providers until the cached entries from the original provider time out.
+ </para>
+ <para>
+ To avoid this situation, you can either purge the cache or use a different domain name for the new provider (this is the recommended practice). Changing the domain name means that when you restart SSSD it will create a new cache file (with the new name) and the old file will be ignored.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </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>
+ <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.
+ </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.
+ </para>
+ </section>
</section>
<section id="sect-SSSD_User_Guide-SSSD_Features-Differentiating_Like_named_Users">
More information about the docs-commits
mailing list