openstack team mailing list archive

[Christopher Smith <csmith@xxxxxxxxxxx>]

Hey everybody,

We're trying very hard to build an Openstack cluster here, and I've been running into some trouble with the Keystone LDAP identity backend.  I have every expectation that this is just something I have misconfigured, but honestly the documentation seems somewhat lacking for this, so I haven't been able to figure out what is going wrong.

Here's the current situation:

We have gotten an entire Openstack installation working, using the SQL backends to keystone.  We're currently trying to move the identity into LDAP.  This has caused a few problems, but the one I'm stuck on at the moment is that the admin user seems not to be associated with the admin role.  Nor does keystone seem to be attempting at all to look up role information.  

The relevant section of keystone.conf looks like:

[ldap]
url = ldap://ldap.wolfram.com
tree_dn = ou=OpenStack,dc=wolfram,dc=com
user_tree_dn = ou=Users,ou=OpenStack,dc=wolfram,dc=com
role_tree_dn = ou=Roles,ou=OpenStack,dc=example,dc=com
tenant_tree_dn = ou=Groups,ou=OpenStack,dc=wolfram,dc=com
user = cn=directory,ou=misc,ou=OpenStack,dc=wolfram,dc=com
password = redacted (but the bind is successful)
suffix = cn=wolfram,cn=com

Now, I've captured the traffic between keystone and ldap for when I execute any nova operation, say, nova list.  What I get is a set of successful binds as cn=directory, a search request against ou=Users, one against ou=Groups, one for admin's UID in ou=Users, then re-bind as the Admin object -- also successful, so I assume I'm authenticated. Next I have a search by ID for the admin group.  This, depending on the operation, might be repeated along with additional lookups for the lists of users and groups against the corresponding OUs.  Anyway, all of this looks reasonable to me, expect that it doesn't appear to ever be trying to assign roles, which I'd like for it to do.

My LDAP structure looks like this:

ou=OpenStack
  ou=Groups
    Contains a set of groupOfNames objects with cn=id,ou=name member=DN of member.  Our tenants are stored here.
  ou=misc
    This is just a place to stick the keystone directory user for the initial bind.
  ou=Roles
    Contains a set of organizationalRole objects with ou=name, cn=id, roleOccupant=DN of member
  ou=Users
    Contains a set of inetOrgPerson objects with ou=username and cn=id

Any ideas what I'm missing?

Chris

-- 
Christopher Smith
Systems Engineer, Wolfram Research