30 may 2014
greetings,
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
KRB5_CLIENT_KTNAME=some.key.file app-with-gssapi-calls
worked.
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
manner.)
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
case of
KRB5CCNAME=MEMORY: KRB5_CLIENT_KTNAME=some.key.file \
app-with-gssapi-calls
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)
kdestroy -A
rm ${KRB5CCNAME}
KRB5CCNAME=FILE:/tmp/tgt_${RANDOM} \
with
KRB5_CLIENT_KTNAME=some.key.file app1-with-gssapi-calls &
ditto for
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.
frank smith
--
http://www.fastmail.fm - The way an email service should be
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
