krb5-1.12.1 and client keytab file
squidmobile at fastmail.fm
Fri May 30 13:38:43 EDT 2014
30 may 2014
again, many thanks to michael.
>>$ export KRB5_CLIENT_KTNAME=<location> # e.g. $HOME/client.keytab
>>$ app-with-gssapi-calls # in my case curl
i ran some tests, and they proved most interesting.
the good news is that
the bad news is that it did not always work quite as expected.
if you do NOT have a tgt, this syntax works and works well. it
obtains a tgt with the principal specified in the client keytab.
the app (in my case ldapwhoami) worked exactly as expected.
(please note that i cite cyrus-sasl and openldap because that is
the only app i currently have that uses gssapi in quite this
fashion. i expect any other gssapi app to behave in a similar
complications arise if you already have a tgt. if that tgt is
valid, the cyrus-sasl library will use it and ignore the principal
in the KRB5_CLIENT_KTNAME file. that current active principal
could be very wrong for the app in question. if that tgt exists
and is expired, the app fails because of the expired tgt; it does
NOT obtain a new tgt with the specified principal.
if you use the KRB5CCNAME=DIR:... variable setting, things can get
even more interesting. if you run kdestroy -A and let the app
obtain a tgt, that tgt appears as a random secondary tgt in the
credential cache directory. it leaves the primary tgt unchanged.
klist does not show the new tgt, but klist -A shows its existence.
kswitch -p can make it the primary tgt.
considering the potential clash between principals, i tried the
KRB5CCNAME=MEMORY: KRB5_CLIENT_KTNAME=some.key.file \
this worked extemely well. no clashes occured with any other tgt,
with either the FILE:... or DIR:... syntax. however, i believe
some dialects of unix make all of memory available via things like
/dev/kmem or /proc/core, which could pose security issues...
i suppose you could run some FILE: games, such as (pick one)
KRB5_CLIENT_KTNAME=some.key.file app1-with-gssapi-calls &
KRB5_CLIENT_KTNAME=other.key.file app2-with-gssapi-calls &
to clear the credential cache for the second app.
one other thought: what happens to app-with-gssapi-calls if it
runs past the time limit for the tgt obtained by this mechanism?
i suspect app-specific behavior. for example, openssh validates at
the start of the connection and any given connection will run
forever, but openldap validates every transaction.
i wish the krb5 documentation people would include some variant of
some of these observations in the documentation that comes with
krb5. i think their recommendations would be most helpful.
many thanks for the tip.
http://www.fastmail.fm - The way an email service should be
More information about the Kerberos