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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
