yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #01756
[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