[Openstack] Can somebody offer some help regarding Keystone interaction with LDAP in Essex?

Christopher Smith csmith at wolfram.com
Tue Dec 18 21:07:56 UTC 2012

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:

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:

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

Any ideas what I'm missing?


Christopher Smith
Systems Engineer, Wolfram Research

More information about the Openstack mailing list