Client keytab ignored

[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

> The question is, why does it completely ignore my keytab and tries the default one in /etc?

It is not trying the default in /etc

> 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.

> 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.

> 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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York