Bug 674578

The fix for this will not arrive in time for the 8/15 deadline.  I've set the exception flag to '?' to consider this fix for inclusion in a later update.

You should consider running SSSD in this case on the same host. It currently can take care of renewing ticket for a logged in user for the cases when user starts a background job and leaves for a long weekend. It would be easy to extend it to renew tickets for other principals on the system including the one for the QPID broker. Is this an acceptable solution instead of implementing it natively?

Ok I think I know the answer. It is not SSSD. 

Would that utility meet your needs?
http://www.eyrie.org/~eagle/software/kstart/k5start.html

@dmitri: yes, at first glance it looks like kstart would make sense.  However, the question is how to integrate this nicely with all QMF agents that are running.  Should this be something that is handled by the core QMF libs when an agent is started? 

Ted, what are your thoughts?

It should be a part of the post installation configuration and keytab provisioning. Whatever configures the use of kerberos on the broker should configure the k5start to renew the tickets for it.

So from a documentation standpoint we need to make sure the administrator of the broker understands to run kstart for ticket renewal. 

So the order for Kerberos authentication and renewal is something like:

1) setup kerberos server with realm of EXAMPLE.COM
2) add principal for qpidd/EXAMPLE.COM
3) add entry in keytab (ktadd -k /etc/krb5.keytab qpidd/EXAMPLE.COM)
4) configure broker to use realm, user, and enable gssapi
5) finally, run
    k5start -f /etc/krb5.keytab -K 10 -l 10h qpidd/example.com
    In order to check every 10 minutes during its 10h lifetime

Since there are no existing initscripts for #5 we can put some conditionals in our agent initialization script to run k5start if a certain option exists?

At this time there is not a k5start binary for Windows. In order to port this particular code over we'd either need to compile natively on Windows or port MIT Kerberos into MinGW so that we can continue building everything on Linux. At this time there is very little gain aquired by going down this path.

A proposed design would be to have qpid continually poll the kerberos ticket cache and re-init when the expiry date is close. This way we can eliminate the need for things like "Cron for Windows" or going down different paths to achieve the same goal across platforms.

I'm going to move the component back under qpid-cpp and would like to get some feedback on the above design.

The unfortunate thing with this is that qpid relies on SASL to abstract away the details of the various authentication and security mechanisms.  To ask qpid to poll a kerberos ticket cache is a real violation of this architecture.  As it is, qpid has no access to krb5 or GSSAPI.  These are accessed generically through the SASL layer.

As far as I know, SASL has no means of notifying an application that underlying credentials are soon to expire.

To my thinking, this is a general problem with non-interactive daemons that use kerberos to authenticate to remote services.  There's no user to "log into the network" via kinit.  Might it be more architecturally clean to create a new component that is configured to track and keep kerberos tickets up-to-date?

@tross: I agree completely.  From that perspective it seems like this is even more general of an issue than just for qpid-cpp.

Dmitri, it seems like this bug should be moved over to the security team in general to provide a daemon that tracks and refreshes service oriented tickets.  What are your thoughts?

There is already one. But it does not run on Windows. It would be really tough to find or build a unified solution for Linux and Windows. It might be easier to search for some Windows specific tools that try to solve the same problem but in a Windows specific way. I will take a look.

I did some search and do not see any good tools on windows side. I sent question to MIT. It seems that something like this would have to be built. But to do this I really need this to be prioritized.

@dmitri: Well... it's only important to me if it's important that we support kerberos for Matahari on Windows.  From my perspective, driving matahari adoption is critical, but I don't have a huge vested interest in driving kerberos adoption.  So if we need to tell people that on Windows you can't use kerberos with matahari or vanilla qmf/qpid on Windows, that's fine by me.

Is it certificates then?

But after second thought... How the keytab is going to be provisioned in the first place on Windows? On Linux it can be done with the ipa-client (at least this is how it was planned to be done originally). Anyways we have some tools to get a keytab (ipa-getkeytab for example).

But what about Windows? How you envision the provisioning/bootstrapping? If it is Kerberos there should be other tools built on Windows to get the keytab onto the host in the first place.

Agreed.  But those tools don't presently exist.  In the absence of the right tools for Windows, we will just fall back to user/pass authentication and configure the local broker with the user/pass to talk to the external broker.

So as of right now it looks like the solution is: 

* Fedora/RHEL guests can use either
  * kerberos via ipa
  * user/pass
* Windows guests can use
  * user/pass
* Other Linux distros (other than Fedora/RHEL) can use
  * user/pass
    (unless IPA is ported to those other distros?)

All Linux distros have Kerberos and MIT kerberos will definitely work there. So k5login can be used. Also SSSD is a part of Debian, SUSE, Ubuntu so it is realistic to port ipa-client (as it is a python script) there too. We would need couple things sorted out but it is doable. 

Windows is a much more distant land...

(In reply to comment #17)
> All Linux distros have Kerberos and MIT kerberos will definitely work there. So
> k5login can be used. Also SSSD is a part of Debian, SUSE, Ubuntu so it is
> realistic to port ipa-client (as it is a python script) there too. We would
> need couple things sorted out but it is doable. 
> 
> Windows is a much more distant land...

We'd need k5start though too, on those other distros, right?  k5login only gets us the first ticket.  We need it to renew before it expires.

I meant k5start. I mistyped. Sorry.

Ok so looks like we should be good to go with using kstart on pretty much all of the distros we want to target for Linux.  And we'll just have to recommend user/pass for Windows for the time being.

Given that... this bug can be moved back to matahari component so that astokes can document the kerberos setup process for Linux based hosts (Fedora/RHEL to start with) using a single kstart for all of the agents on a single host or guest.

matahari folks... this make sense to you guys?

Sounds good

Sounds good here, too.

https://github.com/matahari/matahari/wiki/Kerberos-Setup

So what I think we'll do here is update our documentation to include some pointers for Windows on how to run kinit as a service or something like cron for Windows.

Also for kinit under Linux we think it's best to make the use of kerberos configurable so not to make it a requirement but an additional feature of Matahari.

I'd like to close this bug out primarily  because these are just documentation changes that will happen upstream, any objections?

> Also for kinit under Linux we think it's best to make the use of kerberos
> configurable so not to make it a requirement but an additional feature of
> Matahari.

In further discussion we'll need to make some code commits that update how our initialization scripts work for both the agent(s) and broker. Whether we run kstart or not will be based on what configuration options are available in our agent/broker config files.

The cron for Windows is a bit fuzzy part. I think it is called Task Scheduler.
Here is a link that might be useful:
http://msdn.microsoft.com/en-us/library/aa383614%28v=VS.85%29.aspx

https://github.com/matahari/matahari/commit/9a420da7e8565f5ca6cbf2abb02fc87550129549

*** Bug 674579 has been marked as a duplicate of this bug. ***

This was done upstream, but we decided not to include it in RHEL for now.