Can't acquire stored impersonated creds from cache

[Martin Gee]

Thanks Greg,
I'm currently exporting / importing the cred in my own cache similar to what you described.  I'm using the latest code from github which I believe is the 1.14 branch. 
On that note, it seems creds / tickets don't refresh either. I'm using gss_acquire_cred (to get the TGT).  from: Developing with GSSAPI — MIT Kerberos Documentation
|   |
|   |   |   |   |   |
| Developing with GSSAPI — MIT Kerberos DocumentationDeveloping with GSSAPI The GSSAPI (Generic Security Services API) allows applications tocommunicate securely using Kerberos 5 or other security mechanisms.  |
|  |
| View on web.mit.edu | Preview by Yahoo |
|  |
|   |


"If the krb5 mechanism acquires initial tickets using the default client keytab, the resulting tickets will be stored in the default cache or collection, and will be refreshed by future calls togss_acquire_cred as they approach their expire time."
Seems the docs describe something that doesn't exist in the the code.  


     On Sunday, September 20, 2015 3:10 PM, Greg Hudson <ghudson at mit.edu> wrote:
   

 On 09/20/2015 07:46 AM, Martin Gee wrote:
> Version: 1.14I'm attempting to cache some impersonated credentials by using gss_store_cred with the output cred from gss_acquire_cred_impersonate_name.I see the credential via klist after my program runs.
[...]
> Major gss_acquire_cred_impersonate_name:851968 - Unspecified GSS failure.  Minor code may provide more information
> Minor gss_acquire_cred_impersonate_name:-2045022969 - Credential usage type is unknown
> But the call seems to error out as shown. I am using GSS_C_INITIATE as the usage type.Am I missing something?

I can reproduce this problem and have opened a ticket:

    http://krbdev.mit.edu/rt/Ticket/Display.html?id=8248

Unfortunately, the only current way to do what you want is to make your
application manage a fleet of credential caches for each impersonated
credential.  The outline of your code would be:

1. Choose a ccache name based on the subject name.

2. Try to read the chosen ccache name using gss_acquire_cred_from().  On
success, stop and use that cred directly for the subsequent operation
(which I assume is S4U2Proxy using gss_init_sec_context()).  On failure,
continue to step 3.

3. Acquire a service TGT cred from the default cache using
gss_acquire_cred().  (Or from a separately chosen cache name for the
service TGT using gss_acquire_cred_from(), if you want.)

4. Make an S4U2Self request using gss_acquire_cred_impersonate_name(),
using the service TGT cred object as the impersonator cred.

5. Store the result into the chosen ccache name using gss_store_cred_into().

gss_acquire_cred_from() and gss_store_cred_into() are GSS extensions
added in MIT krb5 release 1.11.

> I'm using the latest kerb build. I believe this used to work with 10.1.13

I'm not sure if you mean 1.10 or 1.13, but either way, this scenario
never worked as far as I can tell.  In 1.11 and later, it fails for the
reasons described in the ticket; in 1.10, gss_store_cred() fails with:

    gss_store_cred: Invalid credential was supplied
    gss_store_cred: Principal in credential cache does not match desired
name

There is a variant scenario which sort of works in 1.11 and later.  If
the service ccache does not contain forwardable tickets,
gss_acquire_cred_impersonate_name() does not construct a proxy cred
object; instead it just creates a memory cache containing the
subject-to-service ticket.  This credential object cannot be used for
S4U2Proxy, but it does store and retrieve successfully.  Even in this
limited scenario, repeated runs of the program each store a copy of the
subject-to-service ticket, causing the cache to grow without bound.