Thanks guys That's interesting the doc also mentions a couple of environment variable which I might be able to put in the appropriate /etc/sysconfig file, one of which I knew about but hadn't thought of. I'll do some experimenting when I get back into the office on Sunday. The other thing that occurred to me is I could use saslauthd as a proxy to translate an other mechanism into GSSAPI but I've never liked to use that method if I could avoid it because it weakens the security but at least its better than a local SASL password file. The other thing is the RHEL init script expects you only to have one instance running at any time which is not quite the intended behaviour for saslauthd. You can actually spawn an instance for each Mechanism you want to proxy into your target mechanism the standard RHEL script only allows you to proxy one mechanism which means you have to pick the lowest common denominator. SuSE use to support running an instance for each mechanism back in the early 2000's and it always worked well with my LDAP 3 servers providing support for old or broken clients. <div style="font-family: arial, sans-serif; font-size: 12px;color: #999999;">-- Sent from my HP Pre3</div> <hr align="left" style="width:75%">On Oct 31, 2013 10:31, Simo Sorce <simo@redhat.com> wrote: On Thu, 2013-10-31 at 09:41 -0400, Adam Young wrote: > On 10/30/2013 12:14 PM, Paul Robert Marino wrote: > > Ive been looking over this doc because I would like to secure the > > backend component of openstack with Kerberos. > > http://openstack.redhat.com/Keystone_integration_with_IDM > > > > I don't want to do a full IPA server for this just Kerberos which for > > the most part is fairly simple. > > I already have preexisting Heimdal Kerberos 5 server cluster from an > > other project which I can utilize in the environment which works fine > > with the MIT client libraries and does its own replication without > > using LDAP as a backend. > > > > so far most of it seems fairly strait forward but I found one thing I > > found in the doc thats messy and was hoping the doc is out of date and > > maybe there was a cleaner solution. here is what I have an issue with > > > > " > > > > The problem with this is that the key we just obtained is only good > > for a specified period of time: 24 hours by default. Once 24 hours > > passes the Kerberos ticket will no longer be valid and nova and cinder > > will no longer be able to communicate with qpidd. > > > > The fix for now is to create a cron job which will renew these credentials. > > > > > > " > > I also assume the same would be true for all of the openstack services > > not just nova and cinder, > > has the ability to specify and utilize a keytab been added or does any > > one know if there are any plans to add the feature in the future. If > > not who should I be nagging :-) . > > Really it needs to be added to all of the openstack services it it > > isn't there already > > It is a shortcoming addressed at the GSSAPI level, but that code is not > in the RHEL 6 series yet. In the future, you will be able to put a > Keytab in the appropriate subdirectory under /var/run and the new TGT > will be fetched upon demand. > > Simo Sorce was involved with the projkect to do that and can provide > more details. This is the MIT project page: http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation It boils down to putting a keytab in /var/kerberos/krb5/user/<euid>/client.keytab and then make gssapi initiation calls without trying to check for credentials using direct krb5 calls or anything like that. not all the software does the right thing yet, but we will collaborate with authors and help fix what doesn't work. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ rhos-list mailing list rhos-list@redhat.com https://www.redhat.com/mailman/listinfo/rhos-list