Extended section on overloading ldap attrs

fixes bug 1041704

This new overloading attributes functionality was introduced
recently, and this patch extends the section with some text
stolen from the keystone commit notes.

Change-Id: Ibed2b12bc43ae4220128c5ce8435f83a74758a16
This commit is contained in:
Tom Fifield
2012-09-08 11:28:56 +10:00
parent 4c329aad3f
commit 5f018d18ed

View File

@@ -1323,13 +1323,29 @@ suffix =cn=exampledomain,cn=com
driver = keystone.identity.backends.ldap.Identity </screen>
</listitem>
</orderedlist></para>
<para>By default, the user name in the Identity service is queried against the LDAP
<emphasis role="bold">SN</emphasis> (SurName) attribute type and the tenant name in the
Identity service will be queried against the LDAP <emphasis role="bold">OU</emphasis> (Organizational Unit)
attribute type. These can be changed through the <literal>user_name_attribute</literal>
and <literal>tenant_name_attribute</literal> configuration options in
<filename>keystone.conf</filename>. For example, you can configure the Identity service to
<para><emphasis role="bold">Overriding default attributes</emphasis></para>
<para>
The default object classes and attributes are intentionally simplistic. They
reflect the common standard objects according to the LDAP RFCs.
By default, the user name in the Identity service is queried against the LDAP
<emphasis role="bold">SN</emphasis> (SurName) attribute type and the tenant name in the
Identity service will be queried against the LDAP <emphasis role="bold">OU</emphasis> (Organizational Unit)
attribute type.</para>
<para> However, in a live deployment, the correct attributes can be overridden to support a
preexisting, more complex schema. These can be changed through the
<literal>user_name_attribute</literal>, <literal>user_id_attribute</literal>
and <literal>tenant_name_attribute</literal> configuration options in
<filename>keystone.conf</filename>. </para>
<para>For example, you can configure the Identity service to
use the CN (Common Name) instead of SN.</para>
<para> As a more detailed example, in the user object, the
objectClass posixAccount from RFC2307 is very common. If this is the
underlying objectclass, then the <literal>uid</literal> field should probably be <literal>uidNumber</literal> and
<literal>username</literal> field either <literal>uid</literal> or <literal>cn</literal>. To change these two fields, the
corresponding entries in the Keystone configuration file would be:</para>
<programlisting>[ldap]
user_id_attribute = uidNumber
user_name_attribute = cn</programlisting>
</section>
<section xml:id="reference-for-ldap-config-options">
<title>Reference for LDAP Configuration Options in keystone.conf</title>