yahoo-eng-team team mailing list archive

[Lin Hua Cheng <1409635@xxxxxxxxxxxxxxxxxx>]

Posted the question on IRC.

The general consensus for LDAP assignment is we will be deprecating it
for Kilo: http://lists.openstack.org/pipermail/openstack-
dev/2015-January/055459.html

So any enhancement will be avoided, only security bugs will be taken in
for backport.

** Changed in: keystone
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1409635

Title:
  keystone fails to authenticate users when LDAP project_id_attribute is
  not CN

Status in OpenStack Identity (Keystone):
  Won't Fix

Bug description:
  When using a read-only LDAP backend with

  * project ID not being represented by CN as part of project DN, but some other attribute (Example: entryUUID provided by ApacheDS)
  * this attribute configured as project_id_attribute in keystone.conf

  all authentications fail, caused by failure to retrieve associated
  projects. The LDAP assignment backend still tries to extract the ID
  from project DN.

  Note that project_id_attribute is honored as such (see
  https://bugs.launchpad.net/keystone/+bug/1361306).  You can run
  "keystone tenant-list" and retrieve the correct result. So this
  problem is not a duplicate of the bug mentioned above. Instead the
  issue affecting authentication appears to be in

  keystone/assignment/backends/ldap.py

  in ProjectApi.get_user_projects(), which is

  1. Collecting all associated project DNs from user association
  2. Incorrectly mapping them to IDs, ignoring project_id_attribute
  3. Finally performing subtree searches for these incorrect IDs

  Instead, as the LDAP primary keys of the project entries are already
  known in first place, it should look them up directly without using
  the ID detour.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1409635/+subscriptions