[35924] in Kerberos
Re: Client keytab ignored
daemon@ATHENA.MIT.EDU (Michael-O)
Wed Mar 26 18:40:43 2014
Message-ID: <533356CC.9030705@gmx.net>
Date: Wed, 26 Mar 2014 23:38:04 +0100
From: Michael-O <1983-01-06@gmx.net>
MIME-Version: 1.0
To: kerberos@mit.edu
In-Reply-To: <1395856929.1844.37.camel@willson.li.ssimo.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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@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@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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
