a3165ca60c
Added instructions on how to secure the connection between the keystone host and LDAP server. This patch also includes some edits to the instructions for setting up Assignments, among them is splitting it off to a different XML file (for easier management). Change-Id: I63c19bc034d52efd9e7235c14cd3f0d78d5ae275 Closes-Bug: #1290605
135 lines
5.3 KiB
XML
135 lines
5.3 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. You can override object attributes to map to a
|
|
pre-existing schema. For example, RFC2307-compliant posixAccount
|
|
objects will commonly include the <emphasis>uid</emphasis>
|
|
and <emphasis>cn</emphasis> attributes. These fields can be
|
|
mapped to their corresponding entries in the
|
|
<filename>keystone.conf</filename> file:
|
|
</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 these 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, set these
|
|
configuration options:</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>
|
|
<xi:include href="section_keystone_config_ldap-assignments.xml"/>
|
|
<xi:include href="section_keystone_config_ldap-hardening.xml"/>
|
|
</section>
|