Open Stack

should add.

The trick is an internal realm trusted KDC is necessary for FQDN ( Kerberos
) on the private IP ranges behind any openstack natting.

On Sat, Jul 14, 2012 at 12:12 PM, Matt Joyce <matt.joyce at cloudscaling.com>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/ed49d36f/attachment.html>