Mailing List Archive: OpenStack: Operators

Keystone and Active Directory

Index | Next | Previous | View Threaded

heckj at mac

Jul 14, 2012, 11:55 AM

Post #1 of 10 (779 views)
Permalink

Keystone and Active Directory

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)

-joe
Keystone PTL

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators [at] lists
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

matt.joyce at cloudscaling

Jul 14, 2012, 12:12 PM

Post #2 of 10 (762 views)
Permalink

Re: Keystone and Active Directory [In reply to]

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> 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)
>
> -joe
> Keystone PTL
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

matt.joyce at cloudscaling

Jul 14, 2012, 12:13 PM

Post #3 of 10 (778 views)
Permalink

Re: Keystone and Active Directory [In reply to]

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>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> 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)
>>
>> -joe
>> Keystone PTL
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators [at] lists
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>

heckj at mac

Jul 14, 2012, 12:53 PM

Post #4 of 10 (758 views)
Permalink

Re: Keystone and Active Directory [In reply to]

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> 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)
>
> -joe
> Keystone PTL
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

matt.joyce at cloudscaling

Jul 14, 2012, 1:28 PM

Post #5 of 10 (759 views)
Permalink

Re: Keystone and Active Directory [In reply to]

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
removed.

-Matt

On Sat, Jul 14, 2012 at 12:53 PM, Joseph Heck <heckj [at] mac> 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> 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)
>>
>> -joe
>> Keystone PTL
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators [at] lists
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
>

Jan.van.Eldik at cern

Jul 16, 2012, 1:28 AM

Post #6 of 10 (756 views)
Permalink

Re: Keystone and Active Directory [In reply to]

Hello Joe,

For us, option (3) is best. At CERN, our customers already manage their
Active Directory groups for many other applications.

The LHC experiments have 1000s of collaborators, who are organized in
1000s of AD groups. We want to delegate tenant management to the
experiment coordinators, and a full AD integration with our account
lifecycle management will ensure consistencies.

Let us know if you need any clarification (or help with testing).

cheers, Jose & Jan

On 07/14/2012 08:55 PM, Joseph Heck 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)
>
> -joe
> Keystone PTL
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators [at] lists
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

jaypipes at gmail

Jul 16, 2012, 9:33 AM

Post #7 of 10 (758 views)
Permalink

Re: Keystone and Active Directory [In reply to]

On 07/14/2012 02:55 PM, Joseph Heck wrote:
> 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.

Make it a configurable option in Keystone. Something like:

# What entity is the Active Directory group?
# Options: 'project' (default), 'role', '' (ignore groups)
ad_group_entity = 'project'

We do a similar thing in Glance with the:

owner_is_tenant = True

option, where setting to False indicates that the *X-Auth-User* value
and not the X-Auth-Tenant is the owner of an image...

Also, I will bring up that Keystone changing its semantics from "tenant"
to "project" affects a lot more than Keystone... Is the Keystone v3 API
-- the API which changes to use the term project instead of tenant --
going to be backwards-compatible with the term "tenant"?

Best,
-jay

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators [at] lists
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

ayoung at redhat

Jul 17, 2012, 2:22 PM

Post #8 of 10 (748 views)
Permalink

Keystone and Active Directory [In reply to]

For Kerberos, I would suggest the following:

1. Run Keystone in Apache HTTP with mod_auth_kerberos. It can fall
back to userID/password.
2. Modify the authentication mechanisms so that it checks REMOTE_USER
the same way it currently checks USERID/password when providing a token

Cross realm trust is a nice-to-have, but I suspect that it is not up to
Keystone to implement, but rather something that needs to be set up
correctly Kerberos wise. Once Kerberos Auth works, cross realm should
work, too.

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators [at] lists
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

ayoung at redhat

Jul 17, 2012, 2:34 PM

Post #9 of 10 (763 views)
Permalink

Re: Keystone and Active Directory [In reply to]

On 07/17/2012 05:22 PM, Adam Young wrote:
> For Kerberos, I would suggest the following:
>
> 1. Run Keystone in Apache HTTP with mod_auth_kerberos. It can fall
> back to userID/password.
> 2. Modify the authentication mechanisms so that it checks REMOTE_USER
> the same way it currently checks USERID/password when providing a token
>
> Cross realm trust is a nice-to-have, but I suspect that it is not up
> to Keystone to implement, but rather something that needs to be set up
> correctly Kerberos wise. Once Kerberos Auth works, cross realm should
> work, too.
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
As far as using the Kerberos ticket in place of the Keystone tokens, the
issue is that the other services (Glance, Nova etc) are running in
eventlet as well, and thus Kerberos support would need to be ported
upstream. This is non-trivial, as the Kerberos API is native, which
means the GIL will kick in. (Reimplementing Kerberos in Python is not a
viable option). The GIL might not be a show stopper, but I wouldn't
want to count on it. It does mean some native extension would be needed,
though. I am just not sure it is worth putting the effort into that.

