Client keytab ignored

[Michael-O]

Hi Simo,

first of all, thanks for the quick response. Let me go in detail on the 
issue.

Am 2014-03-26 19:02, schrieb Simo Sorce:
 > On Wed, 2014-03-26 at 17:34 +0100, Michael-O wrote:
 >> Hi,
 >>
 >> I am trying to obtain a service ticket with a client keytab for my 
account. Unfortunately it fails. I wanted to narrow this down and tried 
to peform the very same operation with
 >> $ kinit -k -t my.keytab
 >> and it says kinit: Keytab contains no suitable keys for 
host/fqdn at REALM while getting initial credentials.
 >
 > Kinit assumes you waht to initiate host/<hostname>@<REALM>, if you
 > keytab contains keys for another principal you need to specify that
 > principal on the kinit command line:
 >
 > kinit -k -t my.keytab my/principal at REALM

This explains a lot.

 >> Additionally, I have set KRB5_CLIENT_KTNAME and KRB5_KTNAME with 
$HOME/my.keytab and FILE:$HOME/my.keytab, no avail.
 >> Is there any trick to make a client keytab work with kinit and 
GSS-API init_sec_context?
 >
 > How are you testing hits ? Is it a custom application ?
 > Some application may need minor modifications to be able to take
 > advantage of KRB5_CLIENT_KTNAME depending on how they use gssapi.
 >
 > I use Keytab Initiation often and works fine so far.

I have tried:

1. KRB5_CLIENT_KTNAME=... kinit -k -t my.keytab
    with no difference

Maybe, I should elaborate on my use case: I'd like to use curl and 
libcurl in an automated fashion from within C and Fortran. I use an AD 
account for that, I have created a keytab with ktutil and want to use 
that keytab with curl. I assumed that this should work automagically as 
long as the KRB5 API knows about the keytab location.

 >> The MIT Krb5 docs say that the first principal from the keytab is
 >> taken and my principal is in the keytab which I have created with
 >> ktutil.
 >
 > Yes this is true for gssapi, not for kinit, kinit wants you to be
 > explicit about what principal to use if not the default host principal.

That is good to know.

 >> I am on RHEL 6.5, Linux <fqdn> 2.6.32-431.5.1.el6.x86_64 #1 SMP Fri
 >> Jan 10 14:46:43 EST 2014 x86_64 x86_64 x86_64 GNU/Linux, MIT Kerberos
 >> from standard yum repository.
 >
 > Ah this explains why your application wouldn't work, Keytab Initiation
 > has been introduced in MIT Krb 1.11, we haven't backported it to RHEL 6
 > which runs on 1.10, RHEL 7 will have keytab initiation support.

Are you refering to [1]: "Add a new API krb5_kt_client_default() to 
resolve the default client keytab"?

Does this mean that I won't be able to use a client keytab and create an 
outbound context without an explicit kinit with the keytab to populate a 
credential cache? It comes to my mind that [2] is actually describing my 
exact problem and telling me that I need a new MIT Kerberos version ...

As an important side note, my target platform is HP-UX 11.31 but HP 
makes is really hard to determine what exact MIT Kerberos version is 
installed. All I know is that it has no SPNEGO support so it must be old 
I took RHEL 6 just to verify that issue on a more popular platform. 
Plus, I am used to use Oracle's JGSS, where I provide a principal and 
the keytab, the system does rest.

Thanks,

Michael

[1] http://web.mit.edu/kerberos/krb5-1.11/README-1.11.txt
[2] http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation