Open Stack

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" <dolph.mathews at gmail.com>
> To: "Christopher Smith" <csmith at wolfram.com>
> Cc: "openstack" <openstack at lists.launchpad.net>
> 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 <
> csmith at 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
> 
> 

-- 
Christopher Smith
Systems Engineer, Wolfram Research