← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1153786] Re: ldap dereferencing is broken in the ldap backend

 

Reviewed:  https://review.openstack.org/25050
Committed: http://github.com/openstack/keystone/commit/4f75f848a5c33316b3b4ceec680575d68dfbcd6d
Submitter: Jenkins
Branch:    milestone-proposed

commit 4f75f848a5c33316b3b4ceec680575d68dfbcd6d
Author: Allan Feid <allanfeid@xxxxxxxxx>
Date:   Mon Mar 11 23:11:52 2013 -0400

    Add a dereference option for ldap
    
    This allows proper dereferencing of aliased objects in an LDAP tree.
    
    Fixes Bug #1153786
    
    Change-Id: Ia09a99b7bca1ab055eb0c6dfa34138beca15bff0


** Changed in: keystone
       Status: Fix Committed => Fix Released

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

Title:
  ldap dereferencing is broken in the ldap backend

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  Today I attempted to configure the LDAP backend with my existing
  schema. I wanted to accomplish a scenario where the keystone client
  can still manage roles/tenants/service users but also maintain my
  existing users via an outside tool. The reason for this is a pretty
  simple one, my LDAP infrastructure is for posix account login and I do
  not want service accounts polluting my main tree or potentially
  allowing these accounts to get shell access. To do this, I came up
  with the following schema for openstack:

  dn: ou=openstack,dc=example,dc=net
  objectclass: top
  objectclass: organizationalUnit
  ou: openstack

  dn: ou=users,ou=openstack,dc=example,dc=net
  objectclass: top
  objectclass: organizationalUnit
  ou: users

  dn: ou=roles,ou=openstack,dc=example,dc=net
  objectclass: top
  objectclass: organizationalUnit
  ou: roles

  dn: ou=tenants,ou=openstack,dc=example,dc=net
  objectclass: top
  objectclass: organizationalUnit
  ou: tenants

  dn: ou=posix_accounts,ou=users,ou=openstack,dc=example,dc=net
  objectclass: alias
  objectclass: extensibleObject
  aliasedobjectname: ou=People,dc=example,dc=net

  In this case a simple subtree query with dereferencing set to always
  or search for objectclass=inetOrgPerson returns something similar to
  the following:

  $ ldapsearch -a search -ZZxD 'cn=Manager,dc=example,dc=net' -H ldap:/// -b ou=openstack,dc=example,dc=net -W -s subtree '(&(uid=afeid)(objectClass=inetOrgPerson))'
  Enter LDAP Password: 

  # extended LDIF
  #
  # LDAPv3
  # base <ou=openstack,dc=example,dc=net> with scope subtree
  # filter: (&(uid=afeid)(objectClass=inetOrgPerson))
  # requesting: ALL
  #

  # afeid, People, example.net
  dn: uid=afeid,ou=People,dc=example,dc=net
  objectClass: posixAccount
  objectClass: inetOrgPerson
  uid: afeid
  gidNumber: 10000
  uidNumber: 10031
  homeDirectory: /home/afeid
  loginShell: /bin/bash
  ..etc..

  # search result
  search: 3
  result: 0 Success

  # numResponses: 2
  # numEntries: 1

  That is great, but upon investigation of the core/identity ldap code
  in the master branch of keystone, it becomes obvious that there are a
  lot of assumtions about what the DN of a user should look like (as is
  necessary). I managed to get dereferences working with a simple:

  self.conn.set_option(ldap.OPT_DEREF, ldap.DEREF_ALWAYS)

  But after successfully finding a valid user via UserApi.get_by_name,
  the next step is to throw away the found DN because
  Identity.authenticate is called. In this method, the user's DN is
  reconstructed based on your configurations, which is incorrect and
  breaks the ability to do dereferencing.

  I'd love to get my schema working since it provides the ability to
  give openstack its own bind dn that is limited to a subset of my full
  tree while still working with an externally managed master user tree.
  I can help contribute, but am unsure how to proceed since I don't know
  how to pass the results from the UserApi.get_by_name method to the
  Identity.authenticate method.

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