bc7a9f0da7
Partial-Bug: #1250515 backport: havana Change-Id: I9675dffd130c8aa6343143d9806adb4e0b74a55d author: diane fleming
136 lines
5.4 KiB
XML
136 lines
5.4 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<section xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
|
|
xml:id="configuring-keystone-for-ldap-backend">
|
|
<title>Configure the Identity Service with an LDAP
|
|
back-end</title>
|
|
<para>As an alternative to the SQL database backing store, the
|
|
Identity Service can use a directory server to provide the
|
|
Identity Service, for example:</para>
|
|
<programlisting language="ini">dn: dc=AcmeExample,dc=org
|
|
dc: AcmeExample
|
|
objectClass: dcObject
|
|
objectClass: organizationalUnit
|
|
ou: AcmeExample
|
|
|
|
dn: ou=Groups,dc=AcmeExample,dc=org
|
|
objectClass: top
|
|
objectClass: organizationalUnit
|
|
ou: groups
|
|
|
|
dn: ou=Users,dc=AcmeExample,dc=org
|
|
objectClass: top
|
|
objectClass: organizationalUnit
|
|
ou: users
|
|
|
|
dn: ou=Roles,dc=AcmeExample,dc=org
|
|
objectClass: top
|
|
objectClass: organizationalUnit
|
|
ou: roles</programlisting>
|
|
<para>The corresponding entries in the
|
|
<filename>keystone.conf</filename> configuration file
|
|
are:</para>
|
|
<programlisting language="ini">[ldap]
|
|
url = ldap://localhost
|
|
user = dc=Manager,dc=AcmeExample,dc=org
|
|
password = badpassword
|
|
suffix = dc=AcmeExample,dc=org
|
|
use_dumb_member = False
|
|
allow_subtree_delete = False
|
|
|
|
user_tree_dn = ou=Users,dc=AcmeExample,dc=com
|
|
user_objectclass = inetOrgPerson
|
|
|
|
tenant_tree_dn = ou=Groups,dc=AcmeExample,dc=com
|
|
tenant_objectclass = groupOfNames
|
|
|
|
role_tree_dn = ou=Roles,dc=AcmeExample,dc=com
|
|
role_objectclass = organizationalRole</programlisting>
|
|
<para>The default object classes and attributes are intentionally
|
|
simple. They reflect the common standard objects according to
|
|
the LDAP RFCs. However, in a live deployment, you can override
|
|
the correct attributes to support a preexisting, complex
|
|
schema. For example, in the user object, the objectClass
|
|
posixAccount from RFC2307 is very common. If this is the
|
|
underlying objectclass, then the <emphasis>uid</emphasis>
|
|
field should probably be <emphasis>uidNumber</emphasis> and
|
|
<emphasis>username</emphasis> field either
|
|
<emphasis>uid</emphasis> or <emphasis>cn</emphasis>. To
|
|
change these two fields, the corresponding entries in the
|
|
Keystone configuration file are:</para>
|
|
<programlisting language="ini">[ldap]
|
|
user_id_attribute = uidNumber
|
|
user_name_attribute = cn</programlisting>
|
|
<para>Depending on your deployment, you can modify a set of
|
|
allowed actions for each object type. For example, you might
|
|
set the following options:</para>
|
|
<programlisting language="ini">[ldap]
|
|
user_allow_create = False
|
|
user_allow_update = False
|
|
user_allow_delete = False
|
|
|
|
tenant_allow_create = True
|
|
tenant_allow_update = True
|
|
tenant_allow_delete = True
|
|
|
|
role_allow_create = True
|
|
role_allow_update = True
|
|
role_allow_delete = True</programlisting>
|
|
<para>If the back-end provides too much output, you can filter
|
|
users, tenants, and roles. For example:</para>
|
|
<programlisting language="ini">[ldap]
|
|
user_filter = (memberof=CN=acme-users,OU=workgroups,DC=AcmeExample,DC=com)
|
|
tenant_filter =
|
|
role_filter =</programlisting>
|
|
<para>If the directory server has not enabled the
|
|
<literal>boolean</literal> type for the user, you can use
|
|
configuration options to extract the value from an integer
|
|
attribute. For example, in an Active Directory, as
|
|
follows:</para>
|
|
<programlisting language="ini">[ldap]
|
|
user_enabled_attribute = userAccountControl
|
|
user_enabled_mask = 2
|
|
user_enabled_default = 512</programlisting>
|
|
<para>The attribute is an integer. Bit 1 contains the enabled
|
|
attribute. If the <emphasis>user_enabled_mask</emphasis> mask
|
|
is not 0, it gets its value from the
|
|
<option>user_enabled_attribute</option> field and it
|
|
performs an ADD operation by using the
|
|
<emphasis>user_enabled_mask</emphasis> value. If the value
|
|
matches the mask, the account is disabled.</para>
|
|
<para>It also saves the value without mask to the
|
|
<literal>identity</literal> user in the
|
|
<option>enabled_nomask</option> attribute. In case you
|
|
must change it to enable or disable a user, you can use this
|
|
value because it contains more information than the status
|
|
such as, password expiration. The
|
|
<emphasis>user_enabled_mask</emphasis> value is required
|
|
to create a default value on the integer attribute (512 =
|
|
NORMAL ACCOUNT on AD).</para>
|
|
<para>If Active Directory classes and attributes do not match the
|
|
specified classes in the LDAP module, so you can modify them,
|
|
as follows:</para>
|
|
<programlisting language="ini">[ldap]
|
|
user_objectclass = person
|
|
user_id_attribute = cn
|
|
user_name_attribute = cn
|
|
user_mail_attribute = mail
|
|
user_enabled_attribute = userAccountControl
|
|
user_enabled_mask = 2
|
|
user_enabled_default = 512
|
|
user_attribute_ignore = tenant_id,tenants
|
|
tenant_objectclass = groupOfNames
|
|
tenant_id_attribute = cn
|
|
tenant_member_attribute = member
|
|
tenant_name_attribute = ou
|
|
tenant_desc_attribute = description
|
|
tenant_enabled_attribute = extensionName
|
|
tenant_attribute_ignore =
|
|
role_objectclass = organizationalRole
|
|
role_id_attribute = cn
|
|
role_name_attribute = ou
|
|
role_member_attribute = roleOccupant
|
|
role_attribute_ignore =</programlisting>
|
|
</section>
|