Creating GSSAPI initiate credential using keytab entry

Russ Allbery rra at stanford.edu
Mon Mar 8 12:03:58 EST 2010


"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
> entry
> 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:

http://git.eyrie.org/?p=kerberos/wallet.git;a=blob;f=client/krb5.c;h=38172ae7c64866a0dd364a76945ce8824ae18df4;hb=29452c3daeeb15670322907c53f5db2b43d2559f

will do what you want, with obvious modifications where the string
"wallet" occurs.  Note that it assumes that my Kerberos portability layer
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 credentials.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the krbdev mailing list