openstack-manuals/doc/admin-guide/source/keystone_integrate_identity_backend_ldap.rst
Joseph Robinson 2ce5b11b1a [User Guides] Rename Admin-Guide-Cloud to Admin-Guide
This patch changes the name of the Admin-Guide from the Cloud
Admin Guide to the Administrator guide. This affects the
filename in the repository, and references to cloud administrators
within the document texts.

1.) Changing instances of 'cloud administrator'
    to 'administrator'.

2.) Change links from '/admin-guide-cloud/' to
    '/admin-guide/' within the Admin Guide.

3.) Adjust .htaccess file.

Change-Id: I7f21a710e922981aa295afc0616de36fd819b523
Implements: blueprint user-guides-reorganised
2016-04-01 19:50:13 +09:00

6.9 KiB

Integrate Identity back end with LDAP

The Identity back end contains information for users, groups, and group member lists. Integrating the Identity back end with LDAP allows administrators to use users and groups in LDAP.

Important

For OpenStack Identity service to access LDAP servers, you must define the destination LDAP server in the keystone.conf file. For more information, see integrate-identity-with-ldap.

To integrate one Identity back end with LDAP

  1. Enable the LDAP Identity driver in the keystone.conf file. This allows LDAP as an identity back end:

    [identity]
    #driver = keystone.identity.backends.sql.Identity
    driver = keystone.identity.backends.ldap.Identity
  2. Create the organizational units (OU) in the LDAP directory, and define the corresponding location in the keystone.conf file:

    [ldap]
    user_tree_dn = ou=Users,dc=example,dc=org
    user_objectclass = inetOrgPerson
    
    group_tree_dn = ou=Groups,dc=example,dc=org
    group_objectclass = groupOfNames

    Note

    These schema attributes are extensible for compatibility with various schemas. For example, this entry maps to the person attribute in Active Directory:

    user_objectclass = person
  3. A read-only implementation is recommended for LDAP integration. These permissions are applied to object types in the keystone.conf:

    [ldap]
    user_allow_create = False
    user_allow_update = False
    user_allow_delete = False
    
    group_allow_create = False
    group_allow_update = False
    group_allow_delete = False

    Restart the OpenStack Identity service.

    Warning

    During service restart, authentication and authorization are unavailable.

To integrate multiple Identity back ends with LDAP

  1. Set the following options in the /etc/keystone/keystone.conf file:

    1. Enable the LDAP driver:

      [identity]
      #driver = keystone.identity.backends.sql.Identity
      driver = keystone.identity.backends.ldap.Identity
    2. Enable domain-specific drivers:

      [identity]
      domain_specific_drivers_enabled = True
      domain_config_dir = /etc/keystone/domains
  2. Restart the OpenStack Identity service.

    Warning

    During service restart, authentication and authorization are unavailable.

  3. List the domains using the dashboard, or the OpenStackClient CLI. Refer to the Command List for a list of OpenStackClient commands.

  4. Create domains using OpenStack dashboard, or the OpenStackClient CLI.

  5. For each domain, create a domain-specific configuration file in the /etc/keystone/domains directory. Use the file naming convention keystone.DOMAIN_NAME.conf, where DOMAIN_NAME is the domain name assigned in the previous step.

    Note

    The options set in the /etc/keystone/domains/keystone.DOMAIN_NAME.conf file will override options in the /etc/keystone/keystone.conf file.

  6. Define the destination LDAP server in the /etc/keystone/domains/keystone.DOMAIN_NAME.conf file. For example:

    [ldap]
    url = ldap://localhost
    user = dc=Manager,dc=example,dc=org
    password = samplepassword
    suffix = dc=example,dc=org
    use_dumb_member = False
    allow_subtree_delete = False
  7. Create the organizational units (OU) in the LDAP directories, and define their corresponding locations in the /etc/keystone/domains/keystone.DOMAIN_NAME.conf file. For example:

    [ldap]
    user_tree_dn = ou=Users,dc=example,dc=org
    user_objectclass = inetOrgPerson
    
    group_tree_dn = ou=Groups,dc=example,dc=org
    group_objectclass = groupOfNames

    Note

    These schema attributes are extensible for compatibility with various schemas. For example, this entry maps to the person attribute in Active Directory:

    user_objectclass = person
  8. A read-only implementation is recommended for LDAP integration. These permissions are applied to object types in the /etc/keystone/domains/keystone.DOMAIN_NAME.conf file:

    [ldap]
    user_allow_create = False
    user_allow_update = False
    user_allow_delete = False
    
    group_allow_create = False
    group_allow_update = False
    group_allow_delete = False
  9. Restart the OpenStack Identity service.

    Warning

    During service restart, authentication and authorization are unavailable.

Additional LDAP integration settings

Set these options in the /etc/keystone/keystone.conf file for a single LDAP server, or /etc/keystone/domains/keystone.DOMAIN_NAME.conf files for multiple back ends. Example configurations appear below each setting summary:

Filters

Use filters to control the scope of data presented through LDAP.

[ldap]
user_filter = (memberof=cn=openstack-users,ou=workgroups,dc=example,dc=org)
group_filter =
Identity attribute mapping

Mask account status values (include any additional attribute mappings) for compatibility with various directory services. Superfluous accounts are filtered with user_filter.

Setting attribute ignore to list of attributes stripped off on update.

For example, you can mask Active Directory account status attributes in the keystone.conf file:

[ldap]
user_id_attribute      = cn
user_name_attribute    = sn
user_mail_attribute    = mail
user_pass_attribute    = userPassword
user_enabled_attribute = userAccountControl
user_enabled_mask      = 2
user_enabled_invert    = false
user_enabled_default   = 51
user_default_project_id_attribute =
user_attribute_ignore = default_project_id,tenants
user_additional_attribute_mapping =

group_id_attribute     = cn
group_name_attribute   = ou
group_member_attribute = member
group_desc_attribute   = description
group_attribute_ignore =
group_additional_attribute_mapping =
Enabled emulation

An alternative method to determine if a user is enabled or not is by checking if that user is a member of the emulation group.

Use DN of the group entry to hold enabled user when using enabled emulation.

[ldap]
user_enabled_emulation = false
user_enabled_emulation_dn = false

When you have finished configuration, restart the OpenStack Identity service.

Warning

During service restart, authentication and authorization are unavailable.