bootstrapping keystone failed when LDAP backend is in use

[Dave Chen]

"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/ldapobject.py", 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/ldapobject.py", 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/ldapobject.py", 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/ldapobject.py", 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/ldapobject.py", 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'}

[Dave Chen (wei-d-chen)]

patch is here: https://review.openstack.org/#/c/395967/

[Lance Bragstad (lbragstad)]

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)]

@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)]

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

[Steve Martinelli (stevemar)]

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)

[OpenStack Infra (hudson-openstack)]

Change abandoned by Dave Chen (<email address hidden>) on branch: master
Review: https://review.openstack.org/395967

[Lance Bragstad (lbragstad)]

Automatically unassigning due to inactivity.

[Lance Bragstad (lbragstad)]

I was able to recreate this using devstack:

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

$ cat local.conf
[[local|localrc]]
ADMIN_PASSWORD=password
DATABASE_PASSWORD=password
RABBIT_PASSWORD=password
SERVICE_PASSWORD=$ADMIN_PASSWORD
LDAP_PASSWORD=password
KEYSTONE_CLEAR_LDAP=yes
KEYSTONE_IDENTITY_BACKEND=ldap
ENABLED_SERVICES=rabbit,tempest,mysql,etcd3,dstat,key,horizon,ldap
LOGFILE=$DEST/logs/stack.sh.log
LOGDAYS=2

This results in the following keystone.conf:

[identity]
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

[identity]
driver = ldap

[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 stack.sh, you get the following error:

http://paste.openstack.org/show/618224/

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)]

I was able to successfully run stack.sh 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"
     fi
- iniset $KEYSTONE_CONF identity driver "$KEYSTONE_IDENTITY_BACKEND"
+ 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)]

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?

[0] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-08-11.log.html#t2017-08-11T20:45:37

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/493249

[Adam Young (ayoung)]

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.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Lance Bragstad (<email address hidden>) on branch: master
Review: https://review.opendev.org/493249

[Aaron Hicks (aethylred)]

> 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.

If I'm reading this right the expectation is that the 'default' domain that hosts the 'admin' project should _not_ have LDAP and just use SQL, but other domains can have LDAP in their domain-specific Keystone configuration files.

It should be clear in the documentation that LDAP should not be in the base keystone.conf, but configured as part of domain specific configuration.

Perhaps LDAP configuration in default keystone should be reported as an error.

[Martin Kopec (mkopec)]

Moving back to New as the associated patch got abandoned and removing assigned person due to long inactivity.

[Dr. Jens Harbott (j-harbott)]

If anyone wants to submit a fix for this in devstack, feel free to reopen, but since this hasn't happened in a long time, closing as won't fix for now.