Thanks, Dolph. I have the following Openstack related variables set: OS_AUTH_URL=http://127.0.0.1:5000/v2.0/ OS_PASSWORD=admin OS_REGION_NAME=WRI OS_TENANT_NAME=admin OS_USERNAME=admin
This worked fine for the SQL identity backend, and I've tried to replicate that exact setup into LDAP. I'll poke around with the token-get command later today. Chris ----- Original Message ----- > From: "Dolph Mathews" <[email protected]> > To: "Christopher Smith" <[email protected]> > Cc: "openstack" <[email protected]> > Sent: Tuesday, December 18, 2012 5:57:59 PM > Subject: Re: [Openstack] Can somebody offer some help regarding Keystone > interaction with LDAP in Essex? > > > 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 < > [email protected] > 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 : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > -- Christopher Smith Systems Engineer, Wolfram Research _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
