[Openstack] Can somebody offer some help regarding Keystone interaction with LDAP in Essex?
dolph.mathews at gmail.com
Tue Dec 18 23:57:59 UTC 2012
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"):
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.
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
> The relevant section of keystone.conf looks like:
> 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:
> Contains a set of groupOfNames objects with cn=id,ou=name member=DN of
> member. Our tenants are stored here.
> This is just a place to stick the keystone directory user for the
> initial bind.
> Contains a set of organizationalRole objects with ou=name, cn=id,
> roleOccupant=DN of member
> Contains a set of inetOrgPerson objects with ou=username and cn=id
> Any ideas what I'm missing?
> 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...
More information about the Openstack