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.<br><br>Kerberos requires FQDNs and therefore you will need it sitting behind any nat.<br>
<br>That Kerberos should have a trust back to AD.<br><br>Architecturally that's the only way that makes any sense all. <br><br>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.<br>
<br>That would provide a read only KDC.<br><br>Not sure that has any impact on the solutions mentioned. From my experience it does not.<br><br>What I had envisioned originally was passing keystone auth tokens inside of kerberos ticket comment fields.<br>
<br>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.<br>
<br>Maybe I was looking at it backwards. Maybe what I really want is a comment field inside of keystone API for querying the ticket.<br><br>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.<br>
<br>In a similar fashion we probably want the kdc somewhere useful as well.<br><br>-Matt<br><br><br><div class="gmail_quote">On Tue, Jul 17, 2012 at 2:34 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 07/17/2012 05:22 PM, Adam Young wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For Kerberos, I would suggest the following:<br>
<br>
1. Run Keystone in Apache HTTP with mod_auth_kerberos. It can fall back to userID/password.<br>
2. Modify the authentication mechanisms so that it checks REMOTE_USER the same way it currently checks USERID/password when providing a token<br>
<br>
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.<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.<u></u>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a><br>
</blockquote></div></div>
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.<br>
<br>
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.<div class="HOEnZb">
<div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.<u></u>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a><br>
</div></div></blockquote></div><br>