If all of the service can be run in Apache HTTPD, you could, in theory,
replace the auth_token middleware with a new middleware
auth_service_ticket, that again would just check for the REMOTE_USER
value. You would still need to make a call back to Keystone in order to
get Tenant/Project info. in addition, you could not pass on the
service ticket the way that you do the tokens, so Horizon talking to
Nova and Glance would not work without something like TGT forwarding,
which I don't think we would want to do, either. So I think, shortish
term, using the Kerberos credentials to get the Token is still the
right approach. I'd be interesting in hearing a counter argument.

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators [at] lists
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

matt.joyce at cloudscaling

Jul 17, 2012, 2:48 PM

Post #10 of 10 (749 views)
Permalink

Re: Keystone and Active Directory [In reply to]

The way I see it architecturally, the only way that Kerberos will work in
an openstack deployment is to have a KDC installed along side the rest of
the supporting infrastructure.

Kerberos requires FQDNs and therefore you will need it sitting behind any
nat.

That Kerberos should have a trust back to AD.

Architecturally that's the only way that makes any sense all.

One possible mitigating deployment strategy to satisfy anal security teams
may be to deploy one of those new read only domain managers windows 2008
has into the openstack environment.

That would provide a read only KDC.

Not sure that has any impact on the solutions mentioned. From my
experience it does not.

What I had envisioned originally was passing keystone auth tokens inside of
kerberos ticket comment fields.

I know that MS loves to use that field... but zeroing that data may be to
our benefit if we can as MS AD comment field length can exceed existing
Kerb5 ticket specs and cause damage. Also having the auth token in a
readily identifiable location in the ticket makes it easy to work with.

Maybe I was looking at it backwards. Maybe what I really want is a comment
field inside of keystone API for querying the ticket.

I figure any which way you do it, keystone will need to query against the
AD kdc and a ticket will be issued. We just need to trap it and put it
somewhere useful.

In a similar fashion we probably want the kdc somewhere useful as well.

-Matt

On Tue, Jul 17, 2012 at 2:34 PM, Adam Young <ayoung [at] redhat> wrote:

> On 07/17/2012 05:22 PM, Adam Young wrote:
>
>> For Kerberos, I would suggest the following:
>>
>> 1. Run Keystone in Apache HTTP with mod_auth_kerberos. It can fall back
>> to userID/password.
>> 2. Modify the authentication mechanisms so that it checks REMOTE_USER
>> the same way it currently checks USERID/password when providing a token
>>
>> Cross realm trust is a nice-to-have, but I suspect that it is not up to
>> Keystone to implement, but rather something that needs to be set up
>> correctly Kerberos wise. Once Kerberos Auth works, cross realm should
>> work, too.
>>
>>
>> ______________________________**_________________
>> OpenStack-operators mailing list
>> OpenStack-operators [at] lists**openstack.org<OpenStack-operators [at] lists>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**
>> openstack-operators<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
>>
> As far as using the Kerberos ticket in place of the Keystone tokens, the
> issue is that the other services (Glance, Nova etc) are running in eventlet
> as well, and thus Kerberos support would need to be ported upstream. This
> is non-trivial, as the Kerberos API is native, which means the GIL will
> kick in. (Reimplementing Kerberos in Python is not a viable option). The
> GIL might not be a show stopper, but I wouldn't want to count on it. It
> does mean some native extension would be needed, though. I am just not
> sure it is worth putting the effort into that.
>
> If all of the service can be run in Apache HTTPD, you could, in theory,
> replace the auth_token middleware with a new middleware
> auth_service_ticket, that again would just check for the REMOTE_USER value.
> You would still need to make a call back to Keystone in order to get
> Tenant/Project info. in addition, you could not pass on the service
> ticket the way that you do the tokens, so Horizon talking to Nova and
> Glance would not work without something like TGT forwarding, which I don't
> think we would want to do, either. So I think, shortish term, using the
> Kerberos credentials to get the Token is still the right approach. I'd be
> interesting in hearing a counter argument.
>
>
>
> ______________________________**_________________
> OpenStack-operators mailing list
> OpenStack-operators [at] lists**openstack.org<OpenStack-operators [at] lists>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**
> openstack-operators<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
>

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads