Bug 674578 - Use kstart in matahari init scripts to programatically renew tickets for kerberos
Use kstart in matahari init scripts to programatically renew tickets for kerb...
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: matahari (Show other bugs)
6.3
Unspecified Unspecified
high Severity low
: rc
: ---
Assigned To: Adam Stokes
Dave Johnson
:
Depends On: 674576 737123
Blocks: 688181 743047
  Show dependency treegraph
 
Reported: 2011-02-02 09:43 EST by Perry Myers
Modified: 2011-10-06 09:09 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 674576
Environment:
Last Closed: 2011-10-06 09:09:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Perry Myers 2011-02-02 09:43:40 EST
+++ This bug was initially created as a clone of Bug #674576 +++

Description of problem:
qpid supports kerberos auth, but for a qpid daemon or QMF console/agent there is no built in way to programatically re-authenticate using a keytab.

This functionality needs to be included otherwise using kerberos w/ qpid/QMF will not work properly.
Comment 1 Ted Ross 2011-08-15 19:01:36 EDT
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.
Comment 2 Dmitri Pal 2011-08-17 16:28:44 EDT
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?
Comment 4 Dmitri Pal 2011-08-19 17:17:47 EDT
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
Comment 5 Perry Myers 2011-08-22 11:29:33 EDT
@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?
Comment 6 Dmitri Pal 2011-08-22 14:02:19 EDT
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.
Comment 7 Adam Stokes 2011-08-23 11:03:45 EDT
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?
Comment 8 Adam Stokes 2011-08-23 15:27:03 EDT
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.
Comment 9 Ted Ross 2011-08-23 15:43:13 EDT
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?
Comment 10 Perry Myers 2011-08-23 17:27:48 EDT
@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?
Comment 11 Dmitri Pal 2011-08-23 18:08:13 EDT
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.
Comment 12 Dmitri Pal 2011-08-23 18:53:04 EDT
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.
Comment 13 Perry Myers 2011-08-24 12:51:58 EDT
@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.
Comment 14 Dmitri Pal 2011-08-24 12:59:34 EDT
Is it certificates then?
Comment 15 Dmitri Pal 2011-08-24 13:15:14 EDT
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.
Comment 16 Perry Myers 2011-08-24 14:32:28 EDT
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?)
Comment 17 Dmitri Pal 2011-08-24 14:40:25 EDT
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...
Comment 18 Perry Myers 2011-08-24 16:04:33 EDT
(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.
Comment 19 Dmitri Pal 2011-08-24 19:34:01 EDT
I meant k5start. I mistyped. Sorry.
Comment 20 Perry Myers 2011-08-24 22:00:25 EDT
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?
Comment 21 Adam Stokes 2011-08-25 10:04:29 EDT
Sounds good
Comment 22 Russell Bryant 2011-08-25 13:22:26 EDT
Sounds good here, too.
Comment 24 Adam Stokes 2011-08-25 14:58:01 EDT
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?
Comment 25 Adam Stokes 2011-08-25 16:39:41 EDT
> 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.
Comment 26 Dmitri Pal 2011-08-25 18:20:48 EDT
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
Comment 28 Dave Johnson 2011-09-13 10:03:04 EDT
*** Bug 674579 has been marked as a duplicate of this bug. ***
Comment 29 Russell Bryant 2011-10-06 09:09:19 EDT
This was done upstream, but we decided not to include it in RHEL for now.

Note You need to log in before you can comment on or make changes to this bug.