[deployment-guide/comm-rel: 3/13] Trac #367; updates to Failover and Service Discovery
dsilas
dsilas at fedoraproject.org
Sun Jun 20 21:48:56 UTC 2010
commit cf6822212ae74e844ad7673c1b1033b46f20ff2c
Author: David O'Brien <daobrien at daobrien.csb>
Date: Tue May 18 13:24:22 2010 +1000
Trac #367; updates to Failover and Service Discovery
en-US/SSSD.xml | 26 +++++++++++++++++---------
1 files changed, 17 insertions(+), 9 deletions(-)
---
diff --git a/en-US/SSSD.xml b/en-US/SSSD.xml
index 79703af..29f161c 100644
--- a/en-US/SSSD.xml
+++ b/en-US/SSSD.xml
@@ -264,8 +264,9 @@ session optional pam_console.so
<formalpara><title>Using the Simple Access Provider</title>
<para>By using the Simple Access Provider, you can continue to support a number of network logins to maintain common network accounts on company or department laptops, but you might want to restrict the use of a particular laptop to one or two users. This means that even if a different user authenticated successfully against the same authentication provider, the Simple Access Provider would prevent that user from gaining access.</para>
</formalpara>
+ <para>The Simple Access Provider is also useful if you have two domains configured that have some overlapping users. In this scenario, you can specify <parameter>simple_deny_users</parameter> in one domain for a set of users, thereby guaranteeing that those users will be handled by the other domain.</para>
- <para>The following example demonstrates the use of the Simple Access Provider to grant access to two users. This example assumes that SSSD is correctly configured and example.com is one of the domains specified in the <literal>[sssd]</literal> section, and only shows the Simple Access Provider-specific options.</para>
+ <para>The following example demonstrates the use of the Simple Access Provider to grant access to two users. This example assumes that SSSD is correctly configured and <systemitem class="domainname">example.com</systemitem> is one of the domains specified in the <literal>[sssd]</literal> section, and only shows the Simple Access Provider-specific options.</para>
<screen>[domain/example.com]
access_provider = simple
@@ -278,7 +279,7 @@ simple_allow_users = user1, user2</screen>
<listitem><para>If <parameter>simple_allow_users</parameter> is set, only users from this list are allowed access. This setting supersedes the <parameter>simple_deny_users</parameter> list (which would be redundant).</para></listitem>
<listitem><para>If the <parameter>simple_allow_users</parameter> list is empty, users are allowed access unless they appear in the <parameter>simple_deny_users</parameter> list.</para></listitem>
</itemizedlist>
- <note><para>It is a configuration error if both <parameter>simple_allow_users</parameter> and <parameter>simple_deny_users</parameter> are defined.</para></note>
+ <important><para>Defining both <parameter>simple_allow_users</parameter> and <parameter>simple_deny_users</parameter> is a configuration error. If this occurs, SSSD will throw an error when loading the back end and will fail to start.</para></important>
</para>
</formalpara>
</section>
@@ -293,9 +294,11 @@ simple_allow_users = user1, user2</screen>
<para>In this configuration, <uri>ldap://ldap0.mydomain.org</uri> functions as the primary server. If this server fails, the SSSD failover mechanism first attempts to connect to <uri>ldap1.mydomain.org</uri>, and if that is unavailable, it then attempts to connect to <uri>ldap2.mydomain.org</uri>. If the primary server is restored, the failover mechanism automatically restores operations to use that server instead of any failover servers.</para>
- <warning><para>Do not use multiple <parameter>ldap_uri</parameter> parameters to specify your failover servers. The failover servers must be entered as a comma-separated list of values for a single <parameter>ldap_uri</parameter> parameter. If you enter multiple <parameter>ldap_uri</parameter> parameters, SSSD only recognizes the last entry.</para></warning>
+ <para>If the parameter that specifies which server to connect to for the specific domain (for example, <parameter>ldap_uri</parameter>, <parameter>krb5_kdcip</parameter>, …) is not specified, the back end defaults to using <replaceable>Use service discovery</replaceable>. Refer to <xref linkend="sect-SSSD_User_Guide-Configuring_Domains-Configuring_Failover-Using_SRV_Records_with_Failover"/> for more information on service discovery.</para>
- <section>
+ <important><para>Do not use multiple <parameter>ldap_uri</parameter> parameters to specify your failover servers. The failover servers must be entered as a comma-separated list of values for a single <parameter>ldap_uri</parameter> parameter. If you enter multiple <parameter>ldap_uri</parameter> parameters, SSSD only recognizes the last entry.</para></important>
+
+ <section id="sect-SSSD_User_Guide-Configuring_Domains-Configuring_Failover-Using_SRV_Records_with_Failover">
<title>Using SRV Records with Failover</title>
<para>SSSD also supports the use of SRV records in its failover configuration. This means that you can specify a server that is later resolved into a list of specific servers using SRV requests. The <parameter>priority</parameter> and <parameter>weight</parameter> attributes of SRV records provide further opportunity for specifying which servers should be contacted first in the event that the primary server fails.</para>
@@ -413,7 +416,7 @@ simple_allow_users = user1, user2</screen>
<option>filter_users_in_groups <type>(Boolean)</type>
</option>
</para>
- <para>Specifies that filtered users do not appear in group memberships. If not specified, defaults to <literal>TRUE</literal>.</para>
+ <para>If set to TRUE, specifies that users listed in the <option>filter_users</option> list do not appear in group memberships when performing group lookups. If set to FALSE, group lookups return all users that are members of that group. If not specified, defaults to <literal>TRUE</literal>.</para>
</listitem>
</itemizedlist>
</section>
@@ -682,12 +685,17 @@ tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
</screen>
-<note>
+ <formalpara>
+ <title>Selecting an LDAP Schema</title>
+ <para>
+ You can set the <parameter>ldap_schema</parameter> attribute to either <literal>rfc2307</literal> or <literal>rfc2307bis</literal>. These schema define how groups in <acronym>LDAP</acronym> are specified. In <citetitle>RFC 2307</citetitle>, group objects use a multi-valued attribute, <parameter>memberuid</parameter>, which lists the names of the users that belong to that group. In <citetitle>RFC 2307bis</citetitle>, instead of the <parameter>memberuid</parameter>, group objects use the <parameter>member</parameter> attribute. Rather than just the name of the user, this attribute contains the full Distinguished Name (DN) of another object in the <acronym>LDAP</acronym> database. This means that groups can have other groups as members. That is, it adds support for nested groups.
+ </para>
+ </formalpara>
<para>
- The <parameter>ldap_schema</parameter> attribute can be set to either <literal>rfc2307</literal>, which uses the <parameter>memberuid</parameter> attribute for group membership, or to <parameter>rfc2307bis</parameter>, which uses the <parameter>member</parameter> attribute. Changes to this setting only affect how SSSD determines the groups to which a user belongs; there is no negative effect on the actual user data. If you do not know the correct value for this attribute, consult your System Administrator.
+ Changes to this setting only affect how SSSD determines the groups to which a user belongs; there is no negative effect on the actual user data. If you do not know the correct value for this attribute, consult your System Administrator.
</para>
-</note>
- <para>Refer to the <citetitle>sssd-ldap(5)</citetitle> manual page for a full description of all the parameters that apply to a native LDAP domain.</para>
+
+ <para>Refer to the <citetitle>sssd-ldap(5)</citetitle> manual page for a full description of all the parameters that apply to a native <acronym>LDAP</acronym> domain.</para>
</section>
<section
More information about the docs-commits
mailing list