[Openstack] Can somebody offer some help regarding Keystone interaction with LDAP in Essex?
csmith at wolfram.com
Thu Dec 20 19:49:30 UTC 2012
Well, keystone token-get works fine, as far as it goes. I've found a few other problems here. First I had a left-over dc=example,dc=com in the in the Role tree option which didn't help. Now that I don't, if I use SERVICE_ENDPOINT and SERVICE_TOKEN to authenticate directly to keystone, I can see that the roles exist:
# keystone role-get 037b09e5e80d4d31a275be084f27b5c3
| Property | Value |
| description | description |
| id | 037b09e5e80d4d31a275be084f27b5c3 |
| name | 037b09e5e80d4d31a275be084f27b5c3 |
Of course, there's a problem here; I can't put anything in the LDAP server that Openstack will recognize as giving a name other than simply the role ID to this role, which is probably a show stopper itself. If that weren't enough, it still isn't apparently looking any role information up when I try to authenticate. I now suspect that this is because the tenant's "enabled" attribute is also set by default to something ridiculous that won't fit in the default LDAP schema, so there's no "enabled" value. Perhaps it interprets this to mean that the tenant is disabled and refuses to do more.
I've attempted to change the tenant enabled attribute, but it seems that that option is only available post-essex. If any of this is close to correct, I suppose we may just need to go with the SQL identity backend until such time as we get Folsom set up and find that it actually has useful LDAP support.
Any other ideas?
----- 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"):
> 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 information.
> 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
Systems Engineer, Wolfram Research
More information about the Openstack