[Openstack-operators] Keystone and Active Directory

Matt Joyce matt.joyce at cloudscaling.com
Sat Jul 14 20:28:32 UTC 2012

More or less.  I think it only really ties into the API in so far as a
tighter integration between keystone and instance authentication can allow
for a cleaner user experience.

Added benefit

 Unlike injected keys, a keystone tie into authentication would be able to
disable instance authentication in the event a user in a shared project was


On Sat, Jul 14, 2012 at 12:53 PM, Joseph Heck <heckj at mac.com> wrote:

> Thanks Matt - interesting detail, and a bit beyond what I was originally
> asking :-) I
> 'm not sure I understand the benefit you're getting with the cross-realm
> setup and how you'd want to deploy it. I think the description detail below
> is primarily concerned with pure authentication - more into the instances
> that you might spin up than just accessing OpenStack APIs, and not
> asserting anything about mapping groups in AD to either roles or projects.
> Am I reading that correctly?
> - joe
> On Jul 14, 2012, at 12:12 PM, Matt Joyce wrote:
> One thing I'd love to see eventually with Active Directory would be
> kerberos ticket passing and mapping to authentication tokens in keystone.
> We discussed an early integration effort with keystone at one customer
> site and we got to the point where we decided the best means of handling it
> ( at the time ) was to simply setup a Kerb 5 KDC with a cross realm trust
> to the AD environment then perform a binary check against the kdc for pass
> / user and pull the rest of the posix data from local keystone ldap.
> What I would like to see eventually is a means of authenticating to AD via
> keystone and getting the kerb 5 ticket passed to user instances so that
> users can perform passwordless gssapi ticket auth.  Also query the keystone
> API once authenticated for a keystone auth token and all of the associated
> env data for the user to use client apis.
> Along these same lines... I really want to see the keystone ec2 url path
> placed into the metadata api so that instances can query the path to the
> Keystone API.  I think I am just going to go ahead and submit a patch for
> that.  It really should be there.  I know some folks disagree with that,
> but I think the benefits outweigh the academic arguments vastly.
> -Matt
> On Sat, Jul 14, 2012 at 11:55 AM, Joseph Heck <heckj at mac.com> wrote:
>> Good morning,
>> I wanted to solicit some detail from y'all as operators. I'm starting in
>> on development for a Keystone backend that does basic Authentication
>> against an existing active directory.
>> Looking forward past basic authentication, there's several potentials in
>> how to implement this, and I'm curious among several possibilities what you
>> all would find most useful. I'd love feedback on which of these you'd find
>> most useful, and of course if there's a variation on the theme that would
>> "rock your world", please tell me about it.
>> 1) no explicit mapping to active directory groups, projects and roles
>> managed externally to active directory, with a users in active directory
>> getting assigned to those projects and roles, but using the credentials
>> (userid/password) from active directory.
>> 2) using active directory groups to assign roles to users, regardless of
>> tenant. This would be storing "projects" and links of users to projects
>> external to active directory, but using active directory groups to define
>> what "roles" a user should have within their project(s).
>> 3) using active directory groups to represent projects, with membership
>> in the group simply implying a "membership" style role with broad
>> capabilities in the project.
>> The quandary I'm facing is that I'm not sure how y'all are using groups
>> and what they represent to you, and what that *could* mean to an OpenStack
>> deployment in your organization. Any and all feedback welcome - either back
>> to this list, or directly to me: Joe Heck (heckj at mac.com)
>> -joe
>> Keystone PTL
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120714/2ac59b2c/attachment.html>

More information about the Openstack-operators mailing list