krb5-1.12.1 and client keytab file
1983-01-06 at gmx.net
Thu May 29 16:54:43 EDT 2014
Am 2014-05-29 19:35, schrieb squidmobile at fastmail.fm:
> 29 may 2014
> 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
> 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
> 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