bootstrapping keystone failed when LDAP backend is in use

Bug #1643301 reported by Dave Chen on 2016-11-20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Lance Bragstad

Bug Description

"keystone-manage bootstrap" command is coded for SQL backend, it's should be okay if admin token is always supported by keystone, but we have a plan to remove the support of admin token since it's expose a security risk. And the patch to remove the support of write operation for LDAP backend is on the fly.

Based on the above consideration, we should enable the bootrapping keystone when using LDAP backend, but it currently not work sometimes, for example.

# keystone-manage bootstrap --bootstrap-username Dave --bootstrap-password abc123 --bootstrap-project-name admin --bootstrap-role-name admin

 2016-10-27 16:26:29.845 11359 TRACE keystone return self.result(msgid,all=1,timeout=self.timeout)
 2016-10-27 16:26:29.845 11359 TRACE keystone File "/usr/local/lib/python2.7/dist-packages/ldap/", line 497, in result
 2016-10-27 16:26:29.845 11359 TRACE keystone resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
 2016-10-27 16:26:29.845 11359 TRACE keystone File "/usr/local/lib/python2.7/dist-packages/ldap/", line 501, in result2
 2016-10-27 16:26:29.845 11359 TRACE keystone resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
 2016-10-27 16:26:29.845 11359 TRACE keystone File "/usr/local/lib/python2.7/dist-packages/ldap/", line 508, in result3
 2016-10-27 16:26:29.845 11359 TRACE keystone resp_ctrl_classes=resp_ctrl_classes
 2016-10-27 16:26:29.845 11359 TRACE keystone File "/usr/local/lib/python2.7/dist-packages/ldap/", line 515, in result4
 2016-10-27 16:26:29.845 11359 TRACE keystone ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
 2016-10-27 16:26:29.845 11359 TRACE keystone File "/usr/local/lib/python2.7/dist-packages/ldap/", line 106, in _ldap_call
 2016-10-27 16:26:29.845 11359 TRACE keystone result = func(*args,**kwargs)
 2016-10-27 16:26:29.845 11359 TRACE keystone UNDEFINED_TYPE: {'info': 'enabled: attribute type undefined', 'desc': 'Undefined attribute type'}

Changed in keystone:
assignee: nobody → Dave Chen (wei-d-chen)
status: New → In Progress
Lance Bragstad (lbragstad) wrote :

Where does the bootstrap command take into account the admin token? I thought bootstrap didn't need it because it used the managers directly, bypassing the protected checks at the controller layer.

Also, bootstrap makes sense from a SQL perspective, but I can't imagine anyone wanting to bootstrap an LDAP deployment.

Dave Chen (wei-d-chen) wrote :

@Lance, imagine the case you only have identity ldap backend in place, and user/group are from LDAP server side, how to use it? If it's SQL backend we can bootstrap an admin user (typically the user will be grant access to the resource) but is that possible for LDAP backend? The only way I think is using admin token. But
given admin token should be deprecated for security risk, any other way we can handle with the case?

Lance Bragstad (lbragstad) wrote :

Does this conflict with our goal to make LDAP read-only? I know we removed some read/write LDAP support recently.

Steve Martinelli (stevemar) wrote :

I think we want to encourage folks to use SQL for keystone users and per-domain LDAP for LDAP users. That's the model we've been encouraging for a while, not the single LDAP model (with an "admin" and other service accounts in LDAP)

Changed in keystone:
importance: Undecided → Wishlist

Change abandoned by Dave Chen (<email address hidden>) on branch: master

Lance Bragstad (lbragstad) wrote :

Automatically unassigning due to inactivity.

Changed in keystone:
assignee: Dave Chen (wei-d-chen) → nobody
status: In Progress → Triaged
Lance Bragstad (lbragstad) wrote :
Download full text (5.5 KiB)

I was able to recreate this using devstack:

keystone sha: fe20e5a9a73a2bc075af0990f285c9102c96d1b6
devstack sha: 98ab7d9646730f02983380648831aa2682abcc0c
platform: ubuntu 16.04 container

$ cat local.conf

This results in the following keystone.conf:

password_hash_rounds = 4
driver = ldap
domain_specific_drivers_enabled = True
domain_config_dir = /etc/keystone/domains

This is the contents of my domain specific configuration:

$ cat /etc/keystone/domains/keystone.Users.conf

driver = ldap

group_id_attribute = cn
group_name_attribute = cn
group_objectclass = groupOfNames
group_tree_dn = ou=Groups,dc=openstack,dc=org
password = password
suffix = dc=openstack,dc=org
url = ldap://localhost
user = cn=Manager,dc=openstack,dc=org
user_id_attribute = uid
user_mail_attribute = mail
user_name_attribute = cn
user_objectclass = inetOrgPerson
user_tree_dn = ou=Users,dc=openstack,dc=org
user_allow_create = False
user_allow_update = False
user_allow_delete = False
group_allow_create = False
group_allow_update = False
group_allow_delete = False

When running, you get the following error:

2017-08-11 19:20:54.435 | CRITICAL keystone [None req-94d4890f-dbdd-4542-99b7-02af075de5d0 None None] Unhandled error: Forbidden: You are not au...


Lance Bragstad (lbragstad) wrote :

I was able to successfully run with ldap configured after making the following change to devstack:

diff --git a/lib/keystone b/lib/keystone
index 1061081..8a4061b 100644
--- a/lib/keystone
+++ b/lib/keystone
@@ -223,7 +223,7 @@ function configure_keystone {
         iniset $KEYSTONE_CONF identity domain_config_dir "$KEYSTONE_CONF_DIR/domains"
         iniset $KEYSTONE_CONF identity domain_specific_drivers_enabled "True"
+ iniset $KEYSTONE_CONF identity driver "sql"
     iniset $KEYSTONE_CONF identity password_hash_rounds $KEYSTONE_PASSWORD_HASH_ROUNDS
     iniset $KEYSTONE_CONF assignment driver "$KEYSTONE_ASSIGNMENT_BACKEND"
     iniset $KEYSTONE_CONF role driver "$KEYSTONE_ROLE_BACKEND"

That sets the identity driver in keystone's main configuration file to always be `sql`. The KEYSTONE_IDENTITY_BACKEND parameter is still used to configured LDAP for the Users domain. This is the typical configuration we recommend today with per-domain-ldap, and leaves sql as the default (which doesn't interfere with bootstrapping).

Lance Bragstad (lbragstad) wrote :

This was discussed with Colleen and Kristi in IRC [0]. The following was proposed

 - write a patch so that devstack always configures sql as the identity backend
 - when ldap is set as KEYSTONE_IDENTITY_BACKEND, ensure it's done in a domain-specific way
 - write a patch so keystone fails gracefully with an informative warning saying `bootstrap` is only intended for sql-based deployments

Thoughts on the approach?


Fix proposed to branch: master

Changed in devstack:
assignee: nobody → Lance Bragstad (lbragstad)
status: New → In Progress
Changed in devstack:
importance: Undecided → Wishlist
Adam Young (ayoung) wrote :

I'm closing this Won't fix because running with the LDAP backend is a bad approach. Use SQL, with LDAP in a domain specific back end.

Changed in keystone:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers