Creating GSSAPI initiate credential using keytab entry

Richard Evans richard.evans at
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


-----Original Message-----
From: Russ Allbery [mailto:rra at] 
Sent: 08 March 2010 17:04
To: Richard Evans
Cc: krbdev at
Subject: Re: Creating GSSAPI initiate credential using keytab entry

"Richard Evans" <richard.evans at> 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:;a=blob;f=client/krb5.c;h=381

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  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

More information about the krbdev mailing list