Creating GSSAPI initiate credential using keytab entry
richard.evans at datanomic.com
Mon Mar 8 12:09:59 EST 2010
Thanks for this. Sort of glad that I had missed anything. I do agree
that this is a flaw
in the GSS API.
I'll take a look at your code.
Just for interest, is there any reason why the Kerberos version of
gss_acquire_cred should not get the
credentials itself? It should have access to all the information it
From: Russ Allbery [mailto:rra at stanford.edu]
Sent: 08 March 2010 17:04
To: Richard Evans
Cc: krbdev at mit.edu
Subject: Re: Creating GSSAPI initiate credential using keytab entry
"Richard Evans" <richard.evans at datanomic.com> writes:
> I believe that the gss_acquire_cred call requires a matching entry in
> the credentials cache in order to get the TGT.
> So I guess I would need to:
> 1. Use a KRB5 API call to get the credentials for the relevant keytab
> 2. Store them in a temporary cache file (I don't want to mess with the
> cache for the current user)
> 3. Set the KRB5CCNAME environment variable to point at this location
> 4. Call gss_acquire_cred to get the initiator credentials
> 5. Restore the previous value of KRB5CCNAME, if any
> 6. Delete the temporary cache file
Unfortunately, yup, that's correct.
> Is there any example code which shows how to do this? I've searched
> around and not found much documentation in this area.
The kinit function in:
will do what you want, with obvious modifications where the string
"wallet" occurs. Note that it assumes that my Kerberos portability
is in place and uses some of my utility functions, all of which are
available at http://www.eyrie.org/~eagle/software/rra-c-util/. For MIT
Kerberos without my portability layer, you'll want to drop
krb5_get_init_creds_opt_set_default_flags. For portability to older
versions of Kerberos without that portability layer, you may need to
replace krb5_get_init_creds_opt_alloc with the older calls.
> Also, can this be done in a thread-safe way? I don't like the idea of
> temporarily overriding an environment variable.
No, there isn't any way to do this in a thread-safe manner. It's a
significant flaw in the interface through GSSAPI to the Kerberos
mechanism. In the long run, what I'd like to see is a way to pass
Kerberos credentials into gss_import_name as a mech-specific name, which
would indicate to the mechanism implementation that it should use a
context-specific temporary Kerberos ticket cache using those
Russ Allbery (rra at stanford.edu)
More information about the krbdev