krb5-1.12.1 and client keytab file

Michael Osipov 1983-01-06 at
Thu May 29 16:54:43 EDT 2014

Am 2014-05-29 19:35, schrieb squidmobile at
> 29 may 2014
> greetings,
> many thanks to michael.
>> Simply compile a recent version of MIT Kerberos, re-link your
>> application and then do:
>> $ export KRB5_CLIENT_KTNAME=<locatiion> # e.g. $HOME/client.keytab
>> $ app-with-gssapi-calls # in my case curl
> i just noticed something.  i run app-name, and not kinit?
> i thought this was a two-step process:  kinit and then app.  i
> expected to see kinit automagically obtain my tgt.
> my failed logic ran:
>    kadmin -p my/admin
>      ktadd -k ./some.key.file  my/principal
>    kdestroy
>    KRB5_CLIENT_KTNAME=./some.key.file kinit
> at this point, kinit did what it wanted and not what i expected.

You do not fiddle with kinit anymore when you set the env var. The Krb5 
mech will detect that the ccache is empty and will seek for the var, if 
that is empty it will try other defaults, then will fail ultimately.

Set export KRB5_TRACE=<some-file> before you run your app and you'll see 
the internals.

> ummm.  openldap does not directly play with gssapi.  it uses
> cyrus-sasl to play with gssapi.  will cyrus-sasl pick this up?
> time for some more tests...

Cyrus SASL needs to be linked to the new MIT Kerberos version or you 
have to change LD_LIBRARY_PATH to tell ld to pick up the new libs.

Yes, it should work.


More information about the Kerberos mailing list