Make sure you're specifying a tenant (e.g. OS_TENANT_NAME) in order to receive authorization (e.g. the admin role) to perform nova list. You can debug the authn/authz process using "keystone token-get" (this doc is for folsom, but should work for essex, although the arguments may have changed, check "keystone --help"):
http://docs.openstack.org/trunk/openstack-compute/install/apt/content/verifying-identity-install.html If you're running into issues between your LDAP schema and what keystone Essex expects, it's worth pointing out that keystone became a lot more flexible in terms of LDAP configuration in Folsom. -Dolph On Tue, Dec 18, 2012 at 3:07 PM, Christopher Smith <csm...@wolfram.com>wrote: > 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 >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp