Reviewed: https://review.openstack.org/25050 Committed: http://github.com/openstack/keystone/commit/4f75f848a5c33316b3b4ceec680575d68dfbcd6d Submitter: Jenkins Branch: milestone-proposed
commit 4f75f848a5c33316b3b4ceec680575d68dfbcd6d Author: Allan Feid <[email protected]> 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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
