Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121218/a230afca/attachment.html